Can D simulated by H terminate normally?

[olcott]

Can D simulated by H terminate normally?

The following code is executed in the x86utm operating system based on
an open source x86 emulator. This system enables one C function to
execute another C function in debug step mode. When H simulates D it
creates a separate process context for D with its own memory, stack and
virtual registers. H is able to simulate D simulating itself, thus the
only limit to recursive simulations is RAM.

01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }

*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11

*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...

Is this clear enough to see that D correctly simulated by H can never
terminate normally ? (because D remains stuck in recursive simulation) ?

For any program H that might determine whether programs halt, a
"pathological" program D, called with some input, can pass its own
source and its input to H and then specifically do the opposite of what
H predicts D will do. *No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem

H(D,D) fully operational in x86utm operating system:
https://github.com/plolcott/x86utm

Source-code of several different partial halt deciders and their sample
inputs. https://github.com/plolcott/x86utm/blob/master/Halt7.c

This paper shows how that same idea is applied to the Peter Linz Turing
machine based Halting Problem Proofs.

*Simulating (partial) Halt Deciders Defeat the Halting Problem Proofs*
https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs


*At 10/13/2022 11:29 AM in an email*
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.

It is clear that H does determine the halt status of D precisely
according to that criteria.



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

--
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 5/19/23 10:50 AM, olcott wrote:
> Can D simulated by H terminate normally?

Wrong Question!

You are showing your stupidity by repeatig the Strawman error that has
been pointed out to you many times, showing your Stupidity.


First you have to ask and answer does the ACTUAL H even do a "Correct
Simulation" by the definition that allows you to use the simulation to
determine halting.

Since the answer is NO, your question is mute.

YOU FAIL.

[olcott]

On 5/19/2023 5:54 PM, Richard Damon wrote:
> On 5/19/23 10:50 AM, olcott wrote:
>> Can D simulated by H terminate normally?
>
> Wrong Question!
>

In other words the question is over you head.
It took me many years to recognize this same dodge by Ben.

[Richard Damon]

On 5/19/23 9:47 PM, olcott wrote:
> On 5/19/2023 5:54 PM, Richard Damon wrote:
>> On 5/19/23 10:50 AM, olcott wrote:
>>> Can D simulated by H terminate normally?
>>
>> Wrong Question!
>>
>
> In other words the question is over you head.
> It took me many years to recognize this same dodge by Ben.

No, it is the WRONG question once you try to apply the answer to the
Halting Problem, which you do.

You are just proving your are a stupid ignorant liar by repeating the error.

You have shown a total non-understanding of the principle of
requirements, so none of your work has value to anyone concerned about
doing the right thing when asked.

You keep on giving people the number of dogs when they ask you how many
cats, and insist that must be what they mean.

You TOTALLY don't understand what logic means.

[olcott]

On 5/19/2023 8:56 PM, Richard Damon wrote:
> On 5/19/23 9:47 PM, olcott wrote:
>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>> On 5/19/23 10:50 AM, olcott wrote:
>>>> Can D simulated by H terminate normally?
>>>
>>> Wrong Question!
>>>
>>
>> In other words the question is over you head.
>> It took me many years to recognize this same dodge by Ben.
>
> No, it is the WRONG question once you try to apply the answer to the
> Halting Problem, which you do.
>

So the software engineering really is over your head?
I see, so like Ben you have never actually written any code.

Ben kept masking his coding incompetence this way.
It never occurred to me that you have never written any code.

[Richard Damon]

On 5/19/23 10:10 PM, olcott wrote:
> On 5/19/2023 8:56 PM, Richard Damon wrote:
>> On 5/19/23 9:47 PM, olcott wrote:
>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>> Can D simulated by H terminate normally?
>>>>
>>>> Wrong Question!
>>>>
>>>
>>> In other words the question is over you head.
>>> It took me many years to recognize this same dodge by Ben.
>>
>> No, it is the WRONG question once you try to apply the answer to the
>> Halting Problem, which you do.
>>
>
> So the software engineering really is over your head?
> I see, so like Ben you have never actually written any code.

But you aren't talking about Software Engineering unless you are lying
about this applying to the Halting Problem described by Linz, since that
is the Halting Problem of Computability Theory.

Of course, the likely explanation is that you are just ignorant of what
you are talking about, so you don't understand the diference.

>
> Ben kept masking his coding incompetence this way.
> It never occurred to me that you have never written any code.

I have possibly written more WORKING code than you have.

[olcott]

I don't believe you. Your inability to answer an straight forward
software engineering question seems to prove otherwise.

Ben successfully pulled this same crap for nearly two decades.
He may know some things at the abstract textbook level very well.
That seems to be the total extent of his technical knowledge.
Mike had to coach on some relatively simple things.

[Richard Damon]

What software engineering question?

SInce you refer to The Halting Problem from Turing as described by Linz,
you are putting out a Strawman.

You don't seem to understand the correct meaning of "Simulate" from the
problem domain.

Maybe with your wrong definition of "Correct Simulation" you can show
that H does what you call a "Correct Simulation", but since it doesn't
match the definition used in talking about a UTM, you can't use that
fact to talk about the Halting of the machine described by the input.

You are just proving you don't understand about logic or anything
related that you have been talking about.

>
> Ben successfully pulled this same crap for nearly two decades.
> He may know some things at the abstract textbook level very well.
> That seems to be the total extent of his technical knowledge.
> Mike had to coach on some relatively simple things.
>

Nope, You have been ignoring the fact that you are just ignorant about
what the question you have been working on actually means, because you
refuese to learn the language it was written in.

YOU are the stupid one trying to pull crap with your POOP problem.

[Richard Damon]

On 5/19/23 10:10 PM, olcott wrote:
> On 5/19/2023 8:56 PM, Richard Damon wrote:
>> On 5/19/23 9:47 PM, olcott wrote:
>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>> Can D simulated by H terminate normally?
>>>>
>>>> Wrong Question!
>>>>
>>>
>>> In other words the question is over you head.
>>> It took me many years to recognize this same dodge by Ben.
>>
>> No, it is the WRONG question once you try to apply the answer to the
>> Halting Problem, which you do.
>>
>
> So the software engineering really is over your head?
> I see, so like Ben you have never actually written any code.

Nope, I have likely written more working code than you.

The problem is the question you are discussing isn't a software
engineering question, in part because it predates the computer you are
thinking about.

This seems to be a common problem with you, you don't seem to understand
about requirements, which is likely why you have so much problem with
getting things rignt.

[olcott]

The following code is executed in the x86utm operating system based on
an open source x86 emulator. This system enables one C function to
execute another C function in debug step mode. When H simulates D it
creates a separate process context for D with its own memory, stack and
virtual registers. H is able to simulate D simulating itself, thus the
only limit to recursive simulations is RAM.

01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }

*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11

*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...

Is this clear enough to see that D correctly simulated by H can never
terminate normally ? (because D remains stuck in recursive simulation) ?

[olcott]

The following code is executed in the x86utm operating system based on
an open source x86 emulator. This system enables one C function to
execute another C function in debug step mode. When H simulates D it
creates a separate process context for D with its own memory, stack and
virtual registers. H is able to simulate D simulating itself, thus the
only limit to recursive simulations is RAM.

01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }

*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11

*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...

Is this clear enough to see that D correctly simulated by H can never
terminate normally ? (because D remains stuck in recursive simulation) ?

[Richard Damon]

The answer to that question is NO, but that is because H doesn't, and
can never do an accurarte simulation per the definition of a UTM.

Thus, it is the WRONG QUESTION for the problem.

It is a STRAWMAN.

The fact that you fixate on it, shows your ignorance.

The fact that D simulated by H doesn't terminate because H aborts its
simulatiom has no bearing on the Halting Problem. By your logic ALL
machines can be correctly decided to be non-halting, as all the decider
needs to do is halt its simulation for an unsound reason and say it
didn't reach a final state.

This has been pointed out to you many times in the past, and the fact
you still haven't learned it makes you STUPID.

[Richard Damon]

The answer to that question is NO, but that is because H doesn't, and
can never do an accurarte simulation per the definition of a UTM.

Thus, it is the WRONG QUESTION for the problem.

It is a STRAWMAN.

The fact that you fixate on it, shows your ignorance.

The fact that D simulated by H doesn't terminate because H aborts its
simulatiom has no bearing on the Halting Problem. By your logic ALL
machines can be correctly decided to be non-halting, as all the decider
needs to do is halt its simulation for an unsound reason and say it
didn't reach a final state.

This has been pointed out to you many times in the past, and the fact
you still haven't learned it makes you STUPID.

>

[olcott]

Finally you admit an easily verified fact.

> but that is because H doesn't, and
> can never do an accurarte simulation per the definition of a UTM.
>

If the simulation by a UTM would be wrong then you would have to be able
to point out the mistake in the simulation of D by H,

because H and D are isomorphic to embedded_H and ⟨Ĥ⟩

yet you already admitted that the simulation by H does prevent the
simulated D from terminating normally. So you have painted yourself in a
corner on this.

[Richard Damon]

No, the simulation by a ACTUAL UTM will reach a final state.

H, which isn't a UTM, can't do that.

>
> because H and D are isomorphic to embedded_H and ⟨Ĥ⟩

No, D is Ĥ, &D is (Ĥ)

>
> yet you already admitted that the simulation by H does prevent the
> simulated D from terminating normally. So you have painted yourself in a
> corner on this.
>
>

Right, because H isn't a UTM. If it was, it would fail to answer, and
thus not be a decider. (By Definition, UTM of a non-halting input never
halts and gives an answer, so if H WAS a UTM, it could never correctly
answer non-halting, doing so makes it NOT a UTM).

YOU have shown yourself to be a LIAR, because this has been explained to
you before, and you refuse to learn it.

UTM(D,D) will Halt, since D(D) will Halt because H(D,D) returns 0.

Thus H(D,D) returning 0 is INCORRECT.

Only because you stupidily think you can just "define" H to be a UTM
"plus" when it fails to meet the requirements of a UTM, can you even
attempt your unsound and invalid arguement.

