Is the notion of a simulating halt decider correct ?

[olcott]

Do you agree with professor Sipser or the many dozens of people that
reject the notion of a simulating halt decider?

Disagreement requires that an error with (a) or (b) or (c) exists
or that (d) is not a necessary consequence of (a)(b)(c)

The only rebuttal of my work in thousands of reviews for the last two
years is the rejection of this notion of a simulating halt decider.

*H correctly simulates its input D until H correctly determines*
*that its simulated D would never stop running unless aborted*

(a) A halt decider must report on the actual behavior specified by its
input.

(b) The definition of a universal Turing machine (UTM) specifies that
the correct simulation of a machine description provides the actual
behavior specified by this machine description.

(c) A correctly simulated input that would never stop running unless
aborted does specify non-halting behavior.

(d) Therefore a simulating halt decider does correctly determine the
halt status of its input.

void D(void (*x)())
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H(D, D));
}

Once this notion is accepted then the fact that H correctly determines
the halt status of D is verified entirely on the basis of software
engineering.

MIT Professor Michael Sipser specifically approved this verbatim
definition as the abstract to this paper. (He neither reviewed nor
approved anything else).

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.

*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof



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

[wij]

On Wednesday, November 16, 2022 at 11:31:20 PM UTC+8, olcott wrote:
> ...

You don't even know what a program halts means. You need first define what
a program P halts means.
To be more specific for a person has study this subject for 18 years:
If one has two programs P(...), and H(...), how do we determinate P and H halt or not?

[olcott]

I already defined non-halting for a simulating halt decider:

*H correctly simulates its input D until H correctly determines*
*that its simulated D would never stop running unless aborted*

Thus halting for a simulating halt decider would be:
*H correctly simulates its input D until D reaches its own*
*last instruction (final state) and terminates normally*

The above definition divides up the set of machine descriptions into the
exact same halting and non-halting subsets that the conventional notion
of a halt decider would except for inputs having a pathological
relationship to their halt decider.

In this case the actual behavior of the D correctly simulated by H
indicates that D specifies recursive simulation to H such that D never
stops running unless H aborts its simulation.

[wij]

On Thursday, November 17, 2022 at 1:36:23 AM UTC+8, olcott wrote:
> On 11/16/2022 11:15 AM, wij wrote:
> > On Wednesday, November 16, 2022 at 11:31:20 PM UTC+8, olcott wrote:
> >> ...
> >
> > You don't even know what a program halts means. You need first define what
> > a program P halts means.
> > To be more specific for a person has study this subject for 18 years:
> > If one has two programs P(...), and H(...), how do we determinate P and H halt or not?
> I already defined non-halting for a simulating halt decider:
> *H correctly simulates its input D until H correctly determines*
> *that its simulated D would never stop running unless aborted*
> Thus halting for a simulating halt decider would be:
> *H correctly simulates its input D until D reaches its own*
> *last instruction (final state) and terminates normally*
>
> The above definition divides up the set of machine descriptions into the
> exact same halting and non-halting subsets that the conventional notion
> of a halt decider would except for inputs having a pathological
> relationship to their halt decider.
>
> In this case the actual behavior of the D correctly simulated by H
> indicates that D specifies recursive simulation to H such that D never
> stops running unless H aborts its simulation.
>

To be further more specific for a person has study this subject for 18 years
(you might not understand English better than I):
HOW DO YOU PROVE (SHOW YOUR PROOF) P AND H HALT?

[olcott]

The important part and the only source of disagreement is how I show
that D correctly simulated by H does not halt.

Every rebuttal to this claim is the strawman error of changing the
subject away from D correctly simulated by H.

void D(void (*x)())
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

int main()
{

D(D);
}

_D()
[000019e3] 55 push ebp
[000019e4] 8bec mov ebp,esp
[000019e6] 51 push ecx
[000019e7] 8b4508 mov eax,[ebp+08]
[000019ea] 50 push eax
[000019eb] 8b4d08 mov ecx,[ebp+08]
[000019ee] 51 push ecx
[000019ef] e88ff9ffff call 00001383
[000019f4] 83c408 add esp,+08
[000019f7] 8945fc mov [ebp-04],eax
[000019fa] 837dfc00 cmp dword [ebp-04],+00
[000019fe] 7402 jz 00001a02
[00001a00] ebfe jmp 00001a00
[00001a02] 8be5 mov esp,ebp
[00001a04] 5d pop ebp
[00001a05] c3 ret
Size in bytes:(0035) [00001a05]

When H correctly simulates D it finds that D remains stuck in recursive
simulation

H: Begin Simulation Execution Trace Stored at:112afc
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000019e3][00112ae8][00112aec] 55 push ebp // begin D
[000019e4][00112ae8][00112aec] 8bec mov ebp,esp
[000019e6][00112ae4][00102ab8] 51 push ecx
[000019e7][00112ae4][00102ab8] 8b4508 mov eax,[ebp+08]
[000019ea][00112ae0][000019e3] 50 push eax // push D
[000019eb][00112ae0][000019e3] 8b4d08 mov ecx,[ebp+08]
[000019ee][00112adc][000019e3] 51 push ecx // push D
[000019ef][00112ad8][000019f4] e88ff9ffff call 00001383 // call H
H: Infinitely Recursive Simulation Detected Simulation Stopped

We can see that the first seven instructions of D simulated by H
precisely match the first seven instructions of the x86 source-code of
D. This conclusively proves that these instructions were simulated
correctly.

Anyone sufficiently technically competent in the x86 programming
language will agree that the above execution trace of D simulated by H
shows that D will never stop running unless H aborts its simulation of D.

H detects that D is calling itself with the exact same arguments that H
was called with and there are no conditional branch instructions from
the beginning of D to its call to H that can possibly escape the
repetition of this recursive simulation.

[wij]

Let's begin with simpler English: HOW DO YOU PROVE YOUR HALT DECIDER H HALTS?

[Mr Flibble]

On Wed, 16 Nov 2022 11:36:19 -0600
olcott <non...@beez-waxes.com> wrote:

> On 11/16/2022 11:15 AM, wij wrote:
> > On Wednesday, November 16, 2022 at 11:31:20 PM UTC+8, olcott wrote:
> >
> >> ...
> >
> > You don't even know what a program halts means. You need first
> > define what a program P halts means.
> > To be more specific for a person has study this subject for 18
> > years: If one has two programs P(...), and H(...), how do we
> > determinate P and H halt or not?
>
> I already defined non-halting for a simulating halt decider:
> *H correctly simulates its input D until H correctly determines*
> *that its simulated D would never stop running unless aborted*
>
> Thus halting for a simulating halt decider would be:
> *H correctly simulates its input D until D reaches its own*
> *last instruction (final state) and terminates normally*
>
> The above definition divides up the set of machine descriptions into
> the exact same halting and non-halting subsets that the conventional
> notion of a halt decider would except for inputs having a
> pathological relationship to their halt decider.

The pathological relationship (i.e. the "Impossible Program"
contradiction) is indeed irrelevant: the problem is the input
referencing the decider in the first place; nobody engaging with this
newsgroup seems to understand this simple fact except you and me.

This is what happens when you learn things by rote: you lose your
critical thinking skills.

It is a fact that the [Strachey 1965] contradiction and all the Halting
Problem proofs based on it are a nonsense as Olcott has shown that an
input CANNOT pass itself to a decider.

/Flibble

[olcott]

No one disagrees with this part. If you want to see that
H halts you can Run it and see for yourself:
https://liarparadox.org/2022_11_11.zip

Halt7out.txt shows the results of H(D,D).

[olcott]

Yes back in 2004 I pointed out that this has the same effect as the liar
paradox referencing itself.

> This is what happens when you learn things by rote: you lose your
> critical thinking skills.
>

Professor Sipser has many published works in the theory of computation,
thus knows these things first-hand, thus not by mere rote memorization.
Michael Fredric Sipser: https://dl.acm.org/profile/81100333940

> It is a fact that the [Strachey 1965] contradiction and all the Halting
> Problem proofs based on it are a nonsense as Olcott has shown that an
> input CANNOT pass itself to a decider.
>
> /Flibble
>

[wij]

On Thursday, November 17, 2022 at 2:22:55 AM UTC+8, olcott wrote:
> > ...

> > To be further more specific for a person has study this subject for 18 years
> > (you might not understand English better than I):
> > HOW DO YOU PROVE (SHOW YOUR PROOF) P AND H HALT?
> >
> > Let's begin with simpler English: HOW DO YOU PROVE YOUR HALT DECIDER H HALTS?
> No one disagrees with this part. If you want to see that
> H halts you can Run it and see for yourself:
> https://liarparadox.org/2022_11_11.zip
>
> Halt7out.txt shows the results of H(D,D).

You mean your reviewer shall not ask such question: "No one disagrees with this part....see it yourself..."?

Can you answer the very basic question: Does (your) H halts?

[olcott]

Yes and everyone agrees that my H halts.

[Richard Damon]

On 11/16/22 12:36 PM, olcott wrote:
> On 11/16/2022 11:15 AM, wij wrote:
>> On Wednesday, November 16, 2022 at 11:31:20 PM UTC+8, olcott wrote:
>>> ...
>>
>> You don't even know what a program halts means. You need first define
>> what
>> a program P halts means.
>> To be more specific for a person has study this subject for 18 years:
>> If one has two programs P(...), and H(...), how do we determinate  P
>> and H halt or not?
>
> I already defined non-halting for a simulating halt decider:
>   *H correctly simulates its input D until H correctly determines*
>   *that its simulated D would never stop running unless aborted*

So, you admit that you aren't working on the Halting Problem?

Since that ISN'T the actual definition of Halting.

All you have proven is that your H is a correct POOP decider.

>
> Thus halting for a simulating halt decider would be:
>   *H correctly simulates its input D until D reaches its own*
>   *last instruction (final state) and terminates normally*
>
> The above definition divides up the set of machine descriptions into the
> exact same halting and non-halting subsets that the conventional notion
> of a halt decider would except for inputs having a pathological
> relationship to their halt decider.
>
> In this case the actual behavior of the D correctly simulated by H
> indicates that D specifies recursive simulation to H such that D never
> stops running unless H aborts its simulation.
>

And you can prove that it is wrong by adding a call to D(D) after the
call to H(D,D) and seeing that it returns.

If you want to claim that the correct simulation by H of this input has
different behavior, please point out the first x86 instruction ACTUALLY
CORRCTLY SIMULATED by H that differs from the behavior of the direct
execution of D(D) in the call from main.

Note, one problem that you run into is that your H doesn't actually
simulate all of the program D, since the actual execution of D when it
executes that call to H(D,D) continues inside H, while your
decider/simulator apparently is unable (or unwilling) to simulate the
code of H, even when it is part of the program D that is its input. This
means that since it has an incorrect model of what H actually does, it
makes an error when it simulated it.

Note, when you do your "set" concept, you start looking at wrong inputs,
as D ALWAYS calls the original H, the one that aborts at the first call
to H(D,D) and returns 0, which is NOT the behavior assumed by H.

[Richard Damon]

Which is NOT a proven criteria for non-halting when H is a decider that
might abort its simulation.

The fact that there are conditional instrucions in the H that D calls,
is enough to provide the "escape" from the infinite loop.

This has been pointed out, and your refusal to provide any actual proof
of your statement shows your ignorance and duplicity on the subject.

[Richard Damon]

[Richard Damon]

And what is wrong with building a machine from your Halt Decider?

If it is a Turing Machine Equivalent, you can build another Turing
Machine Equivalent from it with the modifications as described in the proof.

All you are showing is that your decider either can't decide ALL Turing
Machine Equivalents (Which is the statement of the Halting THeorem) or
that you "Halt Decider" isn't actually built as a Turing Machine
Equivalent, and thus can't actually be the needed Decider.

If you are claiming to have a "Higher Class" of machine, that is
actually computable, but not equivalent to a Turing Machine, you need to
actually show what you did, as that would be a major revelation.

[Richard Damon]

Except it isn't. Maybe your incorrect reformulation with intertwined
code creates the equivalent of the Liar's Paradox, but the original doesn't.

Your inability to see the difference reveals your ignorance.

[wij]

On Thursday, November 17, 2022 at 3:33:53 AM UTC+8, olcott wrote:
> On 11/16/2022 1:11 PM, wij wrote:
> > On Thursday, November 17, 2022 at 2:22:55 AM UTC+8, olcott wrote:
> >>> ...
> >>> To be further more specific for a person has study this subject for 18 years
> >>> (you might not understand English better than I):
> >>> HOW DO YOU PROVE (SHOW YOUR PROOF) P AND H HALT?
> >>>
> >>> Let's begin with simpler English: HOW DO YOU PROVE YOUR HALT DECIDER H HALTS?
> >> No one disagrees with this part. If you want to see that
> >> H halts you can Run it and see for yourself:
> >> https://liarparadox.org/2022_11_11.zip
> >>
> >> Halt7out.txt shows the results of H(D,D).
> >
> > You mean your reviewer shall not ask such question: "No one disagrees with this part....see it yourself..."?
> >
> > Can you answer the very basic question: Does (your) H halts?
> Yes and everyone agrees that my H halts.

Then, prove it. and what is the definition of 'halt'?
Because I said the author of 2022_11_11.zip does not understand what halt is
to talk about a halt decider.

[olcott]

Shows that H returns 0 to main();

[wij]

On Thursday, November 17, 2022 at 10:54:59 AM UTC+8, olcott wrote:
> On 11/16/2022 7:44 PM, wij wrote:
> > On Thursday, November 17, 2022 at 3:33:53 AM UTC+8, olcott wrote:
> >> On 11/16/2022 1:11 PM, wij wrote:
> >>> On Thursday, November 17, 2022 at 2:22:55 AM UTC+8, olcott wrote:
> >>>>> ...
> >>>>> To be further more specific for a person has study this subject for 18 years
> >>>>> (you might not understand English better than I):
> >>>>> HOW DO YOU PROVE (SHOW YOUR PROOF) P AND H HALT?
> >>>>>
> >>>>> Let's begin with simpler English: HOW DO YOU PROVE YOUR HALT DECIDER H HALTS?
> >>>> No one disagrees with this part. If you want to see that
> >>>> H halts you can Run it and see for yourself:
> >>>> https://liarparadox.org/2022_11_11.zip
> >>>>
> >>>> Halt7out.txt shows the results of H(D,D).
> >>>
> >>> You mean your reviewer shall not ask such question: "No one disagrees with this part....see it yourself..."?
> >>>
> >>> Can you answer the very basic question: Does (your) H halts?
> >> Yes and everyone agrees that my H halts.
> >
> > Then, prove it. and what is the definition of 'halt'?
> > Because I said the author of 2022_11_11.zip does not understand what halt is
> > to talk about a halt decider.
>
> Halt7out.txt shows the results of H(D,D).
> Shows that H returns 0 to main();

So, you mean this? That H(D,D) returns x to main() means "H halts"?
int main() {
H(D,D);
}

So, that D returns to main() means "D halts"?
int main() {
D(D);
}

[olcott]

NO ONE HERE UNDERSTANDS THIS
It is impossible to have the necessary consequence of three premises to
be false when the premises are true.

H correctly simulates its input D until H correctly determines that its

simulated D would never stop running unless aborted

(a) A halt decider must report on the actual behavior specified by its
input.

(b) The definition of a universal Turing machine (UTM) specifies that
the correct simulation of a machine description provides the actual
behavior specified by this machine description.

(c) A correctly simulated input that would never stop running unless
aborted specifies non-halting behavior.

(d) H correctly determines that D specifies a non-halting behavior.

{a,b,c} ⊨ (d) // intended as notation for sound deduction

[DFS]

On 11/16/2022 10:31 AM, olcott wrote:


Is this you?


"Man believed child porn was legal because 'he was God,' authorities say"

https://www.ketv.com/article/man-believed-child-porn-was-legal-because-he-was-god-authorities-say/7652218

[wij]

You cannot avoid the basic question "what does a program P halt mean?" to show
you understand the HP subject.
[quote]

>> Halt7out.txt shows the results of H(D,D).
>> Shows that H returns 0 to main();
So, you mean this?

int main() {
H(D,D);
}
That H(D,D) returns to main() means "H halts"?

[olcott]

*H correctly simulates its input D until D reaches its own*
*last instruction (final state) and terminates normally*

[olcott]

*H correctly simulates its input D until D reaches its own*
*last instruction (final state) and terminates normally*

[wij]

You said "H returns 0 to main()" means "H halts".
So, "D returns to main()" means "D halts". Do you agree?

int main() {
D(D);
}

[Richard Damon]

But since (d) doesn't actually follow from (a), (b), and (c) it is a
false premise.

(a), (b), and (c) are all conditioned on there being a correct
simulation of the input. (d) requries that you first prove the H
actually DOES a correct simulaiton PER THE DEFINITION OF A UTM.

Changing the definition mid-proof just shows that you LIE and are too
stupid to understand correct logic.

>
> H correctly simulates its input D until H correctly determines that its
> simulated D would never stop running unless aborted
>
> (a) A halt decider must report on the actual behavior specified by its
> input.

Yes, and that means that A Halt Decider needs to return Halting, if the
machine that its input represents, when given the input represented in
the input, would Halt.

That is the DEFINITION of "the actual behavior specified by its input".

Since D(D) will Halt since H(D,D) returns 0 (indicating non-halting),
the H(D,D) returning 0 can not be correct.

>
> (b) The definition of a universal Turing machine (UTM) specifies that
> the correct simulation of a machine description provides the actual
> behavior specified by this machine description.

Right, that is a Tautology, as the DEFINITION of "Correct Simulation"
means that it provides the actual behavior of the machine it is
simulating. (Not that it correctly simulates the x86 instructions that
it processes).

PARTIAL simulations are NEVER the equivalent of a UTM simumulation.

>
> (c) A correctly simulated input that would never stop running unless
> aborted specifies non-halting behavior.

Right, but "Correctly Simulated" here means a simulation that is dond by
a UTM, which this H is not, since it aborts its simulation.

Thus, H has NOT "correctly Simulated" this input.

When you change H to be a UTM, you also change the input, so you are not
simulating the same input.

Remember, D is defined not to call "H", but to call the machine that
gives the right answer about it. That is the H that aborts its
simulation and returns 0 when applied to the input D,D

Your changing the definition of "H" mid proof just shows your ignorance
of the rules of logic, and that you are just lying about what you are doing.

>
> (d) H correctly determines that D specifies a non-halting behavior.
>

Doesn't follow. You haven't established that H does a correct

> {a,b,c} ⊨ (d) // intended as notation for sound deduction
>

And that statement is FALSE, since (d) does NOT follow from (a), (b), (c).

You need to still establish that H HAS correctly determined the behavior
of a UTM simulation of THIS input to be non-halting.

It is impossible to prove that the UTM simulation of the input to H is
non-halting, since it has been proven that it is Halting.

The proof you have provided elsewhere fails because it shows the UTM
simulation of a DIFFERENT input, where D calls a DIFFERENT H.

Just shows you don't understand what a program is.

THe fact that you can't tell the difference between the different
machines you create just shows that you lack the mental ability to
correctly reason.

[Ben Bacarisse]

wij <wyni...@gmail.com> writes:

> You said "H returns 0 to main()" means "H halts".
> So, "D returns to main()" means "D halts". Do you agree?

Do you think you will be able to get through to PO when other have
failed to do in more than *18 years* of posting?

PO has clearly stated that he has extended the definition of non-halting
to include some halting computations:

"A non-halting computation is every computation that never halts
unless its simulation is aborted.

This maps to every element of the conventional halting problem set of
non-halting computations and a few more."

And when asked about about H(P,P) == false, PO stated:

"Yes that is the correct answer even though P(P) halts."

Do you really want to argue about that? He's come clean. All recent
posts are sophistry.

If you can consider the matter closed, consider just letting him post
into to the void. Of course if you enjoy these threads, then who am I
to stop your fun?

--
Ben.

[olcott]

It is dishonest of you to quote views that I have had several
years ago that have since been updated.

Here it halting and non-halting for a simulating halt decider:

*H correctly simulates its input D until D reaches its own*
*last instruction (final state) and terminates normally*

*H correctly simulates its input D until H correctly determines*
*that its simulated D would never stop running unless aborted*

This divides up the set of machine descriptions into the same
subsets as the conventional notion of a halt decider except
that the conventional pathological input becomes decidable as
non-halting.

Because halt deciders compute the mapping from their inputs to
an accept or reject state it is dishonest of you to slip in
the behavior of non-inputs.

[olcott]

Here it halting and non-halting for a simulating halt decider:

*H correctly simulates its input D until D reaches its own*
*last instruction (final state) and terminates normally*

*H correctly simulates its input D until H correctly determines*
*that its simulated D would never stop running unless aborted*

This divides up the set of machine descriptions into the same
subsets as the conventional notion of a halt decider except
that the conventional pathological input becomes decidable as
non-halting.

Because halt deciders compute the mapping from their inputs to
an accept or reject state it is dishonest of you to slip in
the behavior of non-inputs.

[Mr Flibble]

If it is Olcott then that would be a worrying development and I would
have to cease replying to his posts.

/Flibble

[Mikko]

On 2022-11-16 15:31:17 +0000, olcott said:

> Do you agree with professor Sipser or the many dozens of people that
> reject the notion of a simulating halt decider?

Agree about what?

It's not possible to answer the question as you didn't define what do you
mean with "reject the notion" nor which statement of Professor Sipser do
you mean.

Mikko

[olcott]

You cannot correctly answer a complex question by glancing at a couple
of words as the basis for a rebuttal.

MIT Professor Michael Sipser specifically approved this verbatim
definition as the abstract to this paper. (He neither reviewed nor
approved anything else).

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.

*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof


Now we carefully analyze the key portion of that paragraph:

*H correctly simulates its input D until H correctly determines*
*that its simulated D would never stop running unless aborted*

(a) A halt decider must report on the actual behavior specified by its
input.

(b) The definition of a universal Turing machine (UTM) specifies that
the correct simulation of a machine description provides the actual
behavior specified by this machine description.

(c) A correctly simulated input that would never stop running unless

aborted does specify non-halting behavior.

(d) Therefore a simulating halt decider does correctly determine the
halt status of its input.

{a,b,c} ⊨ (d) // intended as notation for sound deduction

[wij]

I ask for a consistent,simple,basic question (many times):
"What does a program (P,H,...) halts mean?".
You reply with lots of non-topic theory and now saying I am dishonest.

All of these showed that olcott don't even understand what 'halt' is to
address the HP issue.

[Richard Damon]

On 11/17/22 11:14 AM, olcott wrote:
> On 11/17/2022 7:21 AM, Ben Bacarisse wrote:
>> wij <wyni...@gmail.com> writes:
>>
>>> You said "H returns 0 to main()" means "H halts".
>>> So, "D returns to main()" means "D halts". Do you agree?
>>
>> Do you think you will be able to get through to PO when other have
>> failed to do in more than *18 years* of posting?
>>
>> PO has clearly stated that he has extended the definition of non-halting
>> to include some halting computations:
>>
>>    "A non-halting computation is every computation that never halts
>>     unless its simulation is aborted.
>>
>>     This maps to every element of the conventional halting problem set of
>>     non-halting computations and a few more."
>>
>> And when asked about about H(P,P) == false, PO stated:
>>
>>    "Yes that is the correct answer even though P(P) halts."
>>
>> Do you really want to argue about that?  He's come clean.  All recent
>> posts are sophistry.
>>
>> If you can consider the matter closed, consider just letting him post
>> into to the void.  Of course if you enjoy these threads, then who am I
>> to stop your fun?
>>
>
> It is dishonest of you to quote views that I have had several
> years ago that have since been updated.

Unless you FORMALLY repudiate them it is still a position you have held.

And, you still hold it, as P(P) DOES Halt, but you say that H(P,P) == 0
is correct. You just change the background story on why you hold that
view. It seems now you are just saying that the correct simulation of
P(P) done by H doesn't need to match the actual behavior of P(P)
directly run, which is a violation of the definiton of "Correct
Simulation" as defined by a UTM, and you can't point out where the
simulation actually diverges for the direct execution, because it
actually doesn't.

The "diverganence" in you mind seems to occur in the part of the
simulaiton of P where you don't actually do a x86 instruction simulation
of P because you don't treat the function H as part of the program P
that you are processing.

>
> Here it halting and non-halting for a simulating halt decider:

And by changinge the definition, you are just admitting that Simulating
Halting Deciders are NOT actually Halt Deciders and you aren't working
on the Halting Problem but on Peter Olcotts Other Problem (POOP).

You H may be a correct POOP decider, but it isn't a valid Halt Decider.

FAIL.

>   *H correctly simulates its input D until D reaches its own*
>   *last instruction (final state) and terminates normally*
>
>   *H correctly simulates its input D until H correctly determines*
>   *that its simulated D would never stop running unless aborted*

Except that it DOESN'T do this.

Note, "Until H correct determines ... " is NOT necessarily a computable
function, so your definition is a category error, and thus so is your H.

You are basically hiding in your logic the assumption that you can
correctly proven Halt Deciding. That is a classic FALLACY and make you
arguement INVALID.

>
> This divides up the set of machine descriptions into the same
> subsets as the conventional notion of a halt decider except
> that the conventional pathological input becomes decidable as
> non-halting.

And the H on one side answers about a P on the other side, even though
that P isn't the D that this H is answering about, so it is WRONG.

>
> Because halt deciders compute the mapping from their inputs to
> an accept or reject state it is dishonest of you to slip in
> the behavior of non-inputs.
>

Right, so it needs to map the behavior of the P that it is given, which
calls an H that does abort its simulation because it also things it has
proven that result, and that makes the P actually Halt.

Thus, since a Halt Decider is a SPECIFIC set of code, and thus its input
is a SPECIFIC set of code, if we fix one one of the deciders you call
corrrect, and call it Hc, and then make the P based on IT, and call it
Pc, then the question is about Hc(Pc,Pc), and you set argument, since it
needs to look at the ACUTAL input, should be looking at H(Pc,Pc) for all
those H's (which isn't what you arguement does, as it changes the H that
P calls).

If you do THAT, then you will see that any H that simulates its input
enough farther than H does will see that the input Halts.

[Richard Damon]

And NOT of the statements (a), (b), or (c) say H correctly simulated its
input, but were all CONDITIONED on it doing so.

In fact, from (b) we get the definition of a "correct simulation", and H
doesn't do that, in fact, it says that since P(P) Halts, H can NOT
corrected determine that ANY correct simulation of its input would be
non-halting, as it has been shown to Halt.

>
> {a,b,c} ⊨ (d)  // intended as notation for sound deduction
>
>

Except that statement isn't correct, as (d) does NOT follow from (a),
(b), (c).

The simulation Halt Decider NEEDS to correctly determine the results of
a *UTM* simulation (since that is what (b) says determines the results),
not "a simulation that H does", since H CAN'T do a "correct simulation"
by the UTM definition of an input that is non-halting.

[olcott]

I have explained what halting means several
times and you keep ignoring what I say:

THIS IS HALTING

*H correctly simulates its input D until D reaches its own*
*last instruction (final state) and terminates normally*

[wij]

If a program X halts it meant by your halting criteria above. How do we decide
H halts or not?
I am asking for a consistent criteria to mean "X halts". The criteria should apply
both to H and D (and other functions or programs).

[Richard Damon]

Right, but non-halting isn't that this doesn't happen, but that NO
correct simulation of this input can reach the final state, or that THE
complete and correct simulation doesn't reach a final state (even if H
doesn't do it)

The fact that this H doesn't reach the final state doesn't matter.

And if you change H and by doing so change the input, that doesn't count
either.

The P given to H includes the EXACT H that it was based on, so your set
logic needs to not change the H that P calls, so it needs to be a
different copy.

[Richard Damon]

That's his problem, he doesn't have a consistent definition.

One thought about his confusion is he thinks of "Turing Machines" as
"just programs" but they actuall really were thoght of a the actual
computers, and the input tape was "the program" given to that computer.

UTMs are a reasonable model for what we think of as the equivalent of
the General Purpose Computer that you can put in "any program" you want
to run, the program being a description of the dedicated hardware of the
Turing Machine that it represents.

This shows where his design breaks down, as his H can't be built as a
special purpose hardware, as the input program is built of the same sort
of stuff as it is, so H isn't a fixed piece of hardware. His H needs to
be effectively prepared as a piece of the input for the UTM that it runs
on, and combined with the input it is to process, thus it isn't a
"complete program" by itself.

H needs to take in a description that is specified in a seperate virtual
memory space from the decider itself, so the decider COULD be made into
the dedicated hardware of a Turing Machine, and the program to be
decided is just the input. The problem then is that his "cheat" to
detect the recursion doesn't work anymore.

He needs to artificially limit what the "input" to make his arguements
seem plausible, but that just shows that he can't actually use that
system to claim it is possible to meet the original requirements.

[olcott]

D correctly simulated by H (or it is wrong)
reaches its last instruction (final state) and terminates normally.

The directly executed of H
reaches its last instruction (final state) and terminates normally.

[wij]

So, "X halts" means:
Def-1: X correctly simulated by H (or it is wrong) reaches its last instruction (final state) and terminates normally.
Def-2: The directly executed of X reaches its last instruction (final state) and terminates normally.

You are using two different criteria. Def-1 and Def-2 are different.
The problem is: H is also a program. H(H) can occur like

D2(Arg x) {
H(D2,D2);
}

We encounter an ambiguity problem. Does "D2 halts" means the H
inside D2 halts (Def-1) or D2 exits normally (Def-2)?

[Mikko]

On 2022-11-17 17:46:17 +0000, olcott said:

> On 11/17/2022 11:30 AM, Mikko wrote:
>> On 2022-11-16 15:31:17 +0000, olcott said:
>>
>>> Do you agree with professor Sipser or the many dozens of people that
>>> reject the notion of a simulating halt decider?
>>
>> Agree about what?
>>
>> It's not possible to answer the question as you didn't define what do you
>> mean with "reject the notion" nor which statement of Professor Sipser do
>> you mean.
>

> You cannot correctly answer a complex question by glancing at a couple
> of words as the basis for a rebuttal.

Of course not. But 21 words may be enough to see that the question is
ill posed or incomplete. Such question cannot be answered so often the
best option is to ask for clarification.

> MIT Professor Michael Sipser specifically approved this verbatim
> definition as the abstract to this paper. (He neither reviewed nor
> approved anything else).
>
> 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.

So you are asking about agreement with Sipser about this?

Is this somehow connected to the rejection or correctness of the

notion of a simulating halt decider?

Mikko

[Richard Damon]

What is wrong is for H to say that the correct simulation of D never
reaches its last instruction.

You restriciton of "Correct Simulation" to be "By H" is a fallacy, and
makes your requirement the equivalent of the Liars Paradox.

Your change in requirements just PROVES that you are not, and never have
been, actually working on the Halting Problem.

> The directly executed of H
> reaches its last instruction (final state) and terminates normally.
>

And since in the execution of H, when used by D, that final instruction
directly leads to the final instruction of D, D also halts.

Note, in the Turing Machine version, the final state of H reporting
non-halting is also a final state of D.

[DFS]

I'm confident it IS him, given that he 1) refuses to answer me, and 2)
he stated in one of his comp.theory posts that "I am God."

Has he said he's from Nebraska?

local Nebraska news story
https://www.youtube.com/watch?v=wfPPJBYc2B0

[olcott]

Being charged with a crime is not the same as being found guilty of a
crime. In the United States one is innocent until proven guilty.

(8) If an inquiry is made in violation of this subsection, the person
may respond as if the offense never occurred.
https://nebraskalegislature.gov/laws/statutes.php?statute=29-3523

According to paragraph 8 of Nebraska Revised Statute 29-3523
the event that you refer to never occurred.

[olcott]

Because simulating halt deciders only compute the mapping from their
inputs to an accept or reject state on the basis of their correct
simulation of this input it is only the behavior of this simulated input
that is relevant to their halt status decision.

int sum(int x, int y)
{
return x + y;
}

For this same reason only the value of 3 + 4 is relevant to sum(3,4)
only the behavior of D correctly simulated by H is relevant to H(D,D).

[wij]

You did not answer the question (again and again. looks like your English is not good?).
What is the criteria to decide a program halts or not?
We will use it to decide whether H (and D,P, ..., etc) halts or not.

[olcott]

void D(void (*x)())
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

When we apply the above definition of a simulating halt decider H to the
above function D ordinary software engineering code analysis proves that
D specifies a non halting sequence of configuration to H.

[olcott]

The criteria that is correctly applied by a simulating halt decider is
anchored in the behavior of D correctly simulated by H.

It is incorrect for H to in any way take into account the behavior
specified by any finite strings that are not:
(a) Arguments to H and (b) Simulated by H

[wij]

Given that your English is not good, I have to assume something to make progress.
Are you suggesting a program X halts or not is decided by H according to
whatever reason H feels like?

[olcott]

I began college with a college graduate vocabulary.

MIT Professor Michael Sipser has agreed that the following verbatim
paragraph is correct (he has not agreed to anything else):

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.

According to that definition H(D,D) correctly determines that D
specifies a non-halting sequence of configurations.

[Mr Flibble]

Did you download child pornography or not? Sounds like you did in which
case I must cease communications with you and everyone else in this
newsgroup should do the same.

/Flibble

[DFS]

"Investigators reportedly seized 30 VHS tapes of suspected child
pornography and more than 100 magazines and pictures of child pornography."


Did investigators seize child porn material from your house?

[Mr Flibble]

On Fri, 18 Nov 2022 09:27:24 -0500

Just watched that news story. Feel sick. I guess I have a good reason
to stop talking about the fucking Halting Problem in this newsgroup
now; I will view anyone else who doesn't with deep suspicion.

/Flibble

[Mr Flibble]

On Fri, 18 Nov 2022 11:11:37 -0500

Magazines?? WTF.

/Flibble

[DFS]

On 11/18/2022 11:19 AM, Mr Flibble wrote:
> On Fri, 18 Nov 2022 09:27:24 -0500
> DFS <nos...@dfs.com> wrote:
>
>> On 11/17/2022 12:16 PM, Mr Flibble wrote:
>>> On Thu, 17 Nov 2022 00:00:09 -0500
>>> DFS <nos...@dfs.com> wrote:
>>>
>>>> On 11/16/2022 10:31 AM, olcott wrote:
>>>>
>>>>
>>>> Is this you?
>>>>
>>>>
>>>> "Man believed child porn was legal because 'he was God,'
>>>> authorities say"
>>>>
>>>> https://www.ketv.com/article/man-believed-child-porn-was-legal-because-he-was-god-authorities-say/7652218
>>>>
>>>
>>> If it is Olcott then that would be a worrying development and I
>>> would have to cease replying to his posts.
>>>
>>> /Flibble
>>
>>
>> I'm confident it IS him, given that he 1) refuses to answer me, and
>> 2) he stated in one of his comp.theory posts that "I am God."
>>
>> Has he said he's from Nebraska?
>>
>> local Nebraska news story
>> https://www.youtube.com/watch?v=wfPPJBYc2B0
>
> Just watched that news story. Feel sick.

It is sickening. Viewers and collectors and purchasers of child porn
contribute to the ruination of children. It can't be excused, even if
most pedophiles are born that way and can't help the feelings.

> I guess I have a good reason
> to stop talking about the fucking Halting Problem in this newsgroup
> now; I will view anyone else who doesn't with deep suspicion.

Has anything but a 'simulating halt decider' been discussed here the
past year?

I only became aware of olcott and this ridiculousness because he
cross-posted to comp.lang.c.

He says this issue is his 'job'.

[Richard Damon]

Nope, because H doesn't actually "correctly simulate" the input to the
point to correctly predict that the correct simulation of it will not halt.

If you condition a statement on a condition that does not actually
happen, then you can not use the result of that condition.

Per your own words, since H does its logic on a D that is built on a
DIFFERENT H than itself (since it DOES abort its simulaiton on the first
instance of D calling H(D,D) ), then H is answering about something that
is NOT its input, and you are shown to be a dispicable liar.

Also, since your criteria is NOT the defined criteria of an actual Halt
Decider, you are showing that you have been lying for years that you are
are actually working on the Halting Problem.

Change the definitions of the problem, and you aren't working on it any
more.

Sorry, you are just PROVING that you just don't understand what you are
talking about, or are a pathological liar.

[Richard Damon]

On 11/18/22 10:05 AM, olcott wrote:

> Because simulating halt deciders only compute the mapping from their
> inputs to an accept or reject state on the basis of their correct
> simulation of this input it is only the behavior of this simulated input
> that is relevant to their halt status decision.
>
> int sum(int x, int y)
> {
>   return x + y;
> }
>
> For this same reason only the value of 3 + 4 is relevant to sum(3,4)
> only the behavior of D correctly simulated by H is relevant to H(D,D).
>

which since H is what it is, if it aborts its simulation, it no longer
has a basis to decide if its input would halt or not, and thus by the
strict reading of your definition, a simulating Halt Decider can NEVER
answer non-halting, only Halting, or it needs to keep on simulating.


That, or you need to accept that your definition does not meet the
actual definition of halting.

Remember, Non-Halting means that the input will continue to run for an
unbounded number of steps. You can not prove, just by the fact that it
didn't stop after some specific number N steps, doesn't tell you if it
would have halted after some larger number of steps or never halted.

That requires allowing the simulation by some other machine to be able
to be used to check if it is halting or non-halting.

Note, this does NOT mean you "change" H to be a different machine, as
THAT is not allowed, as in the case of P/D that changes the input that
it is processing the way you do it.

Since it is a "different" machine that might be needed to provide the
definition, you can't use the words "its simulation" in the definition.

Note, for many inputs, by using things like induction, it IS possible to
reason about what will happen with that other machine based solely on
the data from the simulation that H did. This is why you CAN prove that
some machines like infinte loop or infinite recursion are non-halting,
you CAN make an inductive arguement from the data gathered with a finite
simulation.

THe problem is that the inductive arguement does NOT work for P/D, since
they DO Halt if H aborts and returns 0. This is what makes Halting
non-computable.

[Mikko]

What "above definition of a simulating halt decider"? There is no definition
of a "simulating halt decider".

Mikko

[olcott]

--
Copyright 2022 Olcott "Talent hits a target no one else can hit; Genius

[Mikko]

That is not a definition and does not contain a definition.

Mikko

[Richard Damon]

But Your H doesn't do that, so it doesn't matter.

IF you actually built an H that actually doesn't stop until it can
actually prove that it would not stop running if it didn't abort its
simulation, and gave it the D built on it, then it would never stop running.

The problem is that while H doesn't create a "Liar's Paradox" situation,
H trying to prove that it would not stop running would. It can only
abort its simulation when it proves if the Liars paradox is true or false.

The key problem is "To Prove" is not a computable operation in general.

Your H uses UNSOUND logic to come to its conclusion about its input,
assuming the H that P calls doesn't actually act like H does.

You don't seem to understand what a computation actually is. H needs to
be a SPECIFIC set of instructions, which means so is D, and thus D(D)
has a specific and well defined behavior (given that definition of H).

N needs to predict the behavior of that computation, and that answer is
based on what this specific H does.

You are confusing the behavior of the SPECIFIC computation call D in
this specific example, which is based on a specific H that is claimed to
be correct, with trying to some how define the behavior of a computation
TEMPLATE (the D template that defines D in terms of H) over a set of
deciders.

Computation theory is about SPEIFIC machines, not templates and sets of
deciders.

[olcott]

It is stipulated to by a definition furthermore it is also an axiom.

Simulating halt deciders determine whether or not D simulated by H would
ever stop running on the basis that the behavior of D matches a
non-halting behavior pattern or fails to match such a pattern.

We divide up the above paragraph into a premise and a (sound deduction)
necessary consequence of that premise then when we know that (a) is true
we know that (b) must also be true.

(a) simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted.

(b) then H can abort its simulation of D and correctly report that D

specifies a non-halting sequence of configurations.

*NO ONE HERE UNDERSTANDS THIS*
When (a) is true and (b) is a necessary consequence of (a) then (b) is
true even if everyone and everything in the universe disagrees.

void E(void (*x)())
{
H(x, x);
}

int main()
{
H(E, E);
}

When we know that H(E,E) simulates its input (ignoring stack overflow)
then it is clear that E remains stuck in recursive simulation that will
never stop running unless aborted.

[Richard Damon]

On 11/19/22 9:53 AM, olcott wrote:

>

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

Yes, *IF* it has done this.

Note, your H doesn't do this for D.

It has shown that a DIFFERENT machine built on the same template as this
one, based on a DIFFERENT H that doesn't actually ever abort, would be
non-halting.

Since this H does abort, it isn't that other H, so the D this one was
given isn't that D it is thinking of, so this H is actually processing a
non-input by not correctly handling its own input.

It errs in its assumed behavior of a CALL H instruction.

[olcott]

On 11/19/2022 9:20 AM, Richard Damon wrote:
> On 11/19/22 9:53 AM, olcott wrote:
>
>>
>> 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.
>>
>>
>
> Yes, *IF* it has done this.
>

Well that is a big step in the correct direction.

void E(void (*x)())
{
H(x, x);
}

int main()
{
H(E, E);
}

When we know that H(E,E) simulates its input (ignoring stack overflow)
then it is clear that E remains stuck in recursive simulation that will
never stop running unless aborted.

[Richard Damon]

On 11/19/22 10:28 AM, olcott wrote:
> On 11/19/2022 9:20 AM, Richard Damon wrote:
>> On 11/19/22 9:53 AM, olcott wrote:
>>
>>>
>>> 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.
>>>
>>>
>>
>> Yes, *IF* it has done this.
>>
>
> Well that is a big step in the correct direction.
>
> void E(void (*x)())
> {
>   H(x, x);
> }
>
> int main()
> {
>   H(E, E);
> }
>
> When we know that H(E,E) simulates its input (ignoring stack overflow)
> then it is clear that E remains stuck in recursive simulation that will
> never stop running unless aborted.
>

But you need to insert a specific H into this. H is DEFINED by its
instructions.

Since your H DOES abort its simulation, to answer,

int main()
{
E(E);
}

does NOT get "stuck" in infiite recursion, which is the question that H
is suppose to answer, as that is the only CORRECT meaning of H correctly
simulating its input.

Your problem is you H isn't actually a computation, so can't be a
decider per computation theory.

It seems, you just don't understand what a computation actually is.

H needs to answer about the input it was ACTUALLY given, which was a D
that calls THIS H, not some hypothetical one that actually meets the
impossible specification you have tried to meet but failed.

[olcott]

Everyone having expertise in the C programming language can see that
(ignoring stack overflow) E correctly simulated by H would never stop
running unless aborted.

[Richard Damon]

You are confusion PROGRAM E with the C FUNCTION E.

The PROGRAM E terminates because it calls a H that aborts its simulation
of its simulation of its input, because it INCORRECTLY presumes that it
will not return. (Based on your stipulation that H(E,E) will return 0)

The only legal definition of a correct simulation of that PROGRAM P, is
a simulation that matches that behavior,, so if that isn't what H gets,
it didn't "Correctly Simulate" that input.

This PROGRAM E represents the computation theory FUNCTION P, as
comptation theory "functions" are units of complete execution, unlike
"function" of progrmaming languages which are code snippets.

Note, the H^/P/D definitions that you are modeling your E on, are all
defined to call the SPECIFIC DEFINITION of the decider that is clamied
to be correct in deciding all inputs.

YOU seem to be redefining it to just call what ever decider is actually
trying to decide it at the moment.

This is actually not a valid Computation Theory "Function"/Program, as
in computation theory, the units of computation are ONLY dependent on
their defined input, thus CAN'T know who (if anyone) is trying to decide
them.

You are just working on some strange model of computation that has
nothing to do with the theory you are claiming to be working on, so
nothing you have done has any meaning to Computation Theory.

[olcott]

Ah great you agree.

[Richard Damon]

So you agree that H is incorrect to say that E doesn't terminate?

After all, behavior of the code in E is part of E, so if E halts because
the H it calls does something WITH ANOTHER INSTANCE OF E, then it halts.

[olcott]

(a) simulating halt decider H correctly simulates its input E until H
correctly determines that its simulated E would never stop running
unless aborted

(b) then H can abort its simulation of E and correctly report that E

specifies a non-halting sequence of configurations.

NO ONE HERE UNDERSTANDS THIS

When (a) is true and (b) is a necessary consequence of (a) then (b) is
true even if everyone and everything in the universe disagrees.

[Richard Damon]

Except as I said elsewhere, it didn't.

It determined that if it was a DIFFERENT E based on a DIFFERENT H that
doesn't abort, then its input would be non-halting.

That is a conclusion based on a non-input.

This H doesn't "need" to abort ITS simulation, because the H that E
calls will abort its own simulation after a bit and return 0, and thus E
will end.

You have your pronouns mis-defined.

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

Since it didn't get (a) right, it can't in this case.

Yes, if it did, like it does for infinite_loop, it could.

>
> NO ONE HERE UNDERSTANDS THIS
> When (a) is true and (b) is a necessary consequence of (a) then (b) is
> true even if everyone and everything in the universe disagrees.
>

And you don't understand that (a) is NOT true for H(E,E).

You don't understand that E is using a FIXED COPY of H that must always
do what your original H does, and when doing hypotheticalls to determine
things like "unless", it doesn't change.

Your logic is based on the INCORRECT computation system where E is
defined to call what ever decider is trying to decide it, which is
infact an ILLEGAL definition in Computation theory, as that makes it
depend on something that isn't an input.

You COULD define E differently to do that, where E is define as:

E(x, H) {
H(x,x,H);
}

and then we look at H(E,E,H)), and compare to E(E,H), but then when we
change H it is clear that we have changes an input to the call of E, so
the logic is invalid.

[olcott]

Everyone having sufficient expertise in the C programming language can

see that (ignoring stack overflow) E correctly simulated by H would
never stop running unless aborted.

[Richard Damon]

Nope, explained elsewhere, but obviously that is over your head.

Just repeating the same assertion without refering to factual sources
just shows your lack of basis.

Try it yourself, run:

void E(void (*x)())
{
H(x, x);
}

int main()
{
H(E,E);

E(E);
}

And see that E(E) does return, so the outer H's aborting of the
simulation of E was not NEEDED to make the simulation terminate.

You don't understand the meaning of the words you are using in the
proper context.

[olcott]

On 11/19/2022 11:19 AM, Richard Damon wrote:
> On 11/19/22 12:15 PM, olcott wrote:
>> On 11/19/2022 10:57 AM, Richard Damon wrote:
>>> Except as I said elsewhere, it didn't.
>>>
>>> It determined that if it was a DIFFERENT E based on a DIFFERENT H
>>> that doesn't abort, then its input would be non-halting.
>> void E(void (*x)())
>> {
>>    H(x, x);
>> }
>>
>> int main()
>> {
>>    H(E,E);
>> }
>>
>> Everyone having sufficient expertise in the C programming language can
>> see that (ignoring stack overflow) E correctly simulated by H would
>> never stop running unless aborted.
>>
>>
>>
>
> Nope, explained elsewhere, but obviously that is over your head.
>

*That this is over your head is no rebuttal what-so-ever*
H correctly determines that for every H/E pair of the infinite set of
H/E pairs where E is correctly simulated by H, E never stops running

[Richard Damon]

On 11/19/22 12:20 PM, olcott wrote:
> On 11/19/2022 11:19 AM, Richard Damon wrote:
>> On 11/19/22 12:15 PM, olcott wrote:
>>> On 11/19/2022 10:57 AM, Richard Damon wrote:
>>>> Except as I said elsewhere, it didn't.
>>>>
>>>> It determined that if it was a DIFFERENT E based on a DIFFERENT H
>>>> that doesn't abort, then its input would be non-halting.
>>> void E(void (*x)())
>>> {
>>>    H(x, x);
>>> }
>>>
>>> int main()
>>> {
>>>    H(E,E);
>>> }
>>>
>>> Everyone having sufficient expertise in the C programming language
>>> can see that (ignoring stack overflow) E correctly simulated by H
>>> would never stop running unless aborted.
>>>
>>>
>>>
>>
>> Nope, explained elsewhere, but obviously that is over your head.
>>
> *That this is over your head is no rebuttal what-so-ever*
> H correctly determines that for every H/E pair of the infinite set of
> H/E pairs where E is correctly simulated by H, E never stops running
> unless aborted.
>

The problem with your "infinite pair" analogy is that this input is
never in the side that is completely simulated, so not proven to be
non-halting.

The Theorem isn't about "sets" of machines, but about machines
themselves, so you ar just not working on the Theory you claim you are,
so you are just lying.

You just don't understan what a computation is. This is what just DOOMS
your whole work.

Ignorance is its own punishment.

[olcott]

On 11/19/2022 11:43 AM, Richard Damon wrote:
> On 11/19/22 12:20 PM, olcott wrote:
>> On 11/19/2022 11:19 AM, Richard Damon wrote:
>>> On 11/19/22 12:15 PM, olcott wrote:
>>>> On 11/19/2022 10:57 AM, Richard Damon wrote:
>>>>> Except as I said elsewhere, it didn't.
>>>>>
>>>>> It determined that if it was a DIFFERENT E based on a DIFFERENT H
>>>>> that doesn't abort, then its input would be non-halting.
>>>> void E(void (*x)())
>>>> {
>>>>    H(x, x);
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    H(E,E);
>>>> }
>>>>
>>>> Everyone having sufficient expertise in the C programming language
>>>> can see that (ignoring stack overflow) E correctly simulated by H
>>>> would never stop running unless aborted.
>>>>
>>>>
>>>>
>>>
>>> Nope, explained elsewhere, but obviously that is over your head.
>>>
>> *That this is over your head is no rebuttal what-so-ever*
>> H correctly determines that for every H/E pair of the infinite set of
>> H/E pairs where E is correctly simulated by H, E never stops running
>> unless aborted.
>>
>
> The problem with your "infinite pair" analogy is that this input is
> never in the side that is completely simulated, so not proven to be
> non-halting.

The infinite pair proof involves every H/E pair such that some of these
pairs abort the simulation of their input and in every other H/E pair
the simulated E never stops running.

Your shell game of switching from one H/E pair to another does not work
when the analysis is performed on the infinite set of every H/E pair.

[Richard Damon]

Right, but the H/E pairs that simulate E forever to show it doesn't halt
are smulating a DIFFERENT program E since it uses that DIFFERNT H that
doesn't abort.

The problem is you don't seem to understand that the PROGRAM E, includes
the H that it is calling, so all the H/E pairs are refering to DIFFERENT
E's so you can't move results from one pair to another, since they are
different inputs.

> Your shell game of switching from one H/E pair to another does not work
> when the analysis is performed on the infinite set of every H/E pair.
>

But YOU are the one that is switching H/E pairs.

The ONLY pair that matters is the H that reports non-halting because it
aborts its simulation and the E built on it.

NO other pair in your set has the same E, because it doesn't have that
same H.

The only H/E pairs that actually show that the E is non-halting are
based on an H that never answer H(E,E) so NONE of them qualify as your
"correct" Halt Decider.

All the H/E pairs where H(E,E) returns an answer, abort their simulatino
of E(E), and that exact E has not been simulated by any of the H in that
other group, so not proved to be non-halting.

[olcott]

We and H correctly determine that for every element of the set of H/E
pairs no E correctly simulated by H ever stops running unless aborted.

This all by itself conclusively proves that H is correct to report that
its input specifies a non-halting sequence of configurations.

[Richard Damon]

No, you have shown that no H ever REACHES the final state in the
simulation which H did. ANY E whose simulation was aborted has not been
proved that it wouldn't have stopped if that simulation wasn't aborted.

If this H only did a partial simulation, it does NOT prove that the
input was non-halting.

You are just proving that you don't understand what you are talking
about, and aren't actully working on the Halting Problem

>
> This all by itself conclusively proves that H is correct to report that
> its input specifies a non-halting sequence of configurations.
>
>

Nope, proves you aren't working on the Halting Problem, and have been
lying about that,

Halting is NOT proved by a partial simulation not reaching a final state.

Maybe you are supporting the fact that you have been lying about other
things too.

[olcott]

Right and by your same incorrect reasoning we have no idea that every
integer X > 5 proves that X > 3.

[Richard Damon]

Nope.

Can you point out the error in what I am saying?

I have pointed out WHY you are wrong.

You have just denied it without actually giving a reason.

Maybe you are lying about other things to.

[olcott]

H: Begin Simulation Execution Trace Stored at:112ae5
Address_of_H:1383
[000019c3][00112ad1][00112ad5] 55 push ebp // begin E
[000019c4][00112ad1][00112ad5] 8bec mov ebp,esp
[000019c6][00112ad1][00112ad5] 8b4508 mov eax,[ebp+08]
[000019c9][00112acd][000019c3] 50 push eax // push E
[000019ca][00112acd][000019c3] 8b4d08 mov ecx,[ebp+08]
[000019cd][00112ac9][000019c3] 51 push ecx // push E
[000019ce][00112ac5][000019d3] e8b0f9ffff call 00001383 // call H
H: Infinitely Recursive Simulation Detected Simulation Stopped

You simply refuse to accept proof by something like mathematical
induction. You and I and H can see that E correctly simulated by H will

never stop running unless aborted.

If I say that 2 + 3 = 5 and you disagree what is the exact error that
you made? Refusing to accept arithmetic.

[Richard Damon]

So, you proof is that your program says so?

Not a proof.

>
> You simply refuse to accept proof by something like mathematical
> induction. You and I and H can see that E correctly simulated by H will
> never stop running unless aborted.

So, give the mathematical induction proof if you have one.

Do you even know how do actually DO a proof by induction?

Do you even know how to do an actual proof?

E, when correctly simulated will call H(E,E) and then that H will
simulate those instructions as listed above,

Then the H that E called will stop is simulation just like the above one
does, and return to E, which will then return normally and halt.

>
> If I say that 2 + 3 = 5 and you disagree what is the exact error that
> you made? Refusing to accept arithmetic.
>

Nope, Using Red Herring is just a logical fallicy.

Maybe you are dumb enough to think you are God and the laws don't apply
to you.

You logic is that bad.

[olcott]

http://web.stanford.edu/class/archive/cs/cs161/cs161.1176/Sections/161-section-1.pdf

The recursion invariant for E correctly simulated by H is trivial, E
never makes any progress towards terminating because there are no
conditional branch instructions from the beginning of E to its call to
H(E,E) what-so-ever. It is the same as a loop invariant for an infinite
loop.

[Richard Damon]

I well understand proof by induction.

>
> The recursion invariant for E correctly simulated by H is trivial, E
> never makes any progress towards terminating because there are no
> conditional branch instructions from the beginning of E to its call to
> H(E,E) what-so-ever. It is the same as a loop invariant for an infinite
> loop.
>

So, you don't know how to actually express it as a proof?

But E does make progress towards terminating, as the H that the first E
calls is a DECIDER, and by your example above, WILL abort its simulation
after its simulation reaches the call to H.

Thus, we we try to count how many levels of simulation we get to we can say:

1) The Call to H from main begins a simulation, so N=1 works.

2) That H will simulate E to its call to H.

Normally it would abort here, but we will assume that we suspend that
for THIS instance of the decider, but we need to keep that acting as it
actuall does, since the code in the input can NOT be changed or we have
a different input.

THus we get to N=2

3) That H will simulate the H called by E until it simulated to the call
to H in that simulate E.

The simulated H will then abort its simulation, and we progress no farther.

YOU mke the error of looking at the non-input of the not actually E
based on the not actually H that has been modified.

That isn't the input so you aren't correct to do it.

Your ignorance about this just shows your stupidity.

You are just proved to be a liar, and by continuing you are just showing
that the REAL God may justly decide to put you in the lake of fire.

[olcott]

Yet this correctly simulated E never reaches its own final state and
terminates normally.

[Richard Damon]

No, the CORRECTLY (and completely) simulated H does reach its final
state, I just described that simulation.

All that you have pointed out is that this H never complete and
correctly simulates its input, thus your criteria is illogical.

PARTIAL simulations don't (by themselves) prove non-halting.

This arguement just shows you like to serve your herring with red sauce.

It also shows you don't know how to write an actual proof.

YOU FAIL.

Maybe you can convince your cell mate that your right, if that video was
about you.

[olcott]

So you are saying the complete and correct simulation of E by H
eventually reaches the final state of E and terminates normally without
needing to be aborted?

[Richard Damon]

No, I am saying *THE* complete and correct simulation of E eventually
reaches the final state of E, because you have stipulated that H(E,E)
returns 0.

This is BECAUSE you have defined that the H called by E WILL abort its
simulation of E and returns 0, thus showing it does so INCORRECTLY.

H NEVER does a complete and correct simulation of E and returns the answer 0

You replacing *THE* Complete and correct simulation of the input, with
the simulation by H just shows that you are not working on the Halting
Problem, since that is NOT part of the requirements of the Halting
Problem or provable to be equivalent,

You are thus found to be LYING about what you have been doing.

Sorry, you are just showing that you have wasted your last 18 years of
life and ruined your reputation (though, maybe you have done something
to ruin it worse if Mr Flibble's video is about you).

Of course, your denials might not be beleived since you have proven
yourself to be a pathological liar.

[olcott]

*So basically you are directly disagreeing with professor Sipser*
simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted

[Richard Damon]

No, Professor Sipser said that IF H did a correct simulation or
correctly decided on what a correct simulation would do, H could act on it.

Remeber, to him, a "Correct Simulation" will mean like a UTM, and thus
also complete.

He did NOT say that you H does such a thing, or even can do such a thing
with this input.

By HIS meaning, Your H can NEVER "correctly" abort its simulation,
because if it does, then it becomes impossible to correctly prove that a
correct simulation of this input would be non-halting since *THE*
correct simulation of this input would be Halting, since the input
machine is Halting.

You are just proving you don't know what you are talking about, or even
the basics of logic.

Your assumption that the correct simulation by H can show anything other
than what the direct exectution of the machine represented is just an
error, by definition, and is leading you in to extreme error.

[olcott]

Premise
(a) If simulating halt decider H correctly simulates its input D until H

correctly determines that its simulated D would never stop running
unless aborted

Sound deductive conclusion
(b) then H can abort its simulation of D and correctly report that D

specifies a non-halting sequence of configurations.

[Richard Damon]

Right, *IF*

That means that you need to prove that *THE* correct simulation of the
input, exactly as provided, will not reach a final state.

PERIOD.

This includes taking into account that if that input uses a "copy" of H
to make its decision, that copy acts EXACTLY like the H the fully
behaves as the one that gives the answer.

Since that H aborts its simulation of this input, so does the H that the
this input calls. EVEN IF YOU ARE CHANGING THE H DOING THE SIMULATION TO
SEE IF IT NEEDS TO ABORT.

This is because the actual H that you claim to implement this decision
has the code to abort in that condition, so the answer must still be
correctd when simulating the input using that H.

The fact that no H ever can do that simulation is irrelevent, it just
needs to determine the right answer. The impossiblility is why the
Halting Function is not computable.

Your failure to understand this shows that you are ignorant of the
material of the field, and appparently to dim-witted to understand it
when explained.

You are just showing yourself to be an idiot and a liar.

[olcott]

Not at all. I must only prove that
D correctly simulated by H
D correctly simulated by H
D correctly simulated by H
D correctly simulated by H

would never stop running unless aborted

[Mikko]

On 2022-11-19 15:17:03 +0000, olcott said:

> On 11/19/2022 9:02 AM, Mikko wrote:
>> On 2022-11-19 14:53:46 +0000, olcott said:
>>
>>> On 11/19/2022 5:35 AM, Mikko wrote:
>>>> On 2022-11-18 15:28:18 +0000, olcott said:
>>>>
>>>>> On 11/18/2022 5:48 AM, Mikko wrote:
>>>>>> On 2022-11-17 17:46:17 +0000, olcott said:
>>>>>>
>>>>>>> MIT Professor Michael Sipser specifically approved this verbatim
>>>>>>> definition as the abstract to this paper. (He neither reviewed nor
>>>>>>> approved anything else).

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

>>>>>> So you are asking about agreement with Sipser about this?
>>>>>>
>>>>>> Is this somehow connected to the rejection or correctness of the
>>>>>> notion of a simulating halt decider?
>>>>>
>>>>> void D(void (*x)())
>>>>> {
>>>>>    int Halt_Status = H(x, x);
>>>>>    if (Halt_Status)
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>> When we apply the above definition of a simulating halt decider H to
>>>>> the above function D ordinary software engineering code analysis proves
>>>>> that D specifies a non halting sequence of configuration to H.
>>>>
>>>> What "above definition of a simulating halt decider"? There is no definition
>>>> of a "simulating halt decider".

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

>> That is not a definition and does not contain a definition.
>
> It is stipulated to by a definition furthermore it is also an axiom.

Syntax error. Anyway, nothing above that defines "simulaating halt decider".
A definition clearly identifies one word or phrase as the new term and
fully specifies what it means. Logically definitions are axioms but they
usually are not called so because they are called "definitions".

Mikko

[Richard Damon]

So, you are admitting that you are not working on the Halting Problem of
Computation Theory and have been lying for years?

That isn't the required criteria for the Halting Problem, so anything
based on it isn't either.

Also, it shows your lack of understanding as how can H's correct
simulaton show something different then *THE* definitional Correct
Simulation?

This shows that you just don't understand the meaning of words like
"Correct", and likely don't understand the related words like "Truth",
"Proof", "Logic", etc.

You are just destroying what little reputation you might have had left
by your idiocy.

Of course, if the video that Mr Flibble found turns out to be of you,
then you did a pretty good job of destroying it to others already, or
maybe that it just the final nail in the coffin.

[olcott]

On 11/20/2022 6:27 AM, Richard Damon wrote:
> On 11/19/22 10:44 PM, olcott wrote:
>> On 11/19/2022 9:25 PM, Richard Damon wrote:
>>> On 11/19/22 10:11 PM, olcott wrote:
>>>> Premise
>>>> (a) If simulating halt decider H correctly simulates its input D
>>>> until H correctly determines that its simulated D would never stop
>>>> running unless aborted
>>>>
>>>> Sound deductive conclusion
>>>> (b) then H can abort its simulation of D and correctly report that D
>>>> specifies a non-halting sequence of configurations.
>>>>
>>>
>>> Right, *IF*
>>>
>>> That means that you need to prove that *THE* correct simulation of
>>> the input, exactly as provided, will not reach a final state.
>>>
>>
>> Not at all. I must only prove that
>>     D correctly simulated by H
>>     D correctly simulated by H
>>     D correctly simulated by H
>>     D correctly simulated by H
>>
>>     would never stop running unless aborted
>>
>>
>
> So, you are admitting that you are not working on the Halting Problem of
> Computation Theory and have been lying for years?

The above is a paraphrase of the Sipser approved criteria.

[olcott]

simulating halt decider
simulating halt decider
simulating halt decider
simulating halt decider

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.

[Richard Damon]

On 11/20/22 9:35 AM, olcott wrote:
> On 11/20/2022 6:27 AM, Richard Damon wrote:
>> On 11/19/22 10:44 PM, olcott wrote:
>>> On 11/19/2022 9:25 PM, Richard Damon wrote:
>>>> On 11/19/22 10:11 PM, olcott wrote:
>>>>> Premise
>>>>> (a) If simulating halt decider H correctly simulates its input D
>>>>> until H correctly determines that its simulated D would never stop
>>>>> running unless aborted
>>>>>
>>>>> Sound deductive conclusion
>>>>> (b) then H can abort its simulation of D and correctly report that
>>>>> D specifies a non-halting sequence of configurations.
>>>>>
>>>>
>>>> Right, *IF*
>>>>
>>>> That means that you need to prove that *THE* correct simulation of
>>>> the input, exactly as provided, will not reach a final state.
>>>>
>>>
>>> Not at all. I must only prove that
>>>     D correctly simulated by H
>>>     D correctly simulated by H
>>>     D correctly simulated by H
>>>     D correctly simulated by H
>>>
>>>     would never stop running unless aborted
>>>
>>>
>>
>> So, you are admitting that you are not working on the Halting Problem
>> of Computation Theory and have been lying for years?
> The above is a paraphrase of the Sipser approved criteria.
>

Which DECEPTIVELY changes the meaning, so is a LIE.

To Professor Sipser, the ONLY meaning of "Correctly Simulated" means to
simulate to show the actual behavior of the machine the input represents.

Since D(D) will Halt, it is IMPOSSIBLE for H to somehow "Correctly" show
that a correct (by anyone, even itself) simulation of the input would
not halt.