Correcting the definition of the terms of the halting problem

[olcott]

*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

(b) 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

[Richard Damon]

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.

Note, the definition of a UTM say you can replace the actual running of
the machine representation with that of a UTM simulation (because it
will behave the same) but that operation also says such a simulation can
not abort, as the machine given as an input didn't stop running there.

THus adding the "by H" to your definition, you are REQUIRING that H can
not abort its simulation, and thus your statement (b) is meaningless, as
something that can not abort can not have conditions when it can abort.

You could say, if H correctly determines that (perhaps by its own
partial correct simulation) that an ACTUAL correct simulation of the
input by an actual UTM would not halt, you would be correct.


You H doesn't meet this requrement.

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

But only if H ACTUALLY DOES a correct simulation (which means never
aborts), and that simulation must be of the ACTUAL D, which in this case
used the H that aborts and returns the non-halting answer (not the OTHER
machine lyingly also called H which does a correct simulation).

So, you requirment boils down to a correct halting decider must not
abort its simulation, but also must abort its simulation.

Your H is just another name for the Barber that shaves everyone that
doesn't shave themselves, or the set of all sets that don't contain
themselves.

It just can not exist.

Your "proof" is based on the error or replacing the PROGRAM D, for a
tenplate that changes when the decider changes. Such a template is not a
program, so is a category error to give to a Halt Decider.

Yes, YOUR definition of D (which isn't of a program) make the Halting
Question about it invalid, because it isn't actually a program, which is
what the domain of the Halting Question is.

[immibis]

On 1/19/24 14:54, 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.

yes

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

yes

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

no, this is your interpretation

[olcott]

Well it is very great that you agreed to the first two.
That you can't understand that DD does specify recursive
simulation to HH means that you cannot understand me.

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.

[olcott]

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.

[Richard Damon]

No, D, if it is an actual program, has its OWN "copy" of H that it uses,
so it is not recursive with the H that is deciding it.

If H can notice that D is using a copy of it then it can use that
knowledge, but it also must take into account that that H will behave
exactly like THIS H, so if this H aborts and return 0, it must take into
account that THAT H will also abort and return 0.

The H isn't some "abstract definition", but an actual copy of the actual
code that will do exactly like this one does.

Yes, this means that H is put into the impossible position of having to
compute the answer to the Liar's Paradox. This doesn't mean the question
is invalid, as for every putative definiton of H, there is an answer, it
just means that no H can exist that gets the answer right.

[olcott]

I have proven that does not make any difference.

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Simulating Partial Halt Decider Applied to Linz Proof
Non-halting behavior patterns can be matched in N steps. The simulated
⟨Ĥ⟩ halts only it when reaches its simulated final state of ⟨Ĥ.qn⟩ in a
finite number of steps.

(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

[Richard Damon]

Except that pattern isn't non-halting, since if H (and thus embedded_H)
abort its simulation, that loop is NOT non-halting, but will reac a
point where the outer embedded_H also decides to abort and return Qn to
the Ĥ it was part of, which then halts.

Only by embedded_H not being the required exact copy of H do you get
your logic.

So, your statement is just false, and the fact that this has been
pointed out to you many times, shows you are a pathological liar and an
idiot.

[olcott]

An aborted simulation does not count as the simulated input reaching
its simulated final state of ⟨Ĥ.qn⟩ and terminated normally.

Since it is impossible for the simulated input ⟨Ĥ⟩ to reach its
simulated final state of ⟨Ĥ.qn⟩ and terminate normally then
professor Sipser and I agree that IT DOES NOT HALT.

[Richard Damon]

Right, but doesn't show that the correct simulaiton of that input would
not halt.

Ĥ uses its copy of H to answer (by its simulation) the question about
its input (Ĥ) (Ĥ), and that H aborts its simulation and returns to Ĥ
which halts, as would a CORRECT simulaton of the input to any H give (Ĥ)
(Ĥ).

You are confusing the fact that H does a simulation, with the behavior
of the actual input, and the fact that a correct simulation of this
input simulates a simulator that aborts (and thus doesn't do a correct
simulation) and returns to its caller.

>
> Since it is impossible for the simulated input ⟨Ĥ⟩ to reach its
> simulated final state of ⟨Ĥ.qn⟩ and terminate normally then
> professor Sipser and I agree that IT DOES NOT HALT.
>

Nope.

Read what professor Sipser agreed to, *IF* H can CORRECTLY DETERMINE
that a CORRECT SIMULAITON (by H or anyone else, all correct simulation
are the same) of this input would not halt.

For the clause correct simulation by H to be true, H (and that mean THIS
H) must do a correct simulation in the first place, and since it
doesn't, it can't use that clause.

You confuse two different H's that you have intentionaly and deceptively
given the same name, a practice not allowed in proper logic.

All you have done is defined an impossible condition to use for you decider.

IT is the same as asking does the Barber who shaves everyone who does
shave themesevles shave himself?

[immibis]

H is not allowed to simply ignore that D would detect infinite
recursion, stop simulating and reach a final state.

[Richard Damon]

Except that D doesn't create infinite recursion BECAUSE H (the H used by
D) aborts its simulation and stops it.

Thus the H deciding, can't validly assume the H in D does what you claim
it assumes.

You have to look at the ACTUAL program D (and not the false template you
have created) and the actual H that it uses, which is exactly always the
H that you claim to give the right answer.

Therefore, when the deciding H postulates that it is something differnt
that actually does a correct simulation, that doesn't change the H that
D calls, it still cause the original H that will abort.

Thus H is INCORRECT in presuming that if it was something different that
didn't abort its simulation would go on forever.

Only in your INCORRECT model, where D changes to call whatever H is
trying to decide it, as opposed to the SPECIFIC H which is claimed to
get the right answer, is your logic valid.

Since it doesn't look at the ACTUAL PROGRAM D that the input is claimed
to represent, the logic isn't valid.

[olcott]

Do you understand that none of the simulated ⟨Ĥ⟩ can possibly reach
their simulated final state of ⟨Ĥ.qn⟩ ???

[olcott]

*This is simply over your head*
Unless the outermost HH aborts its simulation then none of them do.

[olcott]

HH correctly simulates DD until it correctly determines
that HH correctly simulated by HH cannot possibly reach
its own simulated final state and halt, then HH returns
to its caller.

When DD(DD) is its caller then this entirely different
execution sequence benefits from the fact that HH
has aborted the simulation of the different execution
sequence specified by DD.

HH cannot possibly benefit from itself already having
aborted the simulation of DD before any HH has done this.

[immibis]

Why?

And what is HH? You changed H to HH - why?

[immibis]

On 1/19/24 17:07, olcott wrote:
> On 1/19/2024 9:56 AM, immibis wrote:
>> On 1/19/24 14:54, 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.
>>
>> yes
>>
>>>
>>> *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.
>>
>> yes
>>
>>>
>>> *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
>>
>> no, this is your interpretation
>>
>
> Well it is very great that you agreed to the first two.
> That you can't understand that DD does specify recursive
> simulation to HH means that you cannot understand me.
>

That you can't understand that H contains a non-halting pattern checker
means you cannot understand yourself.

And what is HH?

[immibis]

On 1/19/24 18:17, olcott wrote:
>
> An aborted simulation does not count as the simulated input reaching
> its simulated final state of ⟨Ĥ.qn⟩ and terminated normally.
>

An abortING simulation does count as the simulatOR reaching its final
state and terminating normally.

[olcott]

Each simulated HH has the exact same instructions as the
others because it <is> the same code at the same machine
address.

The outer HH aborts the simulation as soon as the abort
criteria has been met. Since it sees this abort criteria
first unless it aborts then none of them do.

> And what is HH? You changed H to HH - why?

HH is the original H and can simulate itself simulating
DD. H can not do this, it uses a different abort criteria
so that it can abort sooner.

[olcott]

Yes it does. It does not count as the simulated input DD halting.

[Richard Damon]

Yes, and it doesn't matter as an aborted simulation does not prove
non-halting. Partial simulations don't themselves prove anything. The
actual correct simulation of this input, when given to a REAL UTM (and
the input still using the embedded_H that is a copy of the H that gave
the answer) shows that it will halt, and thus none of the H's simulation
are "correct" for that purpose (just partial)

You are just proving yourself to be an idiot to claim that a "correct
answer" about the Halting behavior of the machine descxribed by the
input can be anything that disagrees with te actual Halting Beahvior of
the program described by the input when run.

You have agrees that Ĥ (Ĥ) will halt, but claim, as a lie, that
H (Ĥ) (Ĥ) saying non-halting is correct, because its PARTIAL (and thus
not difinitive) simulation didn't reach a final state.

Only a simulation that shows that you can not reach a final state even
after an unbounded number of steps shows non-halting, but doing such a
simulation make the machine fail to be a decider, as deciders must
answer in bounded time, and until you invent a time machine, you can't
do unbounded work in bounded time.

[Richard Damon]

The HH actually NEVER stops its simulation

>
> When DD(DD) is its caller then this entirely different
> execution sequence benefits from the fact that HH
> has aborted the simulation of the different execution
> sequence specified by DD.

But it isn't a different exection sequence.

Please show the first step in HH where its behavior differed by being
called from DD then being run as a top level machine.

or equivalnently

Show the first step where a difference actually occurs between the
"Correct" simulation done by HH on its input verse the actual behavior
of the directly run machine (or simulation of the input by a UTM) where
the behavior occurs.

There needs to be a first step of difference for the final results to be
different, since they start at the same place.

>
> HH cannot possibly benefit from itself already havng

> aborted the simulation of DD before any HH has done this.
>

You have the actions backwards. The HH that is doing the actual
simulation needs to "look ahead" at the behavior that the simulated
machine WILL DO if it simulated farther before it can decide to abort.
Since the simulated HH, if properly simulated past the point where HH
decides to abort its simulate, will also reach the point where it will
abort its simulation and return, and thus HH needs to take this into
account if it is to "Correctly" determine what a "Correct Simulation"
will do.

[Richard Damon]

And if the outermost HH aborts its simulation, then a correct simulation
of all of them do, so HH was incorrect in assuming that even if it
aborts, that the correct simulation of this input will never halt.

Since HH doesn't actually do the defined "correct simulation" it can't
use that as grounds to abort. It needs to correctly decide on the
behavior of an actual correct simulation.

[Richard Damon]

No, ALL of the others would do in an actual correct simulation.

>
>> And what is HH? You changed H to HH - why?
>
> HH is the original H and can simulate itself simulating
> DD. H can not do this, it uses a different abort criteria
> so that it can abort sooner.
>

And is still wrong.

[Richard Damon]

On 1/19/24 4:13 PM, olcott wrote:
> On 1/19/2024 2:46 PM, immibis wrote:
>> On 1/19/24 18:17, olcott wrote:
>>>
>>> An aborted simulation does not count as the simulated input reaching
>>> its simulated final state of ⟨Ĥ.qn⟩ and terminated normally.
>>>
>>
>> An abortING simulation does count as the simulatOR reaching its final
>> state and terminating normally.
>>
>>
>
> Yes it does. It does not count as the simulated input DD halting.
>

Except for the fact that it is a given that the correct simulaiton of
that part of the input will be the same as the actual behavior of the
simulator.

Since H returns to qn, a correct simulation of embedded_H must see it
going to qn too.

[immibis]

Does the direct executed HH have the exact same instructions as each
simulated HH?

[immibis]

On 1/19/24 22:13, olcott wrote:
> On 1/19/2024 2:46 PM, immibis wrote:
>> On 1/19/24 18:17, olcott wrote:
>>>
>>> An aborted simulation does not count as the simulated input reaching
>>> its simulated final state of ⟨Ĥ.qn⟩ and terminated normally.
>>>
>>
>> An abortING simulation does count as the simulatOR reaching its final
>> state and terminating normally.
>>
>>
>
> Yes it does. It does not count as the simulated input DD halting.
>

Talk about each level with different name.

DD0 will reach its final state and terminate normally, if not aborted.
DD1 will reach its final state and terminate normally, if not aborted.
DD2 will reach its final state and terminate normally, if not aborted.
DD3 will reach its final state and terminate normally, if not aborted.
DD4 will reach its final state and terminate normally, if not aborted.
And so on.

DD0 aborts the simulation of DD1.
DD1 aborts the simulation of DD2, if DD1 isn't aborted before that happens.
DD2 aborts the simulation of DD3, if DD2 isn't aborted before that happens.
DD3 aborts the simulation of DD4, if DD3 isn't aborted before that happens.
DD4 aborts the simulation of DD5, if DD4 isn't aborted before that happens.
And so on.

The only reason that DD1 doesn't reach its final state and terminate
normally is that DD1 is aborted by DD0.
The only reason that DD2 doesn't reach its final state and terminate
normally is that DD2 is aborted by DD1.
The only reason that DD3 doesn't reach its final state and terminate
normally is that DD3 is aborted by DD2.
The only reason that DD4 doesn't reach its final state and terminate
normally is that DD4 is aborted by DD3.
And so on.

If the ONLY reason a simulation doesn't reach its final state and
terminate normally is that the simulation is aborted, then the correct
return value from the halting decider is 1.

[olcott]

void Infinite_Loop()
{
HERE: goto HERE;
}

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.

The freaking repeated state proves non-halting the first freaking time
that it is encountered.

[olcott]

When DD(DD) calls HH(DD,DD) this *DOES NOT SPECIFY* recursive
simulation.

When DD is simulated by HH(DD,DD) calls HH(DD,DD) this *DOES SPECIFY*
recursive simulation.

You must be very terrible at coding.

[Richard Damon]

That isn't what I said. The fact that the aborted simulation didn't
reach an end, doesn't prove BY ITSELF, that the input is non-halting.

For some case, like above, it is possible to reason about the future
behavior of the simulation, and actually PROVE that it will never reach
a finite state.

It just turns out, that for the D/H case, there is no proof, becuase it
just isn't true, as ANY H that returns 0, will cause the D that is built
on it, to be Halting, and thus a correct simulation of it will end.

The fact that you have shown that you don't actually understand how to
build an actual proof, puts you at a major disadvantage to show what you
need to do.

[Richard Damon]

If the above didn't, then this doesn't. If HH(DD,DD) is correctly
simulting its input, then it simulating DD calling HH(DD,DD) has exactly
the same meaning to the simulaiton and the call did to the actual execution.

Yes, HH seeing that it is simulating an input that it "knows" about,
might allow it to determine some things about the simulation before they
happen, but it can only be correct about future behavior that actually
happens.

If DD(DD) calling HH(DD,DD) doesn't actually cause an infinite recursion
loop, HH(DD,DD) simulating the call in DD(DD) to HH(DD,DD) can't presume
such an infinite recursion loop, that is just using false premises.

The simulator needs to use CORRECT knowledge of what the ACTUAL input
does, since we know that eventually the actual decider that you are
claiming to be correct will abort and return 0, the input built on that
calls a decider that does that, and the simulator part of the decider
needs to use logic that is compatible with that behavior. It can't
presume the decider called behaves differently then it actually behaves.

>
> You must be very terrible at coding.
>

So, what was different.

Show the point of first difference.

You are showing you don't understand the meaning of correct simulation,

[olcott]

This is simply not true. What computer language are you an expert in?

The outermost HH sees the abort criteria first. If it does not abort
then none of them do because it is the exact same code at the exact
same machine address.

[olcott]

There is only one HH at machine address [00001032].

[olcott]

It is the repeated state that proves non-halting you big dummy.
You never did any programming did you?

[immibis]

You can prove it.

You can't prove it with by simulating a bunch of steps and then saying
it still hasn't halted so it won't ever halt.

[immibis]

[olcott]

Repeated State [00001c42] to [00001c4e]!
Repeated State [00001c42] to [00001c4e]!
Repeated State [00001c42] to [00001c4e]!

New Jersey, New Jersey, New Jersey is also a repeated state

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

[olcott]

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.

[Alan Mackenzie]

In comp.theory Richard Damon <ric...@damon-family.org> wrote:

[ .... ]

> Only a simulation that shows that you can not reach a final state even
> after an unbounded number of steps shows non-halting, but doing such a
> simulation make the machine fail to be a decider, as deciders must
> answer in bounded time, and until you invent a time machine, you can't
> do unbounded work in bounded time.

Is that right? Deciders must answer in finite time, but is there
actually a bound on how long this time can be? If so, what is it?

--
Alan Mackenzie (Nuremberg, Germany).

[olcott]

Once a simulating halt decider sees a repeating state it knows that
its input DOES NOT HALT.

[olcott]

On 1/19/2024 4:50 PM, Alan Mackenzie wrote:

The actual technical bound is anything less than infinite time.

[olcott]

On 1/19/2024 4:54 PM, olcott wrote:
> On 1/19/2024 4:50 PM, Alan Mackenzie wrote:
>> In comp.theory Richard Damon <ric...@damon-family.org> wrote:
>>
>> [ .... ]
>>
>>> Only a simulation that shows that you can not reach a final state even
>>> after an unbounded number of steps shows non-halting, but doing such a
>>> simulation make the machine fail to be a decider, as deciders must
>>> answer in bounded time, and until you invent a time machine, you can't
>>> do unbounded work in bounded time.
>>
>> Is that right?  Deciders must answer in finite time, but is there
>> actually a bound on how long this time can be?  If so, what is it?
>>
>
> The actual technical bound is anything less than infinite time.

I stated that incorrectly actual technical bound is a finite number of
steps.

[Alan Mackenzie]

In comp.theory olcott <polc...@gmail.com> wrote:

[ .... ]

> void Infinite_Loop()
> {
> HERE: goto HERE;
> }

> 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 freaking repeated state proves non-halting the first freaking time
> that it is encountered.

If the purported halt decider actually analyses its input, rather than
attempting to simulate it. But there are inputs which are beyond
analysis, and it is neither practical nor possible to say whether the
machines they represent halt or not.

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

[Richard Damon]

No, YOU do not understand about programs.

ALL programs have a defined code. HH must Either HAVE or NOT HAVE the
instruction that cause it to abort its simulation.

If HH HAS those instructions, the the correct simulation of its input
WILL see DD(DD) calling HH(DD,DD) and it eventually (after the point
that any HH simulating it has already aborted its simulation) decide to
abort its simulation and return to DD and DD will then Halt.

If you talk about changing HH to something else, then you can not also
change the HH that DD calls, or you are now talking about a different input.

So since the HH that answers has the abort (or it doesn't answer as you
have shown) DD must call the HH that aborts, and if you make a different
decider that doesn't abort that you try to call HH, you need to make
sure that DD calls the ORIGICAL HH) and then this new HH will see that
DD(DD) calls HH(DD,DD) and that eventually that HH (remember the input
DD calls the HH that you claim give the right answer, NOT the HH that is
deciding on it at the moment) will abort and return to DD and DD Halts.
So, the HH that DOES a correct simulation shows that the only DD (the DD
that calls the original HH) halts, so no HH can use correct simulation
being non-halting as a correct basis to make an action.

SAME machine address means nothing, except that your model is incorrect
and you aren't actually allowed to talk about a different HH at that
address as it changes the input.

[Richard Damon]

And what repeated state is that?

You reach the same point but in a different context, and that context
matters.

You are forgetting that each layer of simulation is conditional, and
thus the fact that there is a repeat at an inner layer can affect the
outer layer and cause it to abort the simulation, thus there is not
infinite loop.

Either you need to make the simulation unconditional, at which point you
do get the infinite behavior, but no answer, or you let the simulation
be conditional but then it isn't necessarily infinite. Since every level
is the same, if any level returns 0, ALL layers when correctly simulated
return 0.

[Richard Damon]

Different context, so NOT "Repeated State"

[Richard Damon]

Which means you are not allowed to change it without changing the input,
so you can't talk about "any HH" since for a given DD, there is only
one, the one that it was built on.

Since this one either doesn't abort, and thus never returns an answer,
or does abort, and thus there isn't a correct simulation by HH to make a
correct decision on, has no valid grounds to do its abort, and thus acts
in error.

[Richard Damon]

It is not stated, but it it DOES answer in a finite time, then that time
can be given as the bound.

[Richard Damon]

On 1/19/24 5:53 PM, olcott wrote:
> On 1/19/2024 4:50 PM, Alan Mackenzie wrote:
>> In comp.theory Richard Damon <ric...@damon-family.org> wrote:
>>
>> [ .... ]
>>
>>> Only a simulation that shows that you can not reach a final state even
>>> after an unbounded number of steps shows non-halting, but doing such a
>>> simulation make the machine fail to be a decider, as deciders must
>>> answer in bounded time, and until you invent a time machine, you can't
>>> do unbounded work in bounded time.
>>
>> Is that right?  Deciders must answer in finite time, but is there
>> actually a bound on how long this time can be?  If so, what is it?
>>
>
> Once a simulating halt decider sees a repeating state it knows that
> its input DOES NOT HALT.
>
>

Yes, if it is FULL repeated state of the FULL thing simulated.

Seeing a repeat in the nested simulation of the outer simulation, when
the outer simulation is conditional is NOT sufficient.

[olcott]

On 1/19/2024 4:58 PM, Alan Mackenzie wrote:
> In comp.theory olcott <polc...@gmail.com> wrote:
>
> [ .... ]
>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>
>> 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.

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.

[olcott]

I will assume that you are not an expert in any programming
language until you say otherwise.

[olcott]

You don't even know what the term means.

[olcott]

On 1/19/2024 5:03 PM, Richard Damon wrote:

Wrong. It must be a finite sequence of steps it
does not matter if each step takes a million years.

[Richard Damon]

Nope.

He agrees that if H can CORRECT determine that a CORRECT SIMULATION (it
doesn't really matter by who) of THIS input would be non-halting, then
the decider can abort.

Since D(D) Halts, a correct simulation will halt, and thus you can not
correctly determine that a correct simulation would not halt, therefore
H is INCORRECT in its decision to abort.

Any simulation showing non-halting behavior is of a different input
where D was built on a different H than the one originally give, which
does abort its simulation and returns 0.

Your system, just is incapbable of handling the required components, and
you have admitted that in the past.

D needs to use the original H, but your system can have only one H, so
any operations done with a modified H (like removing its abort
operation) are just not applicable, as they are not look at the actual
problem.

You also have admitted that your D isn't even really a program, so none
of your logic is even applicable.

You are also have admited that you aren't even working in Computation
Theory, but Olcott-Computation Theory, and just lying that it applies to
the original theory.

[olcott]

You have simply been indoctrinated to believe this.
My counter-example may be the first case in history
where the correct simulation has different behavior
that the direct execution.

The directly executed DD(DD) itself does specify recursive
simulation that is aborted on its second recursive call.
This is the first time that HH can see what is going on.

[Alan Mackenzie]

In comp.theory olcott <polc...@gmail.com> wrote:
> On 1/19/2024 4:58 PM, Alan Mackenzie wrote:
>> In comp.theory olcott <polc...@gmail.com> wrote:

>> [ .... ]

>>> void Infinite_Loop()
>>> {
>>> HERE: goto HERE;
>>> }

>>> 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. Such is impossible, just as it is impossible to square the
circle, or trisect an angle with ruler and compasses.

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

[Richard Damon]

Which is INPOSSIBE by the DEFINITION of "Correct Simulation"

You can't make a cow a horse by calling it a horse.

>
> The directly executed DD(DD) itself does specify recursive
> simulation that is aborted on its second recursive call.
> This is the first time that HH can see what is going on.
>

But the simulation that was aborted was aborted by the program, and thus
the program gets "credit" for that behavior.

The fact the decider in the program happens to abort a simulation
doesn't make the program non-hatling.

This doesn't change just becauae the program it was simulating happend
to be a copy of itself.

You just are proving your utter ignorance of the subject and the fact
that you are just a pathological liar that just doesn't understand what
Truth actually is.

[Richard Damon]

On 1/19/24 6:35 PM, olcott wrote:
> On 1/19/2024 5:03 PM, Richard Damon wrote:
>> On 1/19/24 5:50 PM, Alan Mackenzie wrote:
>>> In comp.theory Richard Damon <ric...@damon-family.org> wrote:
>>>
>>> [ .... ]
>>>
>>>> Only a simulation that shows that you can not reach a final state even
>>>> after an unbounded number of steps shows non-halting, but doing such a
>>>> simulation make the machine fail to be a decider, as deciders must
>>>> answer in bounded time, and until you invent a time machine, you can't
>>>> do unbounded work in bounded time.
>>>
>>> Is that right?  Deciders must answer in finite time, but is there
>>> actually a bound on how long this time can be?  If so, what is it?
>>>
>>
>> It is not stated, but it it DOES answer in a finite time, then that
>> time can be given as the bound.
>
> Wrong. It must be a finite sequence of steps it
> does not matter if each step takes a million years.
>

"time" in Conputation theory is measured in Steps, not Seconds.

[Richard Damon]

Well, I AM proficient in probably more programming languages than you
actually know.

So, I have said otherwise.

I am still employed at a job where programming is a major part of my job
and considered the "go to" person for handling problems.

[Richard Damon]

Sure I do, the conplete state of execution of the program is the
collection of ALL the information under the "control" of the program.

Since the "state" you called repeated occred at a differet level of
simulation then the origianl, the state of the whole program is NOT the
same, as the data reguarding simulation levels differs.

YOU don't seem to know what it means, since you use it incorrectly.

[olcott]

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

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"

[olcott]

The exact same sequence of instructions is executed
with the exact same data... Dunderhead.

[olcott]

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.

[olcott]

In other words you are a Jack of some trades and a master of none.

[Richard Damon]

That isn't the "state"

DUNDERHEAD.

Think of what a Finite STATE machine is.

It isn't how you got there, it is getting to the same place.

Your CAN'T have the program get to the exact same sequence of
instructions executed twice, as the second time you still have the first
time on the list

[Richard Damon]

Nope.

Just your admission of total ignorance.

>
> Naive set theory presumed that its definition of {set}
> was correct and ZFC proved that it was not correct.

Nope.

Russel's paradox proved that it was incorrect.

ZFC showed a different basis to make sets.

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

Nope.

Just shows that H can't do a correct simulation.

[Richard Damon]

Right, If H can CORRECTLY determine that a CORRECT SIMULATION of the
input can not stop running.

Since the program on the input does stop running (since it is D built on
the H that gives the claimed answer) the correct simulation of that
program will halt running at the final state, and thus H can not
correctly determine that it doesn/t.

Of course, since you admit that you don't understand the correct meaning
of a correct simulation, you can't understand what Professor Sipser said.

[Richard Damon]

Nope. It seems you are a Jack of no trades and a master of lying.

Who comes to YOU to solve problems.

[olcott]

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.

[olcott]

And what everyone else is simply not bright enough to
understand is that every undecidable input proves
the each decision problem with undecidable input
is itself incorrect.

> ZFC showed a different basis to make sets.
>

Likewise a different basis to decide halting also
eliminates undecidability.

Undecidability always means that the decision problem is wrong.

[olcott]

It is not about solving arbitrary problems it is about
being able to perfectly understand how execution traces
work and how they can be verified as correct.

You are clearly not very good at that problem.

[Richard Damon]

On 1/19/24 5:29 PM, olcott wrote:
> On 1/19/2024 3:57 PM, Richard Damon wrote:

>> On 1/19/24 4:47 PM, olcott wrote:
>>> On 1/19/2024 3:34 PM, Richard Damon wrote:

>>>> On 1/19/24 1:36 PM, olcott wrote:
>>>>> On 1/19/2024 11:56 AM, Richard Damon wrote:
>>>>>> On 1/19/24 12:17 PM, olcott wrote:
>>>>>>> On 1/19/2024 11:05 AM, Richard Damon wrote:
>>>>>>>> On 1/19/24 11:55 AM, olcott wrote:

>>>>>>>>> On 1/19/2024 10:44 AM, Richard Damon wrote:

>>> void Infinite_Loop()
>>> {
>>>    HERE: goto HERE;
>>> }
>>>
>>> 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.
>>>

>>> The freaking repeated state proves non-halting the first freaking time
>>> that it is encountered.
>>>
>>
>> That isn't what I said. The fact that the aborted simulation didn't
>> reach an end, doesn't prove BY ITSELF, that the input is non-halting.
>>
>
> It is the repeated state that proves non-halting you big dummy.
> You never did any programming did you?
>

But the full state wasn;t repeated, but only showed in different level
of conditional simulation, which doesn't count.

You seem to have never heard of logic and rules.

[Richard Damon]

Nope, undecidable problems are by definition correct, but then you don't
actually seem to know what an undecidable problem is.

Questions without possible answers are incorrect.

So making a set that contains only those sets that don't contain
themselves are not correct, as such a set can't exist.

The Halting Question is NOT such a question.

>
>> ZFC showed a different basis to make sets.
>>
>
> Likewise a different basis to decide halting also
> eliminates undecidability.

So, your making PO-Computation Theory?

The go post in comp.po-theory about your ideas, where people might care
about them.

>
> Undecidability always means that the decision problem is wrong.
>

Nope.

But again, you don't know what undecidability is, so of course you don't
know that it isn't wrong.

[olcott]

The full state of D was repeated.
The only thing that changed was the stack address.

[Richard Damon]

I think better than you,
How many programs have you had to debug at the assembly level due to
bugs in the compiler?


You don't even understand what a simulation trace of a program should
contain.

You think changing levels of abstraction is correct when looking at the
beahavior of the first level and asking if the simulator is correct.

THe Call to H should be followed by the simulation of the subroutine H.

[olcott]

Then you were wrong when you said:
"Russel's paradox proved that it was incorrect."

It being the definition of the term: {set}.
*You just admitted that definitions can be incorrect*

[Richard Damon]

But since DD(DD) Halts, it can't be showing non-halting behavior.

It just shows that HH is incorrect in presuming that HH will never return.

Of course, this isn't HH's fault, it is the fault of the programmer,
which is YOU.

YOUR the idiot that doesn't understand anything of what you are talking.

You are nothing but an ignorant hypocritical pathological lying idiot.

[olcott]

Because of your ADHD I may need to say this hundreds of times
before you actually pay attention to the words.

DD(DD) relies on its HH(DD,DD) to terminate the recursive
simulation that it specifies.

DD simulated by HH cannot do that. This proves that
they are not the same computation.

[Richard Damon]

No, the second set of "State" wasn't a state of the program, but a state
of the simulated simulated program inside the first simulation..

The actual program being simulated did not repeat state, but will
eventually ,when simulated farther by an actual correct simulator abort
its simulation (which your decider was simulating) and return to the top
level simulated program and halt.

When you have conditional simulation (which you do) then level of
simulation is part of your state, so it wasn't "repeated".

[olcott]

The fact that I wrote the x86utm operating system where
HH correctly simulates itself simulating DD and bases
its halt status decision on the x86 machine code trace
(My own program decodes the control flow machine code).
proves that I know these things very well.

I have been working in the 8088 assembly language since
it was new. The x86 language with flat addressing is
much better. 64k segmented architecture was a bit of
a nightmare.

[olcott]

Only the x86utm operating system simulates the program
HH simulates the C function named HH. A C function <is>
a microcosm of a program.

[Richard Damon]

Russels paradox proved that the rule of naive set theory were incorrect
in the sense that they created in logic system that fixed the problem.

>
> It being the definition of the term: {set}.
> *You just admitted that definitions can be incorrect*
>
>

definition can create incorrect logic system.

That means you need to abandon the system they defined.

You don't get to change the definition and still be working in the same
theory.

Note, Naive set theory was proven to be "incorrect" and replaced by ZFC
set theory.

Most people accepted, once Russel's paradox was understood, that Naive
set theory was broken and needed a replacement.

If you want to do something similar for Computation Theory (or Logic
Theory) first you must demonstrate to the bulk of its users that it is
fundamentally broken.

Then you need to show your revised definitions and what you can actually
show comes out of them.

Note, ZFC produce a LOT of background work showing the results of their
new set theory. Which helped peopl accept it.

You have yet to convince anyone that the failure to build Halt Deciders
actually hurts Computation Theory and just totally breaks it.

You also haven't clearly laid out our new rules, or show how to derive a
full system out of them.

So, you have NOTHING but egg on your face.

[Richard Damon]

So?

HH is part of DD, so that is allowed.

> DD simulated by HH cannot do that. This proves that
> they are not the same computation.
>

But that is only because HH can't simulate the input properly.

HH's job is to figure out what happens when you run DD(DD).

The boss doesn't care HOW it gets done, just that it gets done.

HH, by its claim to be a Halt Decider, claim to be able to handle ANY
input, even one that have studied its tapes.

You don't seem to understand that the DEFINITION of the Halting Problem
is that the decider needs to answer about the compuation describe by its
input.

that is ANY compuation.


DD(DD) is a computation, To be a Halt Decider, HH needs to be able to
answer about THAT computation.

The fact that it can't, just proves that HH is not a (Correct) Halt Decider.

PERIOD.

if H(DD,DD) isn't how you ask about DD(DD), why did you make DD call HH
that way, as the definition of the "patholgical program" is to ask the
claimed Halt Decider to decide on the machine on the description of the
machine. (that is, on DD(DD))

So, either you lied when you said DD was designed by the rules, or you
lied when you said that the input doesn't ask that.

Either way, you LIED, and your proof is just invalid.

[Richard Damon]

But HH is suppose to simulate the PROGRAM that is given.

You don't even seem to understand the definition of the problem.

[André G. Isaak]

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é

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

[Richard Damon]

I started on 8088 assembly code in 1975, and most of the variaions ov
x86 through the years, so you don't have more experiance than me.

As A High School Sophomore, I had teachers come to me for help with
assemble language programming as I had learned if for our school
computer. I don't think you can claim to have better experiance tham me.

Your problem isn't in the instruction by instruction simulation (but
then that isn't, as you admit, your code) but on your interpreation of it.

You don't seem to understand the fundamentals of the problem, as I
pointed out years ago.

Your Halt Decider needs to take in a full independent program to decide
on, not a function in its own address space, and especially not a
program that reuses code that is part of your decider.

There is a reason that the proof have the program use a COPY of the
decide and not have it call the same copy of the code as is deciding on
it, because that just doesn't match the definiton of the problem.

The decider needs to be give a description of the WHOLE program, a
description that is complete enough to define ALL the behavior of the
program, so the input program D must include its own copy of H.

Since yours doesn't, at least not the way you claim it is give, your
setup is just not proper to talk about the theorem.

It is this sort of stupid mistakes that have made you waste the last 2
decades of you life on a LIE.

[olcott]

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.

The easily verified fact that DD simulated by HH cannot possibly
reach its own simulated final state conclusively proves that DD
does not halt.

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

[Richard Damon]

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

[olcott]

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.

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

[Richard Damon]

It can't in its simulation, but an actually correct simulation of the
input, which HH doesn't do, can.

You start with the INCORRECT assumption that HH will do a correct
simulation. That assumption can only hold if HH never aborts its
simulation, and then it can never answer.

Your presumption of an HH that correctly simulates its input until it
correctly determines that the actual behavior of the program given as an
input is non-halting is an impossible presumption, just like the barber
that shaves everyone that does not shave themselves, or the set that
contains all sets that do not contain themselves.

Now, since we KNOW that HH(DD,DD) returns 0, from THAT known behavior,
we can just look at the code for DD and see that it will halt, or just
correctly simulate the input with a UTM.

Remember, programs are what there code defines them to be, and once it
is a program, its behavior for a given input can not change without
changing the code of the program (or a hidden input, which isn't allowed
for a computation).

[olcott]

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

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]

[Richard Damon]

i.e. I'm not falling for your strawman and are panicing as badly as your
buddy Trump.

Since you ADMIT that DD(DD) halts, and it does that because DD is built
on the only version of HH that matters, the one that answers, and that
version does abort its simulation at the point you show, it is thus
clear that a CORRECT simulation of this input by a real simulator that
didn't abort when your INCOMPLETE (and thus incorrect) simulation in HH
did, would show that the simulator call in the first simulation of the
input DD, would when this HH printed

New slave_stack,

would have outputed

Begin Local Halt Decider Simulation.

Then when you top level HH outputed

Local Hat Decider: Recursive Simulation Detected,

(but the HHH doesn't abort its simulation, so it wouldn't print that
message, the simulated HH would output

New Slave_stack

Then it would put out a third copy of the instructions (remember, this
is the trace of a real UTM or an HHH that was changed not to abort, but
DD still calls HH) followd by the simulated HH saying

Local Halt Decider: Recursion Simulation Detected, Simulation Stoppeed

And then the trace of the end of DD to the final return.

If you try to say you can't change the simulator looking at the input to
HHH or a UTM without changing DD to use it, then your system is just
broken and you are just admitting that. BY DEFINITION, the "pathological
program" uses the ONE decider that is claimed to be the one to get the
correct answer, and the definition of a "Correct Simulation" is not a
function of the simulator used, but of the program being simulated ALONE.

Any complaints just proves you to be a LIAR.

[olcott]

Trump is a Hitler wanna bee.

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

*OR YOU FAIL*
*OR YOU FAIL*
*OR YOU FAIL*
*OR YOU FAIL*

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

Begin Local Halt Decider Simulation Execution Trace Stored at:113027

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============

[immibis]

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?

[immibis]

On 1/20/24 02:14, olcott wrote:
>
> It is not about solving arbitrary problems it is about
> being able to perfectly understand how execution traces
> work and how they can be verified as correct.
>
> You are clearly not very good at that problem.
>

And how they can be verified as incorrect.

H has some instructions which tell it when to halt, but the simulator
dishonestly ignores these instructions.

[immibis]

On 1/20/24 00:33, olcott wrote:

> On 1/19/2024 5:03 PM, Richard Damon wrote:
>> On 1/19/24 5:29 PM, olcott wrote:
>>>
>>> It is the repeated state that proves non-halting you big dummy.
>>> You never did any programming did you?
>>>
>>

>> And what repeated state is that?
>>
>
> You don't even know what the term means.
>

You don't know what it means. The execution trace is part of the state,
but is dishonestly ignored by the code that checks for repeated states.

[immibis]

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.

[immibis]

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?

[immibis]

On 1/20/24 00:30, olcott wrote:
> On 1/19/2024 4:58 PM, Alan Mackenzie wrote:
>> In comp.theory olcott <polc...@gmail.com> wrote:
>>
>> [ .... ]
>>

>>> void Infinite_Loop()
>>> {
>>>    HERE: goto HERE;
>>> }
>>
>>> 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.
>
> 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.
>

The quote is correct, and your simulator is incorrect.

[immibis]

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.