Basically, we have a case where you are told that Jack knows the answer
to the problem, so you ask Jim for the answer. Even if you ask Jim what
would Jack say, since Jim doesn't know the answer, either he doesn't
answer or he lies, or he just makes up an answer.

The UTM is Jack.

Your H is Jim, it isn't actually a UTM, so it doesn't actually have the
answer in this case, so it needs to either blatantly lie, or just guess,
and due to the structure of D, it will always guess wrong.

[olcott]

I don't know why you say this when you already know that ⟨Ĥ⟩ correctly
simulated by embedded_H cannot possibly terminate normally.

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

N steps of ⟨Ĥ⟩ correctly simulated by embedded_H are the actual behavior
of this input:
(a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to embedded_H
(b) embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) which simulates
⟨Ĥ⟩ applied to ⟨Ĥ⟩
(c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the process

[Richard Damon]

Because embedded_H doesn't actually "Correctly Simulate" its input by
the definintion aquired by your mentioning of a UTM.

Remember, as you have previously pointed out, very word/phrase in a
natural language sentence implicitly has a UUID attached to it to
indicate which of its meanings this use has. When we are talking about a
UTM, the ONLY definition of "Correctly Simulate" that matches, as a
COMPLETE simulation. (Maybe your problem is you don't really understand
what a UTM is). Since the phrase "Correctly Simulates" means completly
simulates, and embedded_H doesn't do that, since it DOES abort its
simulation, your statement of "correctly simulated by embedded_H" is a
statement built on a false premise, and thus unsound.

Thus, your whole arguement fails.

You can't change H / embedded_H to be some other program beside the one
claimed (which does abort) or that means that your Ĥ isn't the Ĥ from
the problem.

You are just showing you are a stupid and ignorant pathological liar.

>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> N steps of ⟨Ĥ⟩ correctly simulated by embedded_H are the actual behavior
> of this input:

Which isn't "Correctly Simulated" per the meaning of the words as
implied by your invoking of the concept of a UTM.

> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to embedded_H
> (b) embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) which simulates
> ⟨Ĥ⟩ applied to ⟨Ĥ⟩
> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the process
>
>

And in actuality, (c) doesn't continue the process as the outer
embedded_H aborts its simulation, and returns (incorrectly) non-halting
and the input machine, which then halts.

So a CORRECTLY simulated input will halt, it is just that embedded_H
aborts its simulation, so gets the wrong answer.

[olcott]

You have already agreed that it does simulate the first N steps
correctly. It is just as obvious that the behavior pattern of N steps of
⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly terminate normally
even if the value of N is ∞.

[Richard Damon]

But N steps in not ALL steps as required by the actual definition of a UTM.

And, since H DOES abort it simulation, you need to consider that it
does, and thus it doesn't do a correct simulation, so you can't use its
simuation.

You need to decide whcih fact your H implements.

Either it actually does a "Correct Simulation" and thus simulates until
it finds the actual end, which you have shown causes H to never answer, or

it aborts its simulation to give an answer, but then its simulation
doesn't meet the requirements to be "Correct", and when we put the input
that it takes into an ACTUAL UTM, we see that the actual correct
simulation of the input halts, so your H is using incorrect and unsound
logic to make its decision.

You have never answered why you think you answer is correct to say the
input isn't halting, when an actual running of the input is to see it
halts, and the actual correct simulation of the input (by an actual UTM
that doesn't abort) is to show that the correct simulation halts.

You say that the correct simulation by H is different, but you can't
show the step ACTUALLY SIMULATED that shows the actual difference. You
logic confuses the simulation of the simulator with the machine it is
simulating, which are only matchable it the simulator never aborts,
which yours does.

[olcott]

Actually N steps is the exact definition of a UTM for those N steps.
Just like with the H/D example after N steps we can see that neither
D correctly simulated by H nor ⟨Ĥ⟩ correctly simulated by embedded_H
can possibly terminate normally.

Disagreeing with easily verified facts makes you look foolish.

[Richard Damon]

Nope, UTMs have no concept of only doing a partial simulation.

Please show in the DEFINITON of what a UTM is that justifies your claim.

UTM isn't a "process" it is a type of Turing Machine. That machine has a
defined behavior, which is a complete simulation of the input generating
the exact same results as that machine.

You are making a Type Error in your description.

> Disagreeing with easily verified facts makes you look foolish.
>

Stating false statement shows you are a LIAR.

[olcott]

When a simulating halt decider correctly simulates N steps of its input
it derives the exact same N steps that a pure UTM would derive because
it is itself a UTM with extra features.

(a) Watching the behavior doesn't change it.
(b) Matching non-halting behavior patterns doesn't change it
(c) Even aborting the simulation after N steps doesn't change the first
N steps.

Because of all this we can know that the first N steps of input D
simulated by simulating halt decider H are the actual behavior that D
presents to H for these same N steps.

When we can see after N steps of correct simulation that D correctly
simulated by H cannot possibly terminate normally (as you already
admitted) we can equally see after N steps of correct simulation that

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly terminate
normally.

You really look quite foolish denying this.
It is like you agreed that 2 + 3 = 5
yet vehemently disagree that 3 + 2 = 5.

[Richard Damon]

Just like a racing car is a street legal care with extra features that
makes it no longer street legal.

The fact that H aborts its simulation part way means it is no longer a
UTM because it fails to meet the requriements, thus the fact that its
simulation doesn't meet a final state doesn't mean the program is
non-halting.

That is like saying if you run a program for just N steps, and then stop
it and it hasn't meet a final state, that shows that the program, even
if allowed to run to completion, will never halt. That is incorrect, it
just shows that the step where it reaches its final state, if it does,
is at a step greater than N.

> (a) Watching the behavior doesn't change it.
> (b) Matching non-halting behavior patterns doesn't change it
> (c) Even aborting the simulation after N steps doesn't change the first
> N steps.

but does change the over all behavior of the machine doing it.

Since embedded_H does its analysis of its simulation presuming that the
copy of embedded_H it sees is actually a UTM, since embeded_H does abort
its simulation, and thus isn't one, means that embedded_H used a false
premise in its analysis,

>
> Because of all this we can know that the first N steps of input D
> simulated by simulating halt decider H are the actual behavior that D
> presents to H for these same N steps.

Right, but that doesn't give actual behavior of a CORRECT (per
definition of a UTM) simulation.

If you are saying that a simulation of N steps done correctly is your
definition of a "Correct Simulation" you can't use the properties of a
UTM, since your simulation doesn't meet the requirements to be a UTM.

>
> When we can see after N steps of correct simulation that D correctly
> simulated by H cannot possibly terminate normally (as you already
> admitted) we can equally see after N steps of correct simulation that
> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly terminate
> normally.

But, since H isn't actually a UTM, that doesn't matter.

We CAN see that a UTM simulation of the input will halt becuase it will
see the first copy of embedded_H simulated will eventually abort its
simulation (making it not a UTM) and returning the INCORRECT answer of
non-halting to the copy of D that called it, and that copy halting, we
see that the CORRECT simulation of the input Halts.

>
> You really look quite foolish denying this.
> It is like you agreed that 2 + 3 = 5
> yet vehemently disagree that 3 + 2 = 5.
>

Nope, You are just lying. I never said that.

You are the one claiming that H does a correct simulation by the
requirements of a UTM, when it doesn't, so you "proof" is based on LIES,
and unsound logic.

[olcott]

*Yet only at the point where it aborts its simulation*
At this point where it aborts its simulation we can see that it must
do this to prevent its own infinite execution, thus conclusively proving
that it correctly determined that its simulated input cannot possibly
terminate normally.

How much longer are you going to play the fool and deny this?

[Richard Damon]

Right, but that affect the behavior of ALL copies of it, since they all
act the same.

Do you think you are immortal because you haven't died yet, and that
everyone is immortal until the point in time they die?

Since it just proves it isn't a UTM, it can't assume that the copy it is
simulating is, it needs to account for that behavior.

The fact that the DESIGN logic to do this goes into an infinite loop,
doesn't mean that the program itself does.

Since H aborts its simulation and returns 0, its input will see its copy
do exactly the same thing and thus will Halt, making the answer wrong.

Since H isn't a UTM, since if fails to meet the defintion, the fact that
it can't reach a final state is irrelevent, as is any definiton of
"Correct Simulation" that differs from what a UTM does.

UTM(D,D) Halts, therefore the CORRECT SIMULATION (by a UTM which is what
is allowed to replace the actual behavior of the machine) Halts, and
thus the CORRECT answer is Halting.

You are just showing that you have fallen for your own Strawman
Deception that got you to use the wrong criteria.

> At this point where it aborts its simulation we can see that it must
> do this to prevent its own infinite execution, thus conclusively proving
> that it correctly determined that its simulated input cannot possibly
> terminate normally.
>
> How much longer are you going to play the fool and deny this?
>

No, it does so because it has been programmed to do so, and thus ALL
copies of it will do so.

It makes the error assuming that the copy it is simulating will do
something different than it does.

[olcott]

It makes no error. As you already admitted D correctly simulated by H
cannot possibly terminate normally thus its isomorphism of ⟨Ĥ⟩ correctly
simulated by embedded_H cannot possibly terminate normally.

Are you going to keep playing the fool on this?

[Richard Damon]

Except that you are answering the wrong question.

The question is NOT "Can H simulate its input to a fina state?" but is
"Does the input represent a Halting Computation?", which can be also
expressed as "does a UTM simulating the input to H halt?", but that is
only because BY DEFIHNITION, a UTM simulating a representation will
exactly reproduce the behavior of the machine that input represents.

If H wants to be a UTM, then it can't stop and give an answer if its
input isn't halting, and thus it will fail to be a Halt Decider.

Unless you think that "Saying the input is non-halting" is exactly the
same thing a "Being Non-Halting" you answer is wrong.

Saying it is would be like saying that a sign with the word "Blue" in
Red letters is a sign whose color is blue.

[olcott]

In other words you want to keep playing the fool and dodging the actual
question that I am actually asking.

So you agreed that D correctly simulated H cannot possibly terminate
normally and the exact same thing goes for ⟨Ĥ⟩ correctly simulated by
embedded_H.

Most novices dealing with the halting problem fail to understand that
halting <is> terminating normally and terminating for any other reason
is not halting.

[Python]

Child molester Peter Oolcott wrote:
...

> Most novices dealing with the halting problem fail to understand that
> halting <is> terminating normally and terminating for any other reason
> is not halting.

Come on! In practice halting or terminating, in any way, for a real
program is just the states of a bunch of switches that happens to be a
computer because we interpret the states. No difference.

Give up CS, Peter, its not your thing. Or persist, meanwhile, at least,
you're not molesting children.

[Richard Damon]

No, you are showing yourself to be the fool by not understand your own
stupidity.

>
> So you agreed that D correctly simulated H cannot possibly terminate
> normally and the exact same thing goes for ⟨Ĥ⟩ correctly simulated by
> embedded_H.

No, I am saying that H can not correctly simulate the input H and give
an answer. If H DOES try to correctly simulate its input, then it can
never giv an answer. if it stops simulating to give an answer, it did
not correctly simulate its input, per the required definition from a UTM.

You just don't understand what a UTM actually is and what its correct
simulation imply.

>
> Most novices dealing with the halting problem fail to understand that
> halting <is> terminating normally and terminating for any other reason
> is not halting.
>
>

Right, terminating normally of the ACTUAL MACHINE, which will not stop
for any reason other than reaching the final state, so there are no
other possible reasons for an actual Turing Machine to stop.

You can not "stop" an actual Turing Machine, it WILL just run to
completion. Yes, you can stop a simulation of a Turing Machine, but that
just means you don't have any direct proof of the machines actual
behavior. You seem to not understand the fundamentals of what Turing
Machines are.

Your arguement is basically like you got on a highway and started to
drive on it. You then go off the highway at an exit. Since you never
reached the end of the Highway, you can concludee the Highway has no end.

FAIL.

[olcott]

Since you already acknowledged that D correctly simulated by H can never
terminate normally and you did not need an infinite amount of time to
determine this then the isomorphic ⟨Ĥ⟩ correctly simulated by embedded_H
can also be determined to never terminate normally and this
determination can be made in a finite amount of time.

In both cases this can be correctly determined after N steps of
simulation thus no need for the infinite simulation that you keep
insisting is necessary.

[Richard Damon]

You keep on LYING about what I said. Any H that gives an answer can not
"Correctly Simulate" this input per the definitions that allow
simulation to replace the behavior of the actual machine.

Thus, your statement is ILLFORMED, just like the Liar's Paradox.

Since your H doesn't "Correctly Simulate" its input, you can not use
logic that assumes it does, thus, since you keep on trying to, you show
you do not understand the principles of sound logic.

You are just proving that you have no idea about how truth works.

What are your actual "Stipulated" facts, and what is the sementic
connection to your answer.

Remember, the replacement of the behavior of the actual machine with the
"Correct Simulation" (which you do) requires that "Correct Simulation"
includes the requirement of COMPLETE simulation.

Thus H can not do a "Correct Simulation" per the above AND abort its
simulation to give an answer, and ALL VERSION OF H (including embedded_H
which is just an alias for H) behave the same given the same input.

"augmenting" a UTM by letting it stop before it gets to the end, means
the machine is no longer a UTM, and its simulation no longer satisfies
the requirement to be a replacement for the actual machine.

A machine that SAYS its input in non-halting, is different than a
machine that indicates its input is non-halting by being, itself,
non-halting.

Saying they are the same is saying that a sign with the word "Blue" in
Red Letters, is the same thing as a Sign that written in the Color Blue.

You are just proving you ideas are worthless, because you cling to
invalid and unsound logic.

[olcott]

Since you already acknowledged that D correctly simulated by H cannot
possibly terminate normally (hence [key agreement]) and the H/D pair is
isomorphic to the embedded_H / ⟨Ĥ⟩ pair you contradict yourself.

[Richard Damon]

So?

D(D) / Ĥ (Ĥ) still halt since H returns non-halting, thus that answer is
wrong for the Halting Problem.

The problem is that the question is about the behavior of the actual
machine, and the logic to transfer that behavior to a simulation
requires a simulation that H doesn't do, so H's inability to simulate to
a final state is irrelevent.


Your arguement is based on unsound and invalid arguements that become a
LIE by your refusal to accept that position.

YOU ARE JUST SHOWING YOU ARE AN STUPID IGNORANT PATHOLOGICAL LIAR.

[olcott]

It only seems wrong because all of the textbooks reject simulating
halt deciders out-of-hand without review incorrectly assuming that
simulation cannot possibly be used as the basis of a halt decider:

We cannot find the answer by simulating the action of M on w, say by
performing it on a universal Turing machine, because there is no limit
on the length of the computation. If M enters an infinite loop, then no
matter how long we wait, we can never be sure that M is in fact in a
loop. It may simply be a case of a very long computation. What we need
is an algorithm that can determine the correct answer for any M and w by
performing some analysis on the machine's description and the input. But
as we now show, no such algorithm exists.(Linz:1990:317)

*THIS IS NECESSARILY TRUE*
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.

This only takes N steps of correct simulation.

[Richard Damon]

No, it is wrong because the question asks about the actual machine, and
that halts, so the right answer is HALTING.

Unless "Simulating Halting Deciders" aren't actually a subclass of Halt
Deciders, and thus aren't actually germane to the problem, there answer
has to match the actual question, not your strawman.

>
> We cannot find the answer by simulating the action of M on w, say by
> performing it on a universal Turing machine, because there is no limit
> on the length of the computation. If M enters an infinite loop, then no
> matter how long we wait, we can never be sure that M is in fact in a
> loop. It may simply be a case of a very long computation. What we need
> is an algorithm that can determine the correct answer for any M and w by
> performing some analysis on the machine's description and the input. But
> as we now show, no such algorithm exists.(Linz:1990:317)

Right, we can't just use a UTM to get the answer, because that won't
give us non-halting in finite time.

That doesn't give you the right to give a wrong answer.

Your "logic" that shows your claim the answer is right is just
incorrect, as it assumes the copy of H in the machine behaves
differently than the copy of H deciding the answer, which is impossible.


If you want to claim otherwise, show the actual step in the direct
execution of D calling H(D,D) and of the direct call to H(D,D) that
difffers.

NOT your simulation of D, but the actual direct exectution of D calling
H(D,D). I say that because your "simulation" of D(D) doesn't actually
show the simulation of that call to H, because it isn't correct. You
claim the pages of irrelevent trace don't matter, but for your claim to
be correct, you need to show where those two machine execution diverge,
with both being calls to H(D,D), just from different contexts, where H
is DEFINED to be a Computation that is only a function of its defined
inputs, and not the context of its call.


YOU FAIL.

>
> *THIS IS NECESSARILY TRUE*
> 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.
>
> This only takes N steps of correct simulation.
>

No, it does NOT "Correctly Simulate" per the definition of a UTM, which
is the ONLY definition that allows changing from the actual machine to a
simulation, so your statement has a false premise.

H does NOT "Correct Simulate" the input per the needed definition, so
has no grounds to call the machine non-halting.

You are just too ignorant of the actual meaning of the words to
understand this.

You also don't seem to understand that an answer can't be both wrong and
right at the same time to a well formed question, which the Halting
Problem is.

You are just proving your stupidity.

[olcott]

Yet any theory of computation computer scientist knows that a simulation
of N steps by a UTM does provide that actual behavior of the actual
input to this UTM.

They also know that when the input to this UTM is defined to have a
pathological relationship to this UTM that this changes the behavior of
this correctly simulated input.

Maybe I should begin my paper with this self-evident truth before
proceeding to the notion of a simulating halt decider.

In any case the perfect isomorphism between H/D and embedded_H / ⟨Ĥ⟩
already fully proves this point.

[Richard Damon]

Nope, only if the machine reaches a final state in that Nth Step.

You just don't understand what a UTM is or what it does.

>
> They also know that when the input to this UTM is defined to have a
> pathological relationship to this UTM that this changes the behavior of
> this correctly simulated input.

Nope, a UTM simulation is only correct if it exactly matches the FULL
b4ehavior of the machine it is looking at. That is its DEFINITION.

>
> Maybe I should begin my paper with this self-evident truth before
> proceeding to the notion of a simulating halt decider.

Yes, do that, so anyone who actually understand the theory knows from
that start that you are a crackpot.

>
> In any case the perfect isomorphism between H/D and embedded_H / ⟨Ĥ⟩
> already fully proves this point.
>

Why, since neither H or embedded_H are actually UTMs, and it is
establishied that both of them declare their input to be non-halting
when the machine they are given the description of Halt.

That just proves that you are wrong.

You are just showing that you like to call the Truth to be Lies, and
Lies to be Truth because you can't tell the difference between them
because you are a pathological liar.

[olcott]

*Clearly you are clueless about what the term isomorphism means*
Both D and ⟨Ĥ⟩ have the exact same form in that both D and ⟨Ĥ⟩ attempt to
do the opposite of whatever their corresponding halt decider determines.

Both of them loop when their halt decider returns {halts} and both halt
when their halt decider returns {non-halting}. Both of them continue to
call the halt decider in recursive simulation until their halt decider
stops simulating them.

[Richard Damon]

Right, so since the Halt Decider must have a defined behavior when given
them as an input, that defined behavior will always be wrong, because no
matter how you define your H, the machines will act the other way. This
is what proves that there can't be a decider that gets all input right.

NEITHER H or embedded_H are UTM's if they answer non-halting, so the
fact that the don't reach a final state in there PARTIAL (and thus not
correct by UTM rules) simulation is irrelevant.

The ACTUAL UTM simulation of the input (which calls H) will see that it
Halts, thus, the CORRECT simulation of the input is Halting, and the one
generated by your machines is shown to be NOT CORRECT by the needed
definition, it is just a PARTIAL SIMULATION, which doesn't prove
non-halting.


And actually, H/D is NOT really isomorphic to H / embedded_H to H^, as
the input to H and embedded_H is a totally distinct thing to H /
embedded_H and just contains a COPY of the input. This is a flaw in your
H/D model. D really needs to have its own copy of the code of H and be
"run"/simulated in a seperate address space of the deciding H.

This is a significant change of form, that has been pointed out to you
for years, but it hasn't seemed to get through your pathological shields.

[olcott]

I did not say that precisely enough.

Both of the simulated inputs [WOULD] loop if their corresponding halt
decider [WOULD] return {halts} to them and [WOULD] halt loop if their
corresponding halt decider [WOULD] return {non-halting} to them yet the
actual case is that they remain stuck in recursive simulation until
their corresponding halt decider stops simulating them.

Thus as you admitted for the H/D pair also applies to the
embedded_H / ⟨Ĥ⟩ pair. The simulated input cannot possibly terminate
normally because it remains stuck in recursive simulation until the
simulation is terminated *IN BOTH CASES*

[olcott]

You seem to be acting like the HBO Westworld character Bernard that was
a robot (AKA host) was almost perfectly a very smart human except that
his brain was hard-wired to not be able to "see" a specific door.

Then, once they're inside the dark house where Ford's robotic family
lives, Theresa asks what's behind one of the doors. "What door?" Bernard
asks, and that's when you know he's a host as well. The door is plain as
day, even in the dark, and he's been there before. And yet, he couldn't
see it.

https://www.forbes.com/sites/erikkain/2016/11/14/one-of-the-biggest-westworld-fan-theories-just-came-true/?sh=5bcd83a38a3e

[Richard Damon]

Nope, because the MUST give an answer in finite time based on a
determinsitic algorithm.

Thus, either they answer halting, and get a non-halting input, or they
answer non-halting, and get a Halting input.

>
> Thus as you admitted for the H/D pair also applies to the
> embedded_H / ⟨Ĥ⟩ pair. The simulated input cannot possibly terminate
> normally because it remains stuck in recursive simulation until the
> simulation is terminated *IN BOTH CASES*
>

Then you are saying you H will NEVER abort its simulation, and thus it
never answers and fails to be a decider.

Remember, the ultimate question is what the machine described by the
input does, and that machine calls H with EXACTLY the same parameters as
the independent call, and thus gets exactly the same answer, so H will
always be wrong.

If H doesn't return to D, it can NEVER return.

You try to clai otherwise, but when asked to show at what point between
the direct call to H, and the direct running of D calling H differ, you
can't point it out, because it doesn't happen. (Remember, we aren't
asking about D simulated by H, but D actually being run, calling H, just
like the indepenedant call to H and both of them then simuating the input.

Your arguement just shows that you don't understand how programs actual
work.

[Richard Damon]

So, where do Main -> H(D,D) and main -> D(D) -> H(D,D) differ in their
execution path?

You claim they differ, so show it.

That, or you are claiming that a "Correct Simulation" can differ from
the actual machine behavior, despite that going against the definition.

I guess "Correct Reasoning" isn't something you use yourself, just that
you argue that others don't do.

[olcott]

If you really do know software engineering then you already know on the
basis that you already agreed that D simulated by H cannot terminate
normally.

When you ask a question that you already know the answer to then you are
only playing head games.

> That, or you are claiming that a "Correct Simulation" can differ from
> the actual machine behavior, despite that going against the definition.
>

You already admitted that D simulated by H never terminates normally.
Thus you knew that H is correct to abort its simulation of D to prevent
its own infinite execution.

The reason that I did this concretely in C is the there is no wiggle
room of ambiguity to deny what is actually occurring.

> I guess "Correct Reasoning" isn't something you use yourself, just that
> you argue that others don't do.

[Don Stockbauer]

I think what happened was that after I sent my email to you that some nefarious force within the bowels of the machine changed it around to that awful statement which got me in trouble and dissociated our relationship.

[Richard Damon]

Yes, but the question isn't what does the (partial) simulation by H
show, but what does the machine repesented by the input do.

Since H doesn't simulate all of the behavior of D, its simulation
doesn't directly prove that answer.

> When you ask a question that you already know the answer to then you are
> only playing head games.

Excdpt what the simulation by H does isn't the question that H is
supposed to be answering.

>
>> That, or you are claiming that a "Correct Simulation" can differ from
>> the actual machine behavior, despite that going against the definition.
>>
>
> You already admitted that D simulated by H never terminates normally.
> Thus you knew that H is correct to abort its simulation of D to prevent
> its own infinite execution.

H is allowed to abort its simulation for any reason its programmer
wants. It still needs to give the right answer to be correct, and that
answer needs to describe the behavior of directly running the machine
given an input.

Since H(D,D) has been said to return 0, we can by simple inspection, and
verify by actually running it, see that D(D) will Halt, which means that
H's answer is just wrong.

It might be a correct POOP decider, but only you seem interested in your
POOP.

>
> The reason that I did this concretely in C is the there is no wiggle
> room of ambiguity to deny what is actually occurring.

Nither is there in Turing Machines.

[olcott]

My way results in a halt decider that recognizes the actual behavior of
the actual input so that it doesn't get stuck in recursive simulation.

You way simply denies the reality actual behavior of the actual input
and gets stuck in infinite recursion.

When a simulating halt decider

(a) H correctly simulates N steps of its input D until
(b) H correctly determines that its simulated D would never stop running
unless aborted then
(c) H can abort its simulation of D and correctly report that D

specifies a non-halting sequence of configurations.

> Nither is there in Turing Machines.
>
>>
>>> I guess "Correct Reasoning" isn't something you use yourself, just
>>> that you argue that others don't do.
>>
>

[Richard Damon]

No, becase the ACTUAL BEHAVIOR of the machine in question is what it
does when actually run.

Since H doesn't do a simulation that meets the ACTUAL requirements of a
UTM, it results don't count.

Since D(D) Halts, H(D,D) returning zero CAN'T be correct.

All you have done is solved a Strawman Problem, which isn't a solution
to the problem in question.

>
> You way simply denies the reality actual behavior of the actual input
> and gets stuck in infinite recursion.

The ACTUAL BEHAVIOR is DEFINED as what the ACTUAL MACHINE does.

IT HALT.

THUS H IS WRONG.

You are just living in a world of lies.

>
> When a simulating halt decider
> (a) H correctly simulates N steps of its input D until
> (b) H correctly determines that its simulated D would never stop running
> unless aborted then
> (c) H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.

Nope. Just a Strawman, since H never CORRECTLY does any of those things.

I guess that is your problem, you don't understand what is Truth, so you
don't understand what is CORRECT.

You are just living in a pathological world of Pathological lies.

[olcott]

You keep insisting on staying out-of-sync by one recursive invocation.

[olcott]

You keep insisting on staying out-of-sync by one recursive invocation.

Can D correctly simulated by H terminate normally?
H uses an x86 emulator to correctly simulate D.

01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }

*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11

*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...

Anyone that is competent and honest can see that D
remains stuck in recursive simulation when H uses
its x86 emulator to correctly simulate D.

[Richard Damon]

What recursiv4 INVOCATION?

H NEVER "invokes" D, it conditionally simulates it to decide on it.

So what is the difference ihn execution between:


main() -> D(D) -> H(D,D) ...
and
main() -> H(D,D) ...

in both cases the H(D,D) will return 0, if not what instruction executed
in H gives a different result just because D(D) called H instead of main?

Since H(D,D) returns 0 to D(D), it it trivial to see that D(D) will halt.


You are just showing your total ignorance on the very basics.

Note, the equivalence of simulation and execution is based on
UNCONDITIONAL simulation, which H doesn't do an unconditional simmulation.

"Unconditinal" doesn't mean do it until some condition occurs.

[Richard Damon]

Why does that matter?

Since H is being asked about the actual execution of D(D).

> H uses an x86 emulator to correctly simulate D.

No, it partially simulates the execution path o D.

Since you ar equating simulation to direct execution, the only meaning
of correct includes being COMPLETE.

>
> 01 int D(int (*x)())
> 02 {
> 03  int Halt_Status = H(x, x);
> 04  if (Halt_Status)
> 05    HERE: goto HERE;
> 06  return Halt_Status;
> 07 }
> 08
> 09 void main()
> 10 {
> 11  H(D,D);
> 12 }
>
> *Execution Trace*
> main() calls H(D,D) that simulates D(D) at line 11
>
> *keeps repeating*
> simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...

Nope, not what happens, since at some point H will decide it went far
enough and abort its simulation and return 0 which causes D to return.

Thus a CORRECT SIMULATION of its input will do likewise, it is just
impossible for H to do that correct simulation

>
> Anyone that is competent and honest can see that D
> remains stuck in recursive simulation when H uses
> its x86 emulator to correctly simulate D.
>
>

Right, but the H that does that correct simulation fails to be a
decider, becuase it never returns an answer, EVER.

Again, please show the step in H

main -> D(D) -> H(D,D) ...
that differs from
main -> H(D,D)


Until you do, it is just a lie that H(D,D) can correctly simulate D(D)
in an infinte loop in one call, but with finite behavior to return an
answer in the other.

If you say it can't return an answer to something that forms a
pathological relationship with it, what x86 instruction in H cause that
to happen?

You have just been lying about this all the time, because that is your
native language, lies, because you just don't know what Truth actually
is, so you can't help yourself.

[olcott]

*This is factually incorrect*
H is only being asked about the behavior of its input.
H is not being asked about the behavior of a non-input.

You already know that a decider computes the mapping
*from its input* to its own accept or reject state.

The behavior of the non-input is the behavior that is one
recursive invocation removed from the behavior of its input.

>> H uses an x86 emulator to correctly simulate D.
>
> No, it partially simulates the execution path o D.
>
> Since you ar equating simulation to direct execution, the only meaning
> of correct includes being COMPLETE.
>
>>
>> 01 int D(int (*x)())
>> 02 {
>> 03  int Halt_Status = H(x, x);
>> 04  if (Halt_Status)
>> 05    HERE: goto HERE;
>> 06  return Halt_Status;
>> 07 }
>> 08
>> 09 void main()
>> 10 {
>> 11  H(D,D);
>> 12 }
>>
>> *Execution Trace*
>> main() calls H(D,D) that simulates D(D) at line 11
>>
>> *keeps repeating*
>> simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...
>

[Richard Damon]

Which is DEFINED as the Behavior of the Machine it describes.

> H is not being asked about the behavior of a non-input.

So, you think the x86 code of a program isn't a suitable description of
an x86 program?

>
> You already know that a decider computes the mapping
> *from its input* to its own accept or reject state.

Right, and the "Input" is a description of a machine it is to decide the
behavior of.

In fact, you CAN define the behavior basd on simulation, as long as the
simulation is of the right sort, that of an UNCONDITION COMPLETE SIMULATION.

H needs to answer about what your x86 simulator, if put into pure
simulation mode, would do when simulating the input to H.

That is its exact input, just not what it itself would do with it. That
is the difference between accurately simulating an input and deciding on
it. Accurate simulations of a non-halting input take forever, deciding
on it must take finite time.

Thus, H(P,d) needs to decide what UTM(P,d) would do with the exact same
input. Note, D calls H, not the machine simulating it, so UTM(D,D) would
see D(D) calling H(D.D) and what H(D,D) does with that input.

>
> The behavior of the non-input is the behavior that is one
> recursive invocation removed from the behavior of its input.

Nope, You are just proving you don't understand a THING about the problem

I guess this is why you can't understand how Turing Machine works. They
are defined simply enough you can't twist them.

[olcott]

You keep disagreeing with the easily verified fact that D correctly
simulated by H cannot possibly terminate normally thus conclusively
proving your total lack of any interest in an honest dialogue.

[Richard Damon]

Which is an irrelevent fact, since we aren't asking H about its own
PARTIAL simulation of its input, but the actual behavior of the machine,
or the behavior of a ACTUAL UTM (which means complete) simulation of the
input.

You are just proving you beleive that Strawman are valid arguement forms.

You are just proving your brain is full of straw.

You don't understand what a UTM is, or what a Halt Decider is being
asked to decide. You FAIL at understanding what requirements mean, all
of which show you totally don't understand what Truth is, so your
"Correct Reasoning" is show to just be an oxymoron, because you seem to
be a regular moron.

[olcott]

simulated by H cannot possibly EVER terminate normally even if the
simulation could be infinite.

This seems to conclusively prove that your software engineering skills
are not very good or you have no intention on participating in any

[Richard Damon]

I don't like to get into a battle of wits with an unarmed opponent, but
it seems you insist.

Please show where you claim has ANY actual significant, and isn't just
the strawman that describes your brains.

A Halt Decider is DEFINED to return an answer based on the behavior of
the machine DESCRIBED by its input, not a PARTIAL simulation done by the
decider.

Yes, you can replace it with a simulation by the properties of a UTM,
but that requires the simulation to follow the rules of a UTM, one of
which REQUIRES that it fully repoduce the behavior of the machine
described to it, and thus it CAN NOT STOP until it reaches a final
state. Since H does stop (or doesn't answer), it isn't doing a
simulation per the definition of a UTM, so its simulation isn't
"Correct" enough to be used.

You like to point out that a deccider must compute its mapping based on
the behavior of its input, which is corrrect, but since this applies to
ALL deciders, not just Halt Decider, this doesn't answer the question,
"What is the behavior of the input?", Since we are talking Hat Deciders,
that obvious means the behavior we are talking about is Halting, which
as you like to quote is a behavior of a MACHINE (not an "input") and is
that the MACHINE reaches a final state. What machine? well the machine
described by the input, so H(D,D) is asking about the machine D(D) (not
H's simulation of that input, that has NO correct reasoning connection
to Halting).

Yes, again, we can replace the machine with a UTM simulation of that
machine, but again, by the definition of a UTM, that is a simulation
that NEVER stops until it reaches the final state, so H's simulation
isn't that of a UTM.

It doesn't matter that you might have started with an algorithm for a
UTM, your "modification" have broken its ability to still be a UTM, just
like a hot rod shop might start with a street legal car, but the final
vehicle might well not be street legal (but better suited for its new
purpose).

Again, since we know that D(D) will halt because you have declaired that
H(D,D) will "correctly" return 0, so, we can prove that you don't
understand what the word "Correctly" means, since to be correct it needs
to match the actual answer for the problem.

If the math exam ask you what 1 + 2 is equal, you can't say "12" because
that is what "1" + "2" means in some computer language, that is just the
WRONG answer, because it is to the WRONG question.

You may be able to correctly say that D(D) doesn't POOP, so H(D,D)
returning 0 is a correct answer for a POOP detector, but since you can't
detect that you logic is just shit, we can't really even count on you to
know what POOP is really about.

You are just proving that you are totally incompetent at all the things
you have been talking about, and that you are just a ignorant
pathological lying idiot.

[olcott]

In other words you simply {don't believe in} mathematical induction that
correctly infers an infinite sequence from a finite sequence.
https://en.wikipedia.org/wiki/Mathematical_induction

Anyone with sufficient software engineering skill can easily determine
that D correctly simulated by H will never terminate normally after N
simulated steps for any value of N.

[Richard Damon]

So, no answer to any of the questions, I guess you are ADMITTING that
you have no answers.

> In other words you simply {don't believe in} mathematical induction that
> correctly infers an infinite sequence from a finite sequence.
> https://en.wikipedia.org/wiki/Mathematical_induction

SO, provide the VALID induction proof for you assertion.

Remember to include the fact that EVERY H might abort its simulation.

I don't think you know how to do an actual proof by induction.

You are just showing that you are using word salid.

Yes, if you can actualy make a SOUND and VALID proof, from the partial
simulation, you can do so.

H doesn't have enough information to make that decision, it can't even
know that the machine is the pathological one, as it never say what
happens after the answer. As far as it knows, and it can not
distinguish, between a machine that Always Halts, Never Halt, Agrees
with H, or Disagrees with H.

All H has done is say if the H is D is a different program that the H
that it is actually is (the H that gives the anwer), then it will be
non-halting, in other words, you have LIED that D was built by the
rules, or that H is actually examining and reasoning about the input
given to it.

YOU FAIL

>
> Anyone with sufficient software engineering skill can easily determine
> that D correctly simulated by H will never terminate normally after N
> simulated steps for any value of N.
>

Really?

Since that isn't the question, why does it matter?

Why is it a CORRECT simulation when it doesn't match the definition of
correct needed to make the substitution of the behavior of the machine
described by the input with a "Correct Simulatioon"

You got nothing.

You just proved you are unarmed in this battle of wits.

[olcott]

You must not have any software engineering skill.

It is probably a good idea that I create an actual inductive proof.
Partial proof of program correctness has always relied on an adaptation
of mathematical induction, thus I can cite sources that this adaptation
is known to be legitimate.

[Richard Damon]

No, you seem to lack the basic concepts of requirements

Since you have admitted you are wrong, by not providing answers to any
of the questions, I don't need to go any further,

You arguement is refuted, and you are just admitting you are just a
ignorant pathological lying idiot by repeating them.

You seem incapable of actually proving anything, so you are just going
to go to hell for all your lies, and likely sentenced to just working on
your proof, which can never be completed forever.

[olcott]

I still remembered the guy's name that essentially invented proof of
program correctness. I took a course on this and got an A. I have two
textbooks on proof of program correctness. It is all anchored in
mathematical induction.

[Richard Damon]

Even so, you are just proving you don't remember any of that materieal
because you still can't answer any of the question, but keep resorting
to the fallacies of things like the Strawmn and Red Herrings.

Your H isn't correct, because D(D) WILL Halt since H(D,D) returns 0.

Since you just refuse to answer the refutations, and provide ANY actual
proof of your claims, you are shown to just be an ignorant pathological
lying idiot, and your precisous "Correct reasoning" to be just a pile of
crap.

You claim to have an "Inductive proof" of your claim, if so, SHOW IT,
just making an unsubstantiated claim tha that you know what induction is
because you got an A in a course that used it means nothing. If you
actually can prove it, which you can't, since it is demonstratably
false, show the actual proof by proving the two required facts for the
inductiv4 proof.

[olcott]

On 5/25/2023 6:16 AM, Ben Bacarisse wrote:
> Fritz Feldhase <franz.fri...@gmail.com> writes:
>
>> On Wednesday, May 24, 2023 at 9:14:36 PM UTC+2, Richard Damon wrote:
>>
>> Following pseudocode for D:
>>
>> arbitrarily long int D(int start) {
>>
>> arbitrarily long int n = start
>>
>> while (n is not a perfect number) {
>> n = n + 2
>> }
>>
>> return n
>> }
>>
>> What would Olcott's "simulating halt decider" return (answer) if
>> called with, say, H(D, 1)?
>
> Why would you care? PO's H returns "does not halt" for at least some
> halting computations (citations available on request) so the result
> tells you nothing of interest.
>
> PO equivocates over whether he is concerned about just the one case used
> in the usual proof's construction or the general case, but regardless of
> what side of that fence he is currently sitting, you can't use his H for
> anything useful.
>
>> How would it know the correct answer? Will it ever return an answer?
>> (Especially, _if_ there is no odd perfect number?)
>
> On some days he will claim that he has never said he has a general halt
> decider, just one that can't be fooled by the "usual construction". It
> "can't be fooled" because he simply declares that H(H^, H^) == false is
> the correct answer "even though" H^(H^) halts.
>
> On other days, he throws caution to the wind and claims the general
> case, but again with the set of non-halting computations "augmented" by
> some unspecified set of halting ones.
>
> Of course, he is also not an honest disputant, because he will avoid
> giving a direct answer to a simple question for years (literally years),
> and he will even say contradictory things days apart (again, citations
> available on request) so it can take some time to clear all the smoke
> from the mirrors. But once he has said
>
> "Yes that is the correct answer even though P(P) halts."
>
> in reply to the question "do you still assert that H(P,P) == false is
> the 'correct' answer even though P(P) halts?" I don't see any point in
> carrying on, or at least I see not point in saying anything else.
>
> The one weapon we have against cranks is that most can't bear to retract
> any substantive claim. This is why they are usually so evasive about
> giving direct answers -- they know they will have to stick with them.
> But once they have made the mistake of being clear, we should pay them
> the courtesy of quoting them at every available opportunity.
>

Ben has already agreed that H does correctly determine that halt status
of its input according to the Sipser approved criteria. (see quote
below) The Sipser approved criteria is a tautology thus necessarily
true.

Because all deciders only compute the mapping *from their inputs* to
their own accept or reject state and the only objection to my proof is
that it does not get the same result as a non-input this only objection
is nullified. *My proof is correct by tautology*

My reviewers insist on staying one recursive invocation away from
reality. H does correctly determine that D correctly simulated by H
cannot possibly terminate normally.

My reviewers only focus on the behavior after H has already made this
correct halt status decision, thus are clearly out-of-sync by one
recursive invocation.

01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }

*At 10/13/2022 11:29 AM in an email*
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.

*It is clear that the above is a tautology thus necessarily true*
and H does determine the halt status of D precisely according to that
criteria and *Ben has agreed to this*

On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
> ...D(D) would not halt unless H stops the simulation.
> H /can/ correctly determine this silly criterion (in this one case)...

H(D,D) fully operational in x86utm operating system:
https://github.com/plolcott/x86utm

[olcott]

Because all deciders only compute the mapping *from their inputs* to
their own accept or reject state and the only objection to my proof is
that it does not get the same result as a non-input this only objection
is nullified. *My proof is correct by tautology*

My reviewers insist on staying one recursive invocation away from
reality. H does correctly determine that D correctly simulated by H
cannot possibly terminate normally.

My reviewers only focus on the behavior after H has already made this

correct halt status decision, thus are clearly out-of-sync by one
recursive invocation.

> Since you just refuse to answer the refutations, and provide ANY actual
> proof of your claims, you are shown to just be an ignorant pathological
> lying idiot, and your precisous "Correct reasoning" to be just a pile of
> crap.
>
> You claim to have an "Inductive proof" of your claim, if so, SHOW IT,

*You already know the simulation invariant*

01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }

*D correctly simulated by H cannot possibly reach its own line 04*

> just making an unsubstantiated claim tha that you know what induction is
> because you got an A in a course that used it means nothing. If you
> actually can prove it, which you can't, since it is demonstratably
> false, show the actual proof by proving the two required facts for the
> inductiv4 proof.

The course was mathematical proof of program correctness.

[Richard Damon]

That isn't an "Induction Proof"

I guess you don't know how to do an inductive proof.

>
> 01 int D(int (*x)())
> 02 {
> 03  int Halt_Status = H(x, x);
> 04  if (Halt_Status)
> 05    HERE: goto HERE;
> 06  return Halt_Status;
> 07 }
> 08
> 09 void main()
> 10 {
> 11  H(D,D);
> 12 }
>
> *D correctly simulated by H cannot possibly reach its own line 04*

So, that doesn't mean that D(D) is none halting, only that H can't do a
correct simulation per the requirements of a UTM

>
>> just making an unsubstantiated claim tha that you know what induction
>> is because you got an A in a course that used it means nothing. If you
>> actually can prove it, which you can't, since it is demonstratably
>> false, show the actual proof by proving the two required facts for the
>> inductiv4 proof.
>
> The course was mathematical proof of program correctness.
>

So, I guess you are admitting that you can't do an actual inductive
proff, or even know what that actually entails.

[Richard Damon]

Nope, you MIS-QUOTE him by removing context, which is just a form of LYING.

> Because all deciders only compute the mapping *from their inputs* to
> their own accept or reject state and the only objection to my proof is
> that it does not get the same result as a non-input this only objection
> is nullified. *My proof is correct by tautology*

SO, what mapping is this supposed to compute, if this is what ALL
decider do, is "Halting" the only type of decider?

Remember, Halting is DEFINED as the MACHINE coming to a final state, and
it does.

>
> My reviewers insist on staying one recursive invocation away from
> reality. H does correctly determine that D correctly simulated by H
> cannot possibly terminate normally.

Except YOU are one invocation from the probem. It isn't asking about the
simulatiion done by H, but by the machine that H is TRYING to simulate
(but can't).

>
> My reviewers only focus on the behavior after H has already made this
> correct halt status decision, thus are clearly out-of-sync by one
> recursive invocation.

Because it makes the WRONG decision by the definition of the problem,
what does the machine represented by the input do?

YOU are the one just focusing on your POOP, and getting the wrong answer
for the actual question, which is the HALTING of the actual machine.

You don't seem to understand the the TURING MACHINE described by D is
the actual MACHINE, not H's attempt at simulating it.

>
> 01 int D(int (*x)())
> 02 {
> 03  int Halt_Status = H(x, x);
> 04  if (Halt_Status)
> 05    HERE: goto HERE;
> 06  return Halt_Status;
> 07 }
> 08
> 09 void main()
> 10 {
> 11  H(D,D);
> 12 }
>
> *At 10/13/2022 11:29 AM in an email*
> MIT Professor Michael Sipser has agreed that the following verbatim
> paragraph is correct (he has not agreed to anything else):

Right, and i n particular, what you don't seem to grasp is for H to meet
the requirements, it need to correctly determine that an UTM simulation
of the input would never stop, that is a simulation that doesn't stop

until it reaches a final state.

Since a UTM simulation of this input DOES reach a final state, as it
simulates H past the point that H gives up and returns 0 to D, you never
satisfy the conditions given.

>
> 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.
>
> *It is clear that the above is a tautology thus necessarily true*
> and H does determine the halt status of D precisely according to that
> criteria and *Ben has agreed to this*
>
> On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
> > ...D(D) would not halt unless H stops the simulation.
> > H /can/ correctly determine this silly criterion (in this one case)...

He said:

Are you dancing round the fact that PO tricked the professor?

H(D,D) /does/ meet the criterion for PO's Other Halting problem -- the
one no one cares about. D(D) halts (so H is not halt decider), but D(D)

would not halt unless H stops the simulation. H /can/ correctly

determine this silly criterion (in this one case) so H is a POOH decider
(again, for this one case -- PO is not interested in the fact the POOH
is also undecidable in general).


Note, your OTHER problem, the one with the incorrect definition of what
it decides.


I guess by quoting him as support, you are admitting you are talking
about the problem Ben was refering to, you POOP, based on your "silly"
criterion.


Thank you for making that clear.

You are just proving that you are the ignorant pathological lying idiot
that you have made yourself out to be.

[olcott]

The context does not change the fact that he agreed that H does
correctly determine the halt status of D according to the Sisper
approved criteria.

>> Because all deciders only compute the mapping *from their inputs* to
>> their own accept or reject state and the only objection to my proof is
>> that it does not get the same result as a non-input this only objection
>> is nullified. *My proof is correct by tautology*
>
> SO, what mapping is this supposed to compute, if this is what ALL
> decider do, is "Halting" the only type of decider?
>
> Remember, Halting is DEFINED as the MACHINE coming to a final state, and
> it does.
>
>>
>> My reviewers insist on staying one recursive invocation away from
>> reality. H does correctly determine that D correctly simulated by H
>> cannot possibly terminate normally.
>
> Except YOU are one invocation from the probem. It isn't asking about the
> simulatiion done by H, but by the machine that H is TRYING to simulate
> (but can't).
>
>>
>> My reviewers only focus on the behavior after H has already made this
>> correct halt status decision, thus are clearly out-of-sync by one
>> recursive invocation.
>
> Because it makes the WRONG decision by the definition of the problem,
> what does the machine represented by the input do?
>

The definition of the problem that you are referring to contradicts the
definition of a decider that must compute the mapping from
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
to an its own accept or reject state.

You think that H is wrong because the outer invocation halts only
because the inner invocation was correctly aborted.

You know that it is necessarily true that no invocation would ever halt
unless the inner invocation was aborted, thus making the termination of
this inner invocation necessarily correct.

Professor Sipser agrees that my criteria is correct which makes perfect
sense because it is a tautology. Ben agrees that H correctly determines
the Halt status of D according to the Sipser criteria.

That Ben does not understand that the Sipser approved criteria is
necessarily true is his mistake not professor Sipesr's.

When my criteria is correct and H determines the halt status of D
according to that criteria then H is correct even if everyone in the
universe disagrees.

The ratio of the diameter to the circumference of a circle was logically
entailed by the concept of round (such as a full Moon) long before this
caveman could count to five.

>
> Thank you for making that clear.
>
> You are just proving that you are the ignorant pathological lying idiot
> that you have made yourself out to be.
>

You define lying to include unintentional falsehood.
That is *NOT* the way that everyone else defines it.

>>
>> H(D,D) fully operational in x86utm operating system:
>> https://github.com/plolcott/x86utm
>>
>>
>

[olcott]

No it is not. It seems to be a good starting point for a proof of
algorithm behavior. All of them are based on some kind of invariant,
it is the most important part.

> I guess you don't know how to do an inductive proof.
>
>>
>> 01 int D(int (*x)())
>> 02 {
>> 03  int Halt_Status = H(x, x);
>> 04  if (Halt_Status)
>> 05    HERE: goto HERE;
>> 06  return Halt_Status;
>> 07 }
>> 08
>> 09 void main()
>> 10 {
>> 11  H(D,D);
>> 12 }
>>
>> *D correctly simulated by H cannot possibly reach its own line 04*
>
> So, that doesn't mean that D(D) is none halting,

*Yes it does. It 100% perfectly means exactly that*

> only that H can't do a
> correct simulation per the requirements of a UTM
>>
>>> just making an unsubstantiated claim tha that you know what induction
>>> is because you got an A in a course that used it means nothing. If
>>> you actually can prove it, which you can't, since it is
>>> demonstratably false, show the actual proof by proving the two
>>> required facts for the inductiv4 proof.
>>
>> The course was mathematical proof of program correctness.
>>
>
> So, I guess you are admitting that you can't do an actual inductive
> proff, or even know what that actually entails.

An inductive proof applied to computations is based on mathematical
induction yet not exactly one-and-the-same thing as mathematical
induction. It was more than 35 years ago that I took this course.

[olcott]

I have better words. The termination of the simulation of D is mandated
by the requirements that a halt decider must always halt, thus
conclusively proving that this termination is necessarily correct.

[Richard Damon]

So, you DON'T have an inductive proof.

You seem to have forgotten a lot in those 35 years.

Maybe you shouldn't make claims you can't back up, like all the claims
you have made.

[Richard Damon]

It is also mandated to give the correct answer, which since H(D,D)
returns 0, which causes D(D) to Halt, the only correct answer that
H(D,D) should give is 1, so it is necessarily incorrect.

[Richard Damon]

SO, you accept that you are talking about a different problem?

If not, you are just proving yourself to be a LAIR.

Right, and its input is the DESCRIPTION of the PROGRAM D, which it is to
decide what that PROGRAM (which its input described) does.

>
> You think that H is wrong because the outer invocation halts only
> because the inner invocation was correctly aborted.

No, it is wrong because the outer invocation aborts its simulation
before it sees that the program it is simulating will halt.

Of course, if it simulated longer, and the input is changed, then that
input waits longer to decide to halt, but if you replace the outer with
a UTM (or even a variation of H that simulates enough longer) then that
will see that the input halts.

>
> You know that it is necessarily true that no invocation would ever halt
> unless the inner invocation was aborted, thus making the termination of
> this inner invocation necessarily correct.

So, that isn't the question. H will do what it will do, but its answer
isn't judged by H's partial simulation, but by the actual beavior of the
actual input, the program described by it "string" given to H, or by the
UTM simulation of the string given to H.

You obviously can't understand the question given to H, because you seem
to be totally ignorant of the language and an idiot.

Yes, the criteria you stated is "Correct", but only if H is correct
about a correct simulation, which means to PRofessor Sipser, the
simulation of an actual UTM.

Since the simulation of an actual UTM of this input halts, H is not
"Correct" in determining that a correct simulation would not halt/

> That Ben does not understand that the Sipser approved criteria is
> necessarily true is his mistake not professor Sipesr's.
>

Nope, the problem is YOU don't understand the meaning of "Correct"

> When my criteria is correct and H determines the halt status of D
> according to that criteria then H is correct even if everyone in the
> universe disagrees.

Except H never does correctly determine the behavior of an actually
correct simulation, since it never does one.

>
> The ratio of the diameter to the circumference of a circle was logically
> entailed by the concept of round (such as a full Moon) long before this
> caveman could count to five.

SO, D(D) Halts, so H(D,D) returning 0 can't be correct.

All you are doing is prove that your "Correct Reasoning" system is
inconsistent and proves contradicitons.

>
>>
>> Thank you for making that clear.
>>
>> You are just proving that you are the ignorant pathological lying
>> idiot that you have made yourself out to be.
>>
>
> You define lying to include unintentional falsehood.
> That is *NOT* the way that everyone else defines it.

So, you are admitting that your statements are incorrect and you are
incapable of understanding that?

I have pointed out that the Natural Language of English accepts as a
possbile definition of Lying as telling something that is clearly
incorrect, even if the person might believe it.

Note, that even applies to legal defenses. You don't need to know that
something is false to be guilty of lying, just having a careless
disregard of what is actually true is enough.

[olcott]

The easily verified fact that H itself would not terminate unless it
aborted the simulation of its input conclusively proves that H is
necessarily correct to do this and report this input as non-halting.

This equally applies to the Peter Linz Turing machine based halting
problem proof with embedded_H and ⟨Ĥ⟩.

[Richard Damon]

So? H not terminating is its own problem. It still needs to give the
right answer. You can't just assume an answer is right because you can't
prove the other answer is right.

All you have done is proved that H can't prove the correct answer, not
that the answer it gives is correct.

You are just showing that your "Correct Reasoning" is anything like
actually correct reasoning, because it claims wrong answers must be correct.

You are just proving that you are a ignorant pathological lying idiot
because you can't see that H saying a progrma that halts is non-halting
because it can't prove to itself that it is halting.

You are just showing how STUPID You are.

It seems you just can't even understand basic English.

[olcott]

Since it is required to terminate the choice to not abort its simulation
would violate this requirement thus making this choice necessarily
correct. This also conclusively proves that its input cannot possibly
terminate normally thus is correctly determined to be non-halting.

[Richard Damon]

So? You still don't get it.

yes, it is required to give an answer in finite time, so it can't just
be programmed to simulate forever. It also is required to return the
correct answer, and can't use needing to give an answer as a reason for
giving the wrong answer.

But, since it DOES abort its simulation, and return 0 when it does, that
makes the machine it is simulating, which is what the question is about,
actually halt, and a correct simulation of this exact same input shows
that behavior, so the non-halting answer is necessarily incorrect.

Your logic assumes that the H that D calls doesn't do the same thing as
the H that is answering, which means your whole arguement is based on a
LIE, as, if H is an equiivalent to a Turing Machine, as clainmed, then
all copies of it will behave exactly the same when given the same input,
and D must be built with a copy of the H that is claimed to be giving
the correct answer.

Thus, you are just proving yourself to be a LIAR, or a total idiot that
doesn't understand ANYTHING about what he is talking about, and since
you are claiming to be an EXPERT, you are lying about something.

Remember, the ACTUAL PROBLEM is about the machine descxribed by its input.

Switching to looking at a simulation involves accepting requirements on
that simulation, which H doesn't meet, so you are just showing you are
an ignorant pathological lying idiot.

[olcott]

Since it is true that unless H aborts its simulation of D that H itself
never terminates normally that makes it necessarily correct to do this.

That you refer to the behavior of executed D after H has already
aborted its simulated of D is one recursive invocation away from
reality.

[Richard Damon]

So, you are admitting that H doesn't actually "terminate normally" and
thus fails to be a decider?

Or is H actually two different programs that you claim to be just one?

You have at times claimed that H behaves differently under different
conditions but have also demonstarted that this statement is incorrect
by failing to provide the simple evidence to demonstart how that could
happen.

In other words, you LIE.

>
> That you refer to the behavior of executed D after H has already
> aborted its simulated of D is one recursive invocation away from
> reality.
>

No, I am talkiag about the behavior of D when actually executed.

Since it has behavior that H didn't simulate, that makes H's simuation
not correct for the purposes of determining the behavior of the machine.


You don't seem to understand the difference between the reality of the
actual execution of the machine, and the make believe world of H's
simulation which it thinks is "correct" when it isn't.

Just like you seem to live in a make believe world what H, while just a
single program, has two different behaviors to the same input.

There is a name of people who can't face reality and just live in a
fantasy world.

[olcott]

Your software engineering skill must be quite awfully terrible to make a
mistake like that.

> Or is H actually two different programs that you claim to be just one?
>

The outer D behaves differently after its own inner D has been aborted
than the inner D that must be aborted behaves.

[Richard Damon]

So, does H "Terminate Normally", at which point, so does the D, or does
H not "Terminate Normally" and thus isn't a decider?

>
>> Or is H actually two different programs that you claim to be just one?
>>
>
> The outer D behaves differently after its own inner D has been aborted
> than the inner D that must be aborted behaves.
>
>

Really, at what instruction is there a difference between the ACTUAL
EXECUTION of the H(D,D) on the outer level, that called by main, and the
H(D,D) call be the D(D) that is called by main?

This has been asked of you, and the answer never provided, because there
is no point this happens.

All you are doing is showinfg that you don't understand what a Turing
Machine actually is and what a correct simulation actually is.

YOU FAIL.

[olcott]

// The following is written in C

01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {

11 D(D);
12 }

*Execution Trace*
main() invokes D(D) at line 11
executed D(D) invokes H(D,D) that simulates D(D) at line 03 ...

*keeps repeating*
simulated D(D) invokes simulated H(D,D) that simulates D(D) at line 03 ...

The simulated D cannot possibly terminate normally and H will
never return to its caller unless and until H aborts its simulation.

>>
>>> Or is H actually two different programs that you claim to be just one?
>>>
>>
>> The outer D behaves differently after its own inner D has been aborted
>> than the inner D that must be aborted behaves.
>>
>>
>
> Really, at what instruction is there a difference between the ACTUAL
> EXECUTION of the H(D,D) on the outer level, that called by main, and the
> H(D,D) call be the D(D) that is called by main?
>

All of the continue to execute

> This has been asked of you, and the answer never provided, because there
> is no point this happens.
>
> All you are doing is showinfg that you don't understand what a Turing
> Machine actually is and what a correct simulation actually is.
>
> YOU FAIL.

[Richard Damon]

So, why doesn't that happen when main calls H?

What instruction in H acts differently because it was called by D
instead of Main.

>
>
>>>
>>>> Or is H actually two different programs that you claim to be just one?
>>>>
>>>
>>> The outer D behaves differently after its own inner D has been
>>> aborted than the inner D that must be aborted behaves.
>>>
>>>
>>
>> Really, at what instruction is there a difference between the ACTUAL
>> EXECUTION of the H(D,D) on the outer level, that called by main, and
>> the H(D,D) call be the D(D) that is called by main?
>>
>
> All of the continue to execute

SO? That means that H never stops if both of them just continue to
execute, so H is not a decider.


I guess you just don't understand how computers, and computer programs,
actually work.

Or, you are just a pathological liar.

[Richard Damon]

But since when main calls H(D,D) that doesn't happen, you have just
admitted that the H that D calls is a different pure function then the H
that main calls, so you have been lying that D is calling the same pure
function H for all these years.

Glad you have come out and admitted that.

Or maybe you have just been lying that you have actually done any of
this, because that isn't what happens when you run D the way you say
using the exact same H as answers.

[olcott]

H does return to its caller when main calls H.

> What instruction in H acts differently because it was called by D
> instead of Main.

Nothing acts differently in H called with (D,D) no matter what calls it.

This simulation invariant is always true:
D correctly simulated by H cannot possibly reach its own line 04

[Richard Damon]

So, which instruction acts differently?

We have two IDENTICAL initial sequence of instructions, the entry to H,
in one case from main, and in the other from D, with identical parameters.

If the results follow different paths, there must be a first point of
departure. What is it.

Your inability to understand this just shows you are a total moron in
reguards to how computer programs work, or it just shows you are a
pathological liar, insisting on thing you say must be true with
absolutdly no factual backing, and proof that they can't be.

>
>> What instruction in H acts differently because it was called by D
>> instead of Main.
>
> Nothing acts differently in H called with (D,D) no matter what calls it.

So, why does one call run forever and the other return?

You seem to be caught in a lie. In one statement you say the act
differently, in the other you say that act the same.

I guess in your fantasy world, same and different are the same, or are
they different but still the same?

>
> This simulation invariant is always true:
> D correctly simulated by H cannot possibly reach its own line 04
>

So? We aren't talking about the D being simulate by H, but the D called
by main, whose behavior DEFINES what a "Correct Simulation" would be.

All you have shown is that no program like H can simulate this form of
input to a final state, even though, if that H does answer 0, it WILL Halt.

So, your arguement has just fallen apart and your "proof" is shown to be
a sham.

[olcott]

H(D,D) always operates the exact same way no matter what calls it.

> We have two IDENTICAL initial sequence of instructions, the entry to H,
> in one case from main, and in the other from D, with identical parameters.
>
> If the results follow different paths, there must be a first point of
> departure. What is it.
>

D(D) is merely the outer invocation that includes H(D,D) as the inner
invocation. Directly executed H(D,D) always behaves exactly the same
way whenever it is invoked.

Because it is an easily verified fact that neither the directly executed
H(D,D) nor the directly executed D(D) would ever terminate normally
unless H aborts its simulation of D, H is necessarily correct to abort
its simulation of D to meet the requirement that itself must halt.

It is also a tautology that when a simulation must be aborted to prevent
the simulator's infinite execution that this simulated input does
specify non-halting behavior to this simulator.

You can call me all kinds of insults and gullible fools will take these
insults as rebuttal. The target audience, however, is not gullible
fools.

[Richard Damon]

So, you admit that D(D) will Halt, so, since H(D,D) is asking H to
decide if D(D) will Halt, it should have answered YES, (1)

>
> Because it is an easily verified fact that neither the directly executed
> H(D,D) nor the directly executed D(D) would ever terminate normally
> unless H aborts its simulation of D, H is necessarily correct to abort
> its simulation of D to meet the requirement that itself must halt.

No it DOES terminate because it DOES abort is simulation, since that is
what the code says to do. No need to argue about a fantasy case that
doesn't exist.

In this problem, there does not exist an H that doesn't abort its
simulation, that program just doesn't exist here. That would be a
DIFFERENT program.

>
> It is also a tautology that when a simulation must be aborted to prevent
> the simulator's infinite execution that this simulated input does
> specify non-halting behavior to this simulator.

Yes, but that means if you change the simulator, but NOT the input, to
not abort, it must run forever. Since you can't do that in your broken
model, that tautology isn't applicable.

>
> You can call me all kinds of insults and gullible fools will take these
> insults as rebuttal. The target audience, however, is not gullible
> fools.
>

Fine, you are the ignorant pathological lying idiot, and I will continue
to point out the errors in your logic that your stupid brain can't
understand so a target audience with any bit of reasoning will
understand how broken your argument is.

I am counting on the audience not to be a gullible fools, so am showing
what the truth actually is.

Your logic is as bad as Trump's, and only someone as dumb as a Trump
Supporter would believe your lies.

I am really coming to the conviction that you are just mentally
incapable of understanding, and am just limiting the spread of your
cancerous folly.

[olcott]

*Halting auto problem repair shop analogy*
(a) You take your car to the repair shop.
(b) The car is badly in need of a replacement exhaust system.
(c) You ask the head mechanic to inspect your car's exhaust system.
(d) The head mechanic tells you it needs to be replaced.
(e) You authorize the head mechanic to replace the exhaust system.
(f) At the checkout counter you accuse the head mechanic of lying
because your car clearly does not need to have its exhaust system
replaced.
(g) You refuse to pay on this basis.
(h) The owner calls the police and they tell you pay up or go to jail.

H is asked the question: Does your input need to be aborted to prevent
infinite simulation? H correctly answers yes and aborts the simulation.

Countless reviewers disagree on the basis that after H has already
aborted its simulation of its input the simulation of this input does
not need to be aborted.

[Richard Damon]

Nope, H is asked the question, does the machine represented by your
input finish running in finite time?

Read the problem again. It seems the words must be too big for you to
understand.

It was NEVER about the simulation by the decider. It CAN be changed to
be about the simulation by a UTM, which BY DEFINITION is a machine that
simulates until it reaches the end, so H isn't such a machine.

So, yes, by your repair shop analogy, YOU are the repair shop that
actually DID say the exhaust needed to be replaced because they plugged
the exhaust system before running the test.

>
> Countless reviewers disagree on the basis that after H has already
> aborted its simulation of its input the simulation of this input does
> not need to be aborted.
>

Except it was NEVER about H's simulation, but about the behavior of the
actual machine, and THAT doesn't "stop" when its simulation is abort.

You are just shown to be the ignorant pathological lying idiot.

You don't even seem to know the problem you are trying to solve, but
have replaced it by a strawman built out the straw in your brains.

[Richard Damon]

On 5/26/23 7:31 PM, olcott wrote:
>

> H is asked the question: Does your input need to be aborted to prevent
> infinite simulation?  H correctly answers yes and aborts the simulation.

Simple question, Where do you find this requirement stated by ANYONE but
you?

This is the foundation of your lies.

[olcott]

That is asking the question:
Does my exhaust system need to be replaced after you just replaced it?

[Richard Damon]

Why do you say that?

The "Exhaust System" is the ACTUAL THING, that would be the PROGRAM IN
QUESTION.

Maybe in your case the mechanic just duct taped over the holes and
claimed to replace it.

Or maybe he ran around the block to get himself "exhausted" and then to
a nap to replace it.


You have shown you don't know the actual question, or what any of terms
actually mean.


As I asked, where do you get your question from. All the sources you
quote comment about asking about the machine described.

You are just showing yourself to be a liar, and resorting to all the
fallacies in the book,

[olcott]

We cannot say that the YES answer original question:
(a) Does the exhaust system need to be replaced?
(b) Does the simulation need to be aborted?

Is proven to be incorrect on the basis of after
(a) The exhaust system has been replaced.
(b) The simulation of the input has been aborted.
The answer to the original question becomes NO.

The answer to the question:
Is it possible for D correctly simulated by H to terminate normally?
Competent and honest software engineers concur

[Richard Damon]

Except (b) isn't the question of a Halt Decider.

It should be "Does the Machine Described Reach its final state when run?"

You are just working with the strawman built out of the straw in your brain.

You keep repeating that error and ducking the question you can not
answer because you are just lying about what you are doing.

>
> Is proven to be incorrect on the basis of after
> (a) The exhaust system has been replaced.
> (b) The simulation of the input has been aborted.
> The answer to the original question becomes NO.

WRONG, the question was NEVER about H's simulation, but about the
behavior of the machine described.

You changed the spark plugs instead of the exhaust system.

>
> The answer to the question:
> Is it possible for D correctly simulated by H to terminate normally?
> Competent and honest software engineers concur
>

But that isn't the question, showing you are a liar.

Show a reliable source, not you, that says a Halt Decider needs to
answer the question the way you are asking.

Remember, if H stops its simulation, it isn't a UTM, so a question about
UTM simulation isn't asking about H's simulation.

You can't, because everything you have done is based on LIES.

[olcott]

When your exhaust system needs to be replaced
The question: Does my exhaust system need to be replaced?
has YES as a correct answer.

We can't say that this answer is wrong on the basis that the
answer changes to NO *After the exhaust system has been replaced*

When we ask Does the input to H terminate normally?
the answer is always NO.

We can't say that that answer is wrong on the basis of the
behavior of D after the input to H has been aborted.

*A different context makes it a different question*

> You are just working with the strawman built out of the straw in your
> brain.
>
> You keep repeating that error and ducking the question you can not
> answer because you are just lying about what you are doing.
>
>>
>> Is proven to be incorrect on the basis of after
>> (a) The exhaust system has been replaced.
>> (b) The simulation of the input has been aborted.
>> The answer to the original question becomes NO.
>
> WRONG, the question was NEVER about H's simulation, but about the
> behavior of the machine described.
>
> You changed the spark plugs instead of the exhaust system.
>
>>
>> The answer to the question:
>> Is it possible for D correctly simulated by H to terminate normally?
>> Competent and honest software engineers concur
>>
>
> But that isn't the question, showing you are a liar.
>
> Show a reliable source, not you, that says a Halt Decider needs to
> answer the question the way you are asking.
>
> Remember, if H stops its simulation, it isn't a UTM, so a question about
> UTM simulation isn't asking about H's simulation.
>
> You can't, because everything you have done is based on LIES.
>
>
>

[Richard Damon]

Which ISN'T the question!, and your repeating that just shows you to be
a LIAR. NO ONE (except you) is interested in your question.

As you have posted before, from
https://en.wikipedia.org/wiki/Halting_problem

In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and an
input, whether the program will finish running, or continue to run forever.

SO, the question is EXACTLY about the behavior of the program described.

Since D(D) Halts, the answer is Halting.

>
> We can't say that that answer is wrong on the basis of the
> behavior of D after the input to H has been aborted.
>

But D itself can't be "aborted" so the behavior of the problem is what
the actual machine does.

You are just caught in your lies based on the strawman u

> *A different context makes it a different question*

WHAT "different context"?

Are you admitting your simulating Halt Decider isn't actually a Halt
Decider?

After all, from the DEFINITION of the problem, the question is about the
machine "D", not the simulation by "H". Nothing in the question refers
to the decider at all, just indirectly by means of the input, which is
just a description.

So, it seems that when the customer came in to have his exhust system
changed, your repair shop just wrote the words "New Exhaust System" an
put it on the old one, and then said they gave him a "New Exhaust System".


You are just proving how stupid and ignorant you are.

[olcott]

We can't say that D(D) halts on the basis that its otherwise infinite
simulation has already been aborted.

This is exactly the same thing as saying that the mechanic lied about
your car needing a new exhaust system because it doesn't need one after
it has been replaced.