On 6/25/2025 1:50 AM, Mikko wrote:
On 2025-06-24 15:00:30 +0000, olcott said:
On 6/24/2025 3:53 AM, Mikko wrote:
On 2025-06-23 16:51:23 +0000, olcott said:
On 6/23/2025 2:12 AM, Mikko wrote:
On 2025-06-22 19:16:24 +0000, olcott said:
On 6/22/2025 3:59 AM, Mikko wrote:
On 2025-06-21 17:34:55 +0000, olcott said:
On 6/21/2025 4:52 AM, Mikko wrote:
On 2025-06-20 13:59:02 +0000, olcott said:
On 6/20/2025 4:20 AM, Fred. Zwarts wrote:
Op 19.jun.2025 om 17:17 schreef olcott:
On 6/19/2025 4:21 AM, Fred. Zwarts wrote:
Op 18.jun.2025 om 15:46 schreef olcott:
On 6/18/2025 5:12 AM, Fred. Zwarts wrote:
Op 18.jun.2025 om 03:54 schreef olcott:
On 6/17/2025 8:19 PM, Richard Damon wrote:All of them do abort and their simulation does not need an abort.
On 6/17/25 4:34 PM, olcott wrote:
void Infinite_Recursion()WHich means that the code for HHH is part of the input, and thus there
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
void DDD()
{
HHH(DDD);
return;
}
When it is understood that HHH does simulate itself >>>>>>>>>>>>>>>>>>> simulating DDD then any first year CS student knows >>>>>>>>>>>>>>>>>>> that when each of the above are correctly simulated >>>>>>>>>>>>>>>>>>> by HHH that none of them ever stop running unless aborted. >>>>>>>>>>>>>>>>>>
is just ONE HHH in existance at this time. >>>>>>>>>>>>>>>>>>
Since that code aborts its simulation to return the answer that you
claim, you are just lying that it did a correct simulation (which in
this context means complete)
*none of them ever stop running unless aborted* >>>>>>>>>>>>>>>>
*It is not given that any of them abort*
At least it is true for all aborting ones, such as the one you >>>>>>>>>>>>>> presented in Halt7.c.
My claim is that each of the above functions correctly >>>>>>>>>>>>> simulated by any termination analyzer HHH that can possibly >>>>>>>>>>>>> exist will never stop running unless aborted by HHH. >>>>>>>>>>>>> Can you affirm or correctly refute this?
Yes, I confirmed many times that we can confirm this vacuous claim,
because no such HHH exists. All of them fail to do a correct simulation
up to the point where they can see whether the input specifies a >>>>>>>>>>>> halting program.
if DDD correctly simulated by any simulating termination >>>>>>>>>>> analyzer HHH never aborts its simulation of DDD then
that HHH is not interesting.
*then the HP proofs are proved to be wrong*
No, they are not. You have not solved the halting problem and that >>>>>>>> (in addition to all proofs) supports the claim that halting problem >>>>>>>> is unsolvable.
ChatGPT corrected my words and agreed that I have
correctly refuted the generic HP proof technique
where an input has been defined to only do the
opposite of whatever value that its decider decides.
https://chatgpt.com/s/t_6857335b37a08191a077d57039fa4a76
Doesn't matter. Only proofs matter. So far you have not proven anything >>>>>> and it is unlikely you could prove anything even after asking ChatGPT >>>>>> for help.
The ChatGPT that evaluated and affirmed my analysis
of HHH(DDD) one year ago could only handle 4000 tokens
thus could not understand HHH(DD).
ChatGPT with GPT-4-turbo — can handle up to 128,000 tokens
of context in a single conversation, immediately understood
HHH(DD) within the context of the conversation of HHH(DDD).
ChatGPT does not understand. Whether you do is still not determined. >>>>>>
Anyway,
In order to show that a proof is wrong you need to show an error >>>>>>>> in the proof. Even then the conclusion is proven unless you can >>>>>>>> show an error in every proof of that conclusion.
That you do not understand that any set of expressions of
language that show another expression of language is
necessarily true is its proof is your ignorance not mine.
Only a proof is a proof.
There are things called proofs that have a certain
form and there is the broader concept of proof that
does not require this certain form.
A proof is any set of expressions of language that
correctly concludes that another expression of
language is definitely true.
A singlet set of expressions that just states a correct conclusion
satisfy the above definition but does not prove anything. A proof
is something that gives a sufficient reson to believe what otherwise
might not be believed.
Correct proofs can also depend on the meaning of natural
language words.
It is typical that formal proofs make sure
to totally ignore every aspect of this.
An expression of language is proven true when a set of
semantic meanings makes it true.
To really understand this requires deep understanding of
the philosophy of truth, rather than rote memorization
of some conventional steps.
Two elements that require very deep understanding are
(a) truth-makers and (b) truth-bearers.
Truthmaker Maximalism says that when there is nothing
that makes an expression of language true then this
expression is not true.
A set of expressions is not sufficiently organized to count as a
proof. The conclusion of the proor is its last sentence and in a
set there is no last one.
On 6/26/2025 4:30 AM, Mikko wrote:
On 2025-06-25 14:33:52 +0000, olcott said:
On 6/25/2025 1:50 AM, Mikko wrote:
On 2025-06-24 15:00:30 +0000, olcott said:
A proof is any set of expressions of language that
correctly concludes that another expression of
language is definitely true.
A singlet set of expressions that just states a correct conclusion
satisfy the above definition but does not prove anything. A proof
is something that gives a sufficient reson to believe what otherwise
might not be believed.
Correct proofs can also depend on the meaning of natural
language words.
Yes, and avoid ambiguous expressions or disambiguate them when needed.
It is typical that formal proofs make sure
to totally ignore every aspect of this.
That is the main advantage of formal proofs. But an application
of a formal proof usually requires natural language to express
the interpretation.
An expression of language is proven true when a set of
semantic meanings makes it true.
Often it is sufficiently proven if it is observed to be true
though that of course depends on the qualyty of the obserfation
and of the quality of the report of the observation.
To really understand this requires deep understanding of
the philosophy of truth, rather than rote memorization
of some conventional steps.
Deep understanding is rarely useful. Often it is sufficient to
understand that what is presented as a proof isn't a proof.
Two elements that require very deep understanding are
(a) truth-makers and (b) truth-bearers.
Truthmaker Maximalism says that when there is nothing
that makes an expression of language true then this
expression is not true.
That is not a useful result as the non-existence is usually
unobservable and unverifiable.
Analytical truth has nothing to do with observation
and has everything to do we semantic connections
between expressions of language.
All of math, computer science and logic is analytic truth.
We don't observe that 5 > 3, it is defined that way.
None of which affects the truth that
A set of expressions is not sufficiently organized to count as a
proof. The conclusion of the proor is its last sentence and in a
set there is no last one.
On 6/28/2025 6:47 AM, Mikko wrote:
On 2025-06-27 23:35:46 +0000, olcott said:
On 6/26/2025 4:30 AM, Mikko wrote:
On 2025-06-25 14:33:52 +0000, olcott said:
On 6/25/2025 1:50 AM, Mikko wrote:
On 2025-06-24 15:00:30 +0000, olcott said:
A proof is any set of expressions of language that
correctly concludes that another expression of
language is definitely true.
A singlet set of expressions that just states a correct conclusion >>>>>> satisfy the above definition but does not prove anything. A proof
is something that gives a sufficient reson to believe what otherwise >>>>>> might not be believed.
Correct proofs can also depend on the meaning of natural
language words.
Yes, and avoid ambiguous expressions or disambiguate them when needed. >>>>
It is typical that formal proofs make sure
to totally ignore every aspect of this.
That is the main advantage of formal proofs. But an application
of a formal proof usually requires natural language to express
the interpretation.
An expression of language is proven true when a set of
semantic meanings makes it true.
Often it is sufficiently proven if it is observed to be true
though that of course depends on the qualyty of the obserfation
and of the quality of the report of the observation.
To really understand this requires deep understanding of
the philosophy of truth, rather than rote memorization
of some conventional steps.
Deep understanding is rarely useful. Often it is sufficient to
understand that what is presented as a proof isn't a proof.
Two elements that require very deep understanding are
(a) truth-makers and (b) truth-bearers.
Truthmaker Maximalism says that when there is nothing
that makes an expression of language true then this
expression is not true.
That is not a useful result as the non-existence is usually
unobservable and unverifiable.
Analytical truth has nothing to do with observation
and has everything to do we semantic connections
between expressions of language.
Your claims above were about truth in general with no restriction
to analytical truths. But if you don't know that a sentence has
no truth maker it may be hard to find out.
All of math, computer science and logic is analytic truth.
We don't observe that 5 > 3, it is defined that way.
And that includes the non-existence of halt deciders.
*This is only based on false assumptions*
(a) An *input* can be defined that does the opposite
of whatever its decider reports. // proven false
(b) Turing machines can take directly executing Turing
machines as *inputs* // false by definition
A Turing machine partial halt decider computes the
mapping from a finite string input to the behavior
that this finite string actually specifies.
A Turing machine partial halt decider never computes the
mapping from the direct execution of any other Turing
machine because direct executions are not finite string
inputs.
None of which affects the truth that
A set of expressions is not sufficiently organized to count as a
proof. The conclusion of the proor is its last sentence and in a
set there is no last one.
On 6/29/2025 3:42 AM, Mikko wrote:
On 2025-06-28 13:28:04 +0000, olcott said:
On 6/28/2025 6:47 AM, Mikko wrote:
On 2025-06-27 23:35:46 +0000, olcott said:
On 6/26/2025 4:30 AM, Mikko wrote:
On 2025-06-25 14:33:52 +0000, olcott said:
On 6/25/2025 1:50 AM, Mikko wrote:
On 2025-06-24 15:00:30 +0000, olcott said:
A proof is any set of expressions of language that
correctly concludes that another expression of
language is definitely true.
A singlet set of expressions that just states a correct conclusion >>>>>>>> satisfy the above definition but does not prove anything. A proof >>>>>>>> is something that gives a sufficient reson to believe what otherwise >>>>>>>> might not be believed.
Correct proofs can also depend on the meaning of natural
language words.
Yes, and avoid ambiguous expressions or disambiguate them when needed. >>>>>>
It is typical that formal proofs make sure
to totally ignore every aspect of this.
That is the main advantage of formal proofs. But an application
of a formal proof usually requires natural language to express
the interpretation.
An expression of language is proven true when a set of
semantic meanings makes it true.
Often it is sufficiently proven if it is observed to be true
though that of course depends on the qualyty of the obserfation
and of the quality of the report of the observation.
To really understand this requires deep understanding of
the philosophy of truth, rather than rote memorization
of some conventional steps.
Deep understanding is rarely useful. Often it is sufficient to
understand that what is presented as a proof isn't a proof.
Two elements that require very deep understanding are
(a) truth-makers and (b) truth-bearers.
Truthmaker Maximalism says that when there is nothing
that makes an expression of language true then this
expression is not true.
That is not a useful result as the non-existence is usually
unobservable and unverifiable.
Analytical truth has nothing to do with observation
and has everything to do we semantic connections
between expressions of language.
Your claims above were about truth in general with no restriction
to analytical truths. But if you don't know that a sentence has
no truth maker it may be hard to find out.
All of math, computer science and logic is analytic truth.
We don't observe that 5 > 3, it is defined that way.
And that includes the non-existence of halt deciders.
*This is only based on false assumptions*
(a) An *input* can be defined that does the opposite
of whatever its decider reports. // proven false
Not an assumption but proven true from definitions.
No one ever noticed that it is never an actual
*input* that does this.
On 6/30/2025 3:14 AM, Mikko wrote:
On 2025-06-29 14:04:43 +0000, olcott said:
On 6/29/2025 3:42 AM, Mikko wrote:
On 2025-06-28 13:28:04 +0000, olcott said:
On 6/28/2025 6:47 AM, Mikko wrote:
On 2025-06-27 23:35:46 +0000, olcott said:
On 6/26/2025 4:30 AM, Mikko wrote:
On 2025-06-25 14:33:52 +0000, olcott said:
On 6/25/2025 1:50 AM, Mikko wrote:
On 2025-06-24 15:00:30 +0000, olcott said:
A proof is any set of expressions of language that
correctly concludes that another expression of
language is definitely true.
A singlet set of expressions that just states a correct conclusion >>>>>>>>>> satisfy the above definition but does not prove anything. A proof >>>>>>>>>> is something that gives a sufficient reson to believe what otherwise >>>>>>>>>> might not be believed.
Correct proofs can also depend on the meaning of natural
language words.
Yes, and avoid ambiguous expressions or disambiguate them when needed. >>>>>>>>
It is typical that formal proofs make sure
to totally ignore every aspect of this.
That is the main advantage of formal proofs. But an application >>>>>>>> of a formal proof usually requires natural language to express >>>>>>>> the interpretation.
An expression of language is proven true when a set of
semantic meanings makes it true.
Often it is sufficiently proven if it is observed to be true
though that of course depends on the qualyty of the obserfation >>>>>>>> and of the quality of the report of the observation.
To really understand this requires deep understanding of
the philosophy of truth, rather than rote memorization
of some conventional steps.
Deep understanding is rarely useful. Often it is sufficient to >>>>>>>> understand that what is presented as a proof isn't a proof.
Two elements that require very deep understanding are
(a) truth-makers and (b) truth-bearers.
Truthmaker Maximalism says that when there is nothing
that makes an expression of language true then this
expression is not true.
That is not a useful result as the non-existence is usually
unobservable and unverifiable.
Analytical truth has nothing to do with observation
and has everything to do we semantic connections
between expressions of language.
Your claims above were about truth in general with no restriction
to analytical truths. But if you don't know that a sentence has
no truth maker it may be hard to find out.
All of math, computer science and logic is analytic truth.
We don't observe that 5 > 3, it is defined that way.
And that includes the non-existence of halt deciders.
*This is only based on false assumptions*
(a) An *input* can be defined that does the opposite
of whatever its decider reports. // proven false
Not an assumption but proven true from definitions.
No one ever noticed that it is never an actual
*input* that does this.
That "input" is an input to the halting problem. The input to the
decider candidate is a representation of input to the halting
problem. To "do the opposite" refers to what happens if the
"input" computation is executed. Whether it is actually executed
is irrelevant.
Yet no directly executed Turing Machine DDD() can be an input
to another Turing Machine HHH making this DDD() outside of the
domain of HHH thus its behavior is irrelevant to the correctness
of HHH(DDD).
On 7/1/2025 2:51 AM, Mikko wrote:
On 2025-06-30 17:49:20 +0000, olcott said:
On 6/30/2025 3:14 AM, Mikko wrote:
On 2025-06-29 14:04:43 +0000, olcott said:
On 6/29/2025 3:42 AM, Mikko wrote:
On 2025-06-28 13:28:04 +0000, olcott said:
On 6/28/2025 6:47 AM, Mikko wrote:
On 2025-06-27 23:35:46 +0000, olcott said:
On 6/26/2025 4:30 AM, Mikko wrote:
On 2025-06-25 14:33:52 +0000, olcott said:
On 6/25/2025 1:50 AM, Mikko wrote:
On 2025-06-24 15:00:30 +0000, olcott said:
A proof is any set of expressions of language that
correctly concludes that another expression of
language is definitely true.
A singlet set of expressions that just states a correct conclusion >>>>>>>>>>>> satisfy the above definition but does not prove anything. A proof >>>>>>>>>>>> is something that gives a sufficient reson to believe what otherwise
might not be believed.
Correct proofs can also depend on the meaning of natural >>>>>>>>>>> language words.
Yes, and avoid ambiguous expressions or disambiguate them when needed.
It is typical that formal proofs make sure
to totally ignore every aspect of this.
That is the main advantage of formal proofs. But an application >>>>>>>>>> of a formal proof usually requires natural language to express >>>>>>>>>> the interpretation.
An expression of language is proven true when a set of
semantic meanings makes it true.
Often it is sufficiently proven if it is observed to be true >>>>>>>>>> though that of course depends on the qualyty of the obserfation >>>>>>>>>> and of the quality of the report of the observation.
To really understand this requires deep understanding of >>>>>>>>>>> the philosophy of truth, rather than rote memorization
of some conventional steps.
Deep understanding is rarely useful. Often it is sufficient to >>>>>>>>>> understand that what is presented as a proof isn't a proof. >>>>>>>>>>
Two elements that require very deep understanding are
(a) truth-makers and (b) truth-bearers.
Truthmaker Maximalism says that when there is nothing
that makes an expression of language true then this
expression is not true.
That is not a useful result as the non-existence is usually >>>>>>>>>> unobservable and unverifiable.
Analytical truth has nothing to do with observation
and has everything to do we semantic connections
between expressions of language.
Your claims above were about truth in general with no restriction >>>>>>>> to analytical truths. But if you don't know that a sentence has >>>>>>>> no truth maker it may be hard to find out.
All of math, computer science and logic is analytic truth.
We don't observe that 5 > 3, it is defined that way.
And that includes the non-existence of halt deciders.
*This is only based on false assumptions*
(a) An *input* can be defined that does the opposite
of whatever its decider reports. // proven false
Not an assumption but proven true from definitions.
No one ever noticed that it is never an actual
*input* that does this.
That "input" is an input to the halting problem. The input to the
decider candidate is a representation of input to the halting
problem. To "do the opposite" refers to what happens if the
"input" computation is executed. Whether it is actually executed
is irrelevant.
Yet no directly executed Turing Machine DDD() can be an input
to another Turing Machine HHH making this DDD() outside of the
domain of HHH thus its behavior is irrelevant to the correctness
of HHH(DDD).
Irrelevant to the halting problem.
It is relevant to the halting problem because
no input to a halt decider can possibly do the
opposite of whatever its halt decider decides.
The thing that does the opposite is not an input.
On 7/2/2025 1:53 AM, Mikko wrote:
On 2025-07-01 11:46:11 +0000, olcott said:
On 7/1/2025 2:51 AM, Mikko wrote:
On 2025-06-30 17:49:20 +0000, olcott said:
On 6/30/2025 3:14 AM, Mikko wrote:
On 2025-06-29 14:04:43 +0000, olcott said:
On 6/29/2025 3:42 AM, Mikko wrote:
On 2025-06-28 13:28:04 +0000, olcott said:
On 6/28/2025 6:47 AM, Mikko wrote:
On 2025-06-27 23:35:46 +0000, olcott said:
On 6/26/2025 4:30 AM, Mikko wrote:
On 2025-06-25 14:33:52 +0000, olcott said:
On 6/25/2025 1:50 AM, Mikko wrote:
On 2025-06-24 15:00:30 +0000, olcott said:
A proof is any set of expressions of language that >>>>>>>>>>>>>>> correctly concludes that another expression of
language is definitely true.
A singlet set of expressions that just states a correct >>>>>>>>>>>>>> conclusion
satisfy the above definition but does not prove anything. >>>>>>>>>>>>>> A proof
is something that gives a sufficient reson to believe what >>>>>>>>>>>>>> otherwise
might not be believed.
Correct proofs can also depend on the meaning of natural >>>>>>>>>>>>> language words.
Yes, and avoid ambiguous expressions or disambiguate them >>>>>>>>>>>> when needed.
It is typical that formal proofs make sure
to totally ignore every aspect of this.
That is the main advantage of formal proofs. But an application >>>>>>>>>>>> of a formal proof usually requires natural language to express >>>>>>>>>>>> the interpretation.
An expression of language is proven true when a set of >>>>>>>>>>>>> semantic meanings makes it true.
Often it is sufficiently proven if it is observed to be true >>>>>>>>>>>> though that of course depends on the qualyty of the obserfation >>>>>>>>>>>> and of the quality of the report of the observation.
To really understand this requires deep understanding of >>>>>>>>>>>>> the philosophy of truth, rather than rote memorization >>>>>>>>>>>>> of some conventional steps.
Deep understanding is rarely useful. Often it is sufficient to >>>>>>>>>>>> understand that what is presented as a proof isn't a proof. >>>>>>>>>>>>
Two elements that require very deep understanding are >>>>>>>>>>>>> (a) truth-makers and (b) truth-bearers.
Truthmaker Maximalism says that when there is nothing >>>>>>>>>>>>> that makes an expression of language true then this
expression is not true.
That is not a useful result as the non-existence is usually >>>>>>>>>>>> unobservable and unverifiable.
Analytical truth has nothing to do with observation
and has everything to do we semantic connections
between expressions of language.
Your claims above were about truth in general with no restriction >>>>>>>>>> to analytical truths. But if you don't know that a sentence has >>>>>>>>>> no truth maker it may be hard to find out.
All of math, computer science and logic is analytic truth. >>>>>>>>>>> We don't observe that 5 > 3, it is defined that way.
And that includes the non-existence of halt deciders.
*This is only based on false assumptions*
(a) An *input* can be defined that does the opposite
of whatever its decider reports. // proven false
Not an assumption but proven true from definitions.
No one ever noticed that it is never an actual
*input* that does this.
That "input" is an input to the halting problem. The input to the
decider candidate is a representation of input to the halting
problem. To "do the opposite" refers to what happens if the
"input" computation is executed. Whether it is actually executed
is irrelevant.
Yet no directly executed Turing Machine DDD() can be an input
to another Turing Machine HHH making this DDD() outside of the
domain of HHH thus its behavior is irrelevant to the correctness
of HHH(DDD).
Irrelevant to the halting problem.
It is relevant to the halting problem because
no input to a halt decider can possibly do the
opposite of whatever its halt decider decides.
The thing that does the opposite is not an input.
It is irrelevant because the halting problem clarly states that the
input is a description of a Turing machine and an input to that
machine. You may say that to decide halting of a directly executed
Turing machnie is not possible from the given input but the problem
is what it is.
Although it is called a description that term is inaccurate.
It leads people to believe that 98% of exactly what it does
is close enough. That DD() *DOES NOT DO* what DD correctly
simulated by HHH does is a key detail *THAT ALWAYS ESCAPES THEM*
It is actually has 100% of all of the details that the
machine code of DD has. The input to HHH(DD) *SPECIFIES*
100% of every detail of the exactly behavior *OF THIS INPUT*
DDD simulated by HHH according to the actual semantics
of the C programming language GETS STUCK IN RECURSIVE
SIMULATION.
On 7/2/2025 1:53 AM, Mikko wrote:
On 2025-07-01 11:46:11 +0000, olcott said:
On 7/1/2025 2:51 AM, Mikko wrote:
On 2025-06-30 17:49:20 +0000, olcott said:
On 6/30/2025 3:14 AM, Mikko wrote:
On 2025-06-29 14:04:43 +0000, olcott said:
On 6/29/2025 3:42 AM, Mikko wrote:
On 2025-06-28 13:28:04 +0000, olcott said:
On 6/28/2025 6:47 AM, Mikko wrote:
On 2025-06-27 23:35:46 +0000, olcott said:
On 6/26/2025 4:30 AM, Mikko wrote:
On 2025-06-25 14:33:52 +0000, olcott said:
On 6/25/2025 1:50 AM, Mikko wrote:
On 2025-06-24 15:00:30 +0000, olcott said:
A proof is any set of expressions of language that >>>>>>>>>>>>>>> correctly concludes that another expression of
language is definitely true.
A singlet set of expressions that just states a correct conclusion
satisfy the above definition but does not prove anything. A proof
is something that gives a sufficient reson to believe what otherwise
might not be believed.
Correct proofs can also depend on the meaning of natural >>>>>>>>>>>>> language words.
Yes, and avoid ambiguous expressions or disambiguate them when needed.
It is typical that formal proofs make sure
to totally ignore every aspect of this.
That is the main advantage of formal proofs. But an application >>>>>>>>>>>> of a formal proof usually requires natural language to express >>>>>>>>>>>> the interpretation.
An expression of language is proven true when a set of >>>>>>>>>>>>> semantic meanings makes it true.
Often it is sufficiently proven if it is observed to be true >>>>>>>>>>>> though that of course depends on the qualyty of the obserfation >>>>>>>>>>>> and of the quality of the report of the observation.
To really understand this requires deep understanding of >>>>>>>>>>>>> the philosophy of truth, rather than rote memorization >>>>>>>>>>>>> of some conventional steps.
Deep understanding is rarely useful. Often it is sufficient to >>>>>>>>>>>> understand that what is presented as a proof isn't a proof. >>>>>>>>>>>>
Two elements that require very deep understanding are >>>>>>>>>>>>> (a) truth-makers and (b) truth-bearers.
Truthmaker Maximalism says that when there is nothing >>>>>>>>>>>>> that makes an expression of language true then this
expression is not true.
That is not a useful result as the non-existence is usually >>>>>>>>>>>> unobservable and unverifiable.
Analytical truth has nothing to do with observation
and has everything to do we semantic connections
between expressions of language.
Your claims above were about truth in general with no restriction >>>>>>>>>> to analytical truths. But if you don't know that a sentence has >>>>>>>>>> no truth maker it may be hard to find out.
All of math, computer science and logic is analytic truth. >>>>>>>>>>> We don't observe that 5 > 3, it is defined that way.
And that includes the non-existence of halt deciders.
*This is only based on false assumptions*
(a) An *input* can be defined that does the opposite
of whatever its decider reports. // proven false
Not an assumption but proven true from definitions.
No one ever noticed that it is never an actual
*input* that does this.
That "input" is an input to the halting problem. The input to the
decider candidate is a representation of input to the halting
problem. To "do the opposite" refers to what happens if the
"input" computation is executed. Whether it is actually executed
is irrelevant.
Yet no directly executed Turing Machine DDD() can be an input
to another Turing Machine HHH making this DDD() outside of the
domain of HHH thus its behavior is irrelevant to the correctness
of HHH(DDD).
Irrelevant to the halting problem.
It is relevant to the halting problem because
no input to a halt decider can possibly do the
opposite of whatever its halt decider decides.
The thing that does the opposite is not an input.
It is irrelevant because the halting problem clarly states that the
input is a description of a Turing machine and an input to that
machine. You may say that to decide halting of a directly executed
Turing machnie is not possible from the given input but the problem
is what it is.
Although it is called a description that term is inaccurate.
It leads people to believe that 98% of exactly what it does
is close enough. That DD() *DOES NOT DO* what DD correctly
simulated by HHH does is a key detail *THAT ALWAYS ESCAPES THEM*
It is actually has 100% of all of the details that the
machine code of DD has. The input to HHH(DD) *SPECIFIES*
100% of every detail of the exactly behavior *OF THIS INPUT*
DDD simulated by HHH according to the actual semantics
of the C programming language GETS STUCK IN RECURSIVE
SIMULATION.
On 7/2/2025 1:53 AM, Mikko wrote:You are effectively saying that all programs that start with a call
On 2025-07-01 11:46:11 +0000, olcott said:
On 7/1/2025 2:51 AM, Mikko wrote:
On 2025-06-30 17:49:20 +0000, olcott said:
On 6/30/2025 3:14 AM, Mikko wrote:
On 2025-06-29 14:04:43 +0000, olcott said:
On 6/29/2025 3:42 AM, Mikko wrote:
On 2025-06-28 13:28:04 +0000, olcott said:
On 6/28/2025 6:47 AM, Mikko wrote:
It is relevant to the halting problem because no input to a halt
decider can possibly do the opposite of whatever its halt decider
decides. The thing that does the opposite is not an input.
WTH? It is rather obvious that HHH cannot simulate DDD or anything elseIt is irrelevant because the halting problem clarly states that theAlthough it is called a description that term is inaccurate.
input is a description of a Turing machine and an input to that
machine. You may say that to decide halting of a directly executed
Turing machnie is not possible from the given input but the problem is
what it is.
It leads people to believe that 98% of exactly what it does is close
enough. That DD() *DOES NOT DO* what DD correctly simulated by HHH does
is a key detail *THAT ALWAYS ESCAPES THEM*
It is actually has 100% of all of the details that the machine code ofYeah, and you can also execute that code instead of simulating it.
DD has. The input to HHH(DD) *SPECIFIES*
100% of every detail of the exactly behavior *OF THIS INPUT*
On 7/4/2025 2:25 AM, Mikko wrote:Only because it is not simulated.
On 2025-07-03 22:11:45 +0000, olcott said:
On 7/2/2025 1:53 AM, Mikko wrote:
On 2025-07-01 11:46:11 +0000, olcott said:
It is relevant to the halting problem because no input to a halt
decider can possibly do the opposite of whatever its halt decider
decides.
Sounds like a bug.It is a detail that defines a partial halt decider that makes the "doAlthough it is called a description that term is inaccurate.What HHH correctly or otherwise simulates is merely an implementation
It leads people to believe that 98% of exactly what it does is close
enough. That DD() *DOES NOT DO* what DD correctly simulated by HHH
does is a key detail *THAT ALWAYS ESCAPES THEM*
detail.
the opposite" code unreachable.
No, what code does when executed. Nobody cares what any random simulatorWhat matters is the beahviour DD specifies.The behavior that an input specifies is only correctly measured by
correctly simulating this input.
Which HHH doesn't do.Partial halt deciders only compute the mapping from their inputs to the actual behavior that this input actually specifies.It is actually has 100% of all of the details that the machine code ofIn particular, it specifies whether the direct execution of DD halts or
DD has. The input to HHH(DD) *SPECIFIES*
100% of every detail of the exactly behavior *OF THIS INPUT*
not.
A halt decider cannot compute the mapping from its own caller or its own self. That is just not the way that computation fundamentally works.Nor does it need to, it gets the code of its caller and itself as input.
Oh goodie.Other aspects of the behaivour are not relevant
(but are specified anyway).
I have never been trying to solve the halting problem.DDD simulated by HHH according to the actual semantics of the CThat is why simulation alone does not solve the halting problem.
programming language GETS STUCK IN RECURSIVE SIMULATION.
That requires a computer program that is omniscient.Calculating the parity of a number also does.
All that I have done is refute the conventional halting problem proof technique. Once this is accepted as correct I will move on to the nextWhich one is that? And what is your goal if not refuting the halting
best proof after that.
On 7/4/2025 3:55 AM, joes wrote:
Am Thu, 03 Jul 2025 17:11:45 -0500 schrieb olcott:
On 7/2/2025 1:53 AM, Mikko wrote:
On 2025-07-01 11:46:11 +0000, olcott said:
You are effectively saying that all programs that start with a call toIt is relevant to the halting problem because no input to a halt
decider can possibly do the opposite of whatever its halt decider
decides. The thing that does the opposite is not an input.
HHH are the same.
WTH? It is rather obvious that HHH cannot simulate DDD or anything elseIt is irrelevant because the halting problem clarly states that theAlthough it is called a description that term is inaccurate.
input is a description of a Turing machine and an input to that
machine. You may say that to decide halting of a directly executed
Turing machnie is not possible from the given input but the problem
is what it is.
It leads people to believe that 98% of exactly what it does is close
enough. That DD() *DOES NOT DO* what DD correctly simulated by HHH
does is a key detail *THAT ALWAYS ESCAPES THEM*
that calls HHH the same way as that input when run "directly".
Of course not, its code is.Yes. So it is like this:It is actually has 100% of all of the details that the machine code ofYeah, and you can also execute that code instead of simulating it.
DD has. The input to HHH(DD) *SPECIFIES*
100% of every detail of the exactly behavior *OF THIS INPUT*
*The input to HHH(DD) specifies non-halting behavior*
The directly executed DD() is not an input.
Because it is not an input it HHH is not accountable for its behavior. Deciders are only accountable for computing the mapping from theirYes it is, HHH should compute whether the code of DD halts when run.
inputs.
On 7/4/2025 8:37 AM, joes wrote:Did I misunderstand you?
Am Fri, 04 Jul 2025 07:16:23 -0500 schrieb olcott:
On 7/4/2025 3:55 AM, joes wrote:
Am Thu, 03 Jul 2025 17:11:45 -0500 schrieb olcott:
On 7/2/2025 1:53 AM, Mikko wrote:
On 2025-07-01 11:46:11 +0000, olcott said:
You are effectively saying that all programs that start with a call
to HHH are the same.
Are you seriously suggesting that you can't compute what the code ofLikewise we should also compute the area of a square circle with aBecause it is not an input it HHH is not accountable for its behavior.Yes it is, HHH should compute whether the code of DD halts when run.
Deciders are only accountable for computing the mapping from their
inputs.
You can't be thinking that is uncomputable.
radius of 2.
Partial halt deciders have never been allowed to report on the behaviorAnd you think that DDD's direct execution is not specified by its
of any directly executed Turing machine. Instead of this they have used
the behavior that their input machine description specifies as a proxy.
Now for the first time we see that DDD correctly simulated by HHH *ISIndeed, HHH does not simulate it correctly. (You can't mean that DDD
NOT A PROXY* for the behavior of the directly executed DDD().
On 7/4/2025 1:23 PM, joes wrote:Lol, you could have responded immediately. You know how to look up posts.
Am Fri, 04 Jul 2025 12:30:43 -0500 schrieb olcott:
On 7/4/2025 8:37 AM, joes wrote:
Am Fri, 04 Jul 2025 07:16:23 -0500 schrieb olcott:
On 7/4/2025 3:55 AM, joes wrote:
The nesting is too deep to see what you are responding to.You are effectively saying that all programs that start with a call >>>>>> to HHH are the same.
Don't complain later.Are you seriously suggesting that you can't compute what the code ofYes it is, HHH should compute whether the code of DD halts when run.Likewise we should also compute the area of a square circle with a
You can't be thinking that is uncomputable.
radius of 2.
DDD does when executed?
No disagreement; not my question.I HAVE PROVEN THAT DDD CORRECTLY SIMULATED BY HHH DOES NOT HAVE THE SAME BEHAVIOR AS DDD() THOUSANDS OF TIMES IN THE LAST THREE YEARSPartial halt deciders have never been allowed to report on theAnd you think that DDD's direct execution is not specified by its
behavior of any directly executed Turing machine. Instead of this they
have used the behavior that their input machine description specifies
as a proxy.
description?
So DDD specifies at least two different behaviours?You are using the wrong measure of correct.Now for the first time we see that DDD correctly simulated by HHH *ISIndeed, HHH does not simulate it correctly. (You can't mean that DDD is
NOT A PROXY* for the behavior of the directly executed DDD().
*executed* incorrectly.)
On 7/4/2025 2:09 PM, joes wrote:
Am Fri, 04 Jul 2025 13:37:25 -0500 schrieb olcott:
On 7/4/2025 1:23 PM, joes wrote:Lol, you could have responded immediately. You know how to look up posts.
Am Fri, 04 Jul 2025 12:30:43 -0500 schrieb olcott:
On 7/4/2025 8:37 AM, joes wrote:
Am Fri, 04 Jul 2025 07:16:23 -0500 schrieb olcott:
On 7/4/2025 3:55 AM, joes wrote:
The nesting is too deep to see what you are responding to.You are effectively saying that all programs that start with a call >>>>>>>> to HHH are the same.
Don't complain later.Are you seriously suggesting that you can't compute what the code ofYes it is, HHH should compute whether the code of DD halts when run. >>>>>> You can't be thinking that is uncomputable.Likewise we should also compute the area of a square circle with a
radius of 2.
DDD does when executed?
No disagreement; not my question.I HAVE PROVEN THAT DDD CORRECTLY SIMULATED BY HHH DOES NOT HAVE THE SAME >>> BEHAVIOR AS DDD() THOUSANDS OF TIMES IN THE LAST THREE YEARSPartial halt deciders have never been allowed to report on theAnd you think that DDD's direct execution is not specified by its
behavior of any directly executed Turing machine. Instead of this they >>>>> have used the behavior that their input machine description specifies >>>>> as a proxy.
description?
So DDD specifies at least two different behaviours?You are using the wrong measure of correct.Now for the first time we see that DDD correctly simulated by HHH *IS >>>>> NOT A PROXY* for the behavior of the directly executed DDD().Indeed, HHH does not simulate it correctly. (You can't mean that DDD is >>>> *executed* incorrectly.)
*Yes. This sums it up quite well* (its only 1.5 pages long) https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
On 7/4/2025 3:45 PM, Richard Damon wrote:
On 7/4/25 3:15 PM, olcott wrote:
On 7/4/2025 2:09 PM, joes wrote:
Am Fri, 04 Jul 2025 13:37:25 -0500 schrieb olcott:
On 7/4/2025 1:23 PM, joes wrote:Lol, you could have responded immediately. You know how to look up
Am Fri, 04 Jul 2025 12:30:43 -0500 schrieb olcott:
On 7/4/2025 8:37 AM, joes wrote:
Am Fri, 04 Jul 2025 07:16:23 -0500 schrieb olcott:
On 7/4/2025 3:55 AM, joes wrote:
The nesting is too deep to see what you are responding to.You are effectively saying that all programs that start with a >>>>>>>>>> call
to HHH are the same.
posts.
Don't complain later.Are you seriously suggesting that you can't compute what the code of >>>>>> DDD does when executed?Yes it is, HHH should compute whether the code of DD halts when >>>>>>>> run.Likewise we should also compute the area of a square circle with a >>>>>>> radius of 2.
You can't be thinking that is uncomputable.
No disagreement; not my question.I HAVE PROVEN THAT DDD CORRECTLY SIMULATED BY HHH DOES NOT HAVE THEPartial halt deciders have never been allowed to report on theAnd you think that DDD's direct execution is not specified by its
behavior of any directly executed Turing machine. Instead of this >>>>>>> they
have used the behavior that their input machine description
specifies
as a proxy.
description?
SAME
BEHAVIOR AS DDD() THOUSANDS OF TIMES IN THE LAST THREE YEARS
So DDD specifies at least two different behaviours?You are using the wrong measure of correct.Now for the first time we see that DDD correctly simulated by HHH >>>>>>> *ISIndeed, HHH does not simulate it correctly. (You can't mean that
NOT A PROXY* for the behavior of the directly executed DDD().
DDD is
*executed* incorrectly.)
*Yes. This sums it up quite well* (its only 1.5 pages long)
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
Then your system LIES and is based on lies.
"Code" is deterministic, and thus every instruction when starting from
the same state will always do the same thing.
That you are not bright enough to detect the recursive
simulation non terminating behavior pattern is no rebuttal
at all.
On 7/4/2025 2:25 AM, Mikko wrote:
On 2025-07-03 22:11:45 +0000, olcott said:
On 7/2/2025 1:53 AM, Mikko wrote:
On 2025-07-01 11:46:11 +0000, olcott said:
On 7/1/2025 2:51 AM, Mikko wrote:
On 2025-06-30 17:49:20 +0000, olcott said:
On 6/30/2025 3:14 AM, Mikko wrote:
On 2025-06-29 14:04:43 +0000, olcott said:
On 6/29/2025 3:42 AM, Mikko wrote:
On 2025-06-28 13:28:04 +0000, olcott said:
On 6/28/2025 6:47 AM, Mikko wrote:
On 2025-06-27 23:35:46 +0000, olcott said:
On 6/26/2025 4:30 AM, Mikko wrote:
On 2025-06-25 14:33:52 +0000, olcott said:
On 6/25/2025 1:50 AM, Mikko wrote:
On 2025-06-24 15:00:30 +0000, olcott said:
A proof is any set of expressions of language that >>>>>>>>>>>>>>>>> correctly concludes that another expression of >>>>>>>>>>>>>>>>> language is definitely true.
A singlet set of expressions that just states a correct conclusion
satisfy the above definition but does not prove anything. A proof
is something that gives a sufficient reson to believe what otherwise
might not be believed.
Correct proofs can also depend on the meaning of natural >>>>>>>>>>>>>>> language words.
Yes, and avoid ambiguous expressions or disambiguate them when needed.
It is typical that formal proofs make sure
to totally ignore every aspect of this.
That is the main advantage of formal proofs. But an application >>>>>>>>>>>>>> of a formal proof usually requires natural language to express >>>>>>>>>>>>>> the interpretation.
An expression of language is proven true when a set of >>>>>>>>>>>>>>> semantic meanings makes it true.
Often it is sufficiently proven if it is observed to be true >>>>>>>>>>>>>> though that of course depends on the qualyty of the obserfation >>>>>>>>>>>>>> and of the quality of the report of the observation. >>>>>>>>>>>>>>
To really understand this requires deep understanding of >>>>>>>>>>>>>>> the philosophy of truth, rather than rote memorization >>>>>>>>>>>>>>> of some conventional steps.
Deep understanding is rarely useful. Often it is sufficient to >>>>>>>>>>>>>> understand that what is presented as a proof isn't a proof. >>>>>>>>>>>>>>
Two elements that require very deep understanding are >>>>>>>>>>>>>>> (a) truth-makers and (b) truth-bearers.
Truthmaker Maximalism says that when there is nothing >>>>>>>>>>>>>>> that makes an expression of language true then this >>>>>>>>>>>>>>> expression is not true.
That is not a useful result as the non-existence is usually >>>>>>>>>>>>>> unobservable and unverifiable.
Analytical truth has nothing to do with observation
and has everything to do we semantic connections
between expressions of language.
Your claims above were about truth in general with no restriction >>>>>>>>>>>> to analytical truths. But if you don't know that a sentence has >>>>>>>>>>>> no truth maker it may be hard to find out.
All of math, computer science and logic is analytic truth. >>>>>>>>>>>>> We don't observe that 5 > 3, it is defined that way.
And that includes the non-existence of halt deciders.
*This is only based on false assumptions*
(a) An *input* can be defined that does the opposite
of whatever its decider reports. // proven false
Not an assumption but proven true from definitions.
No one ever noticed that it is never an actual
*input* that does this.
That "input" is an input to the halting problem. The input to the >>>>>>>> decider candidate is a representation of input to the halting
problem. To "do the opposite" refers to what happens if the
"input" computation is executed. Whether it is actually executed >>>>>>>> is irrelevant.
Yet no directly executed Turing Machine DDD() can be an input
to another Turing Machine HHH making this DDD() outside of the
domain of HHH thus its behavior is irrelevant to the correctness >>>>>>> of HHH(DDD).
Irrelevant to the halting problem.
It is relevant to the halting problem because
no input to a halt decider can possibly do the
opposite of whatever its halt decider decides.
The thing that does the opposite is not an input.
It is irrelevant because the halting problem clarly states that the
input is a description of a Turing machine and an input to that
machine. You may say that to decide halting of a directly executed
Turing machnie is not possible from the given input but the problem
is what it is.
Although it is called a description that term is inaccurate.
It leads people to believe that 98% of exactly what it does
is close enough. That DD() *DOES NOT DO* what DD correctly
simulated by HHH does is a key detail *THAT ALWAYS ESCAPES THEM*
What HHH correctly or otherwise simulates is merely an implementation
detail.
It is a detail that defines a partial halt decider
that makes the "do the opposite" code unreachable.
What matters is the beahviour DD specifies.
The behavior that an input specifies is only correctly
measured by correctly simulating this input.
The user's
manual must specify how DD (or any other algorithm) shall be described
for HHH.
The C programming language translated into x86 machine code.
On 7/4/2025 8:33 AM, joes wrote:
Am Fri, 04 Jul 2025 07:34:39 -0500 schrieb olcott:
All that I have done is refute the conventional halting problem proof
technique.
Once this is accepted as correct I will move on to the next bestWhich one is that? And what is your goal if not refuting the halting
proof after that.
theorem?
To conquer each proof of the HP one at a time.
The reason that I am doing this is that people have a fundamentally
incorrect understanding about how truth itself actually works.
Because of these misconceptions there has been no objective way to
divide truth from well crafted lies.
This is causing the rise of the fourth Reich and
the destruction of the planet through climate change.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 7/4/2025 3:45 PM, Richard Damon wrote:
On 7/4/25 3:15 PM, olcott wrote:
On 7/4/2025 2:09 PM, joes wrote:
Am Fri, 04 Jul 2025 13:37:25 -0500 schrieb olcott:
On 7/4/2025 1:23 PM, joes wrote:Lol, you could have responded immediately. You know how to look up
Am Fri, 04 Jul 2025 12:30:43 -0500 schrieb olcott:
On 7/4/2025 8:37 AM, joes wrote:
Am Fri, 04 Jul 2025 07:16:23 -0500 schrieb olcott:
On 7/4/2025 3:55 AM, joes wrote:
The nesting is too deep to see what you are responding to.You are effectively saying that all programs that start with a >>>>>>>>>> call
to HHH are the same.
posts.
Don't complain later.Are you seriously suggesting that you can't compute what the code of >>>>>> DDD does when executed?Yes it is, HHH should compute whether the code of DD halts when >>>>>>>> run.Likewise we should also compute the area of a square circle with a >>>>>>> radius of 2.
You can't be thinking that is uncomputable.
No disagreement; not my question.I HAVE PROVEN THAT DDD CORRECTLY SIMULATED BY HHH DOES NOT HAVE THEPartial halt deciders have never been allowed to report on theAnd you think that DDD's direct execution is not specified by its
behavior of any directly executed Turing machine. Instead of this >>>>>>> they
have used the behavior that their input machine description
specifies
as a proxy.
description?
SAME
BEHAVIOR AS DDD() THOUSANDS OF TIMES IN THE LAST THREE YEARS
So DDD specifies at least two different behaviours?You are using the wrong measure of correct.Now for the first time we see that DDD correctly simulated by HHH >>>>>>> *ISIndeed, HHH does not simulate it correctly. (You can't mean that
NOT A PROXY* for the behavior of the directly executed DDD().
DDD is
*executed* incorrectly.)
*Yes. This sums it up quite well* (its only 1.5 pages long)
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
Then your system LIES and is based on lies.
"Code" is deterministic, and thus every instruction when starting from
the same state will always do the same thing.
That you are not bright enough to detect the recursive
simulation non terminating behavior pattern is no rebuttal
at all.
On 7/5/2025 8:11 AM, Richard Damon wrote:
On 7/4/25 6:26 PM, olcott wrote:
On 7/4/2025 3:45 PM, Richard Damon wrote:
On 7/4/25 3:15 PM, olcott wrote:
On 7/4/2025 2:09 PM, joes wrote:
Am Fri, 04 Jul 2025 13:37:25 -0500 schrieb olcott:
On 7/4/2025 1:23 PM, joes wrote:Lol, you could have responded immediately. You know how to look up >>>>>> posts.
Am Fri, 04 Jul 2025 12:30:43 -0500 schrieb olcott:
On 7/4/2025 8:37 AM, joes wrote:
Am Fri, 04 Jul 2025 07:16:23 -0500 schrieb olcott:
On 7/4/2025 3:55 AM, joes wrote:
The nesting is too deep to see what you are responding to.You are effectively saying that all programs that start with >>>>>>>>>>>> a call
to HHH are the same.
Don't complain later.Are you seriously suggesting that you can't compute what theYes it is, HHH should compute whether the code of DD halts >>>>>>>>>> when run.Likewise we should also compute the area of a square circle with a >>>>>>>>> radius of 2.
You can't be thinking that is uncomputable.
code of
DDD does when executed?
No disagreement; not my question.I HAVE PROVEN THAT DDD CORRECTLY SIMULATED BY HHH DOES NOT HAVEPartial halt deciders have never been allowed to report on the >>>>>>>>> behavior of any directly executed Turing machine. Instead of >>>>>>>>> this theyAnd you think that DDD's direct execution is not specified by its >>>>>>>> description?
have used the behavior that their input machine description
specifies
as a proxy.
THE SAME
BEHAVIOR AS DDD() THOUSANDS OF TIMES IN THE LAST THREE YEARS
So DDD specifies at least two different behaviours?You are using the wrong measure of correct.Now for the first time we see that DDD correctly simulated by >>>>>>>>> HHH *IS*executed* incorrectly.)
NOT A PROXY* for the behavior of the directly executed DDD(). >>>>>>>> Indeed, HHH does not simulate it correctly. (You can't mean that >>>>>>>> DDD is
*Yes. This sums it up quite well* (its only 1.5 pages long)
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
Then your system LIES and is based on lies.
"Code" is deterministic, and thus every instruction when starting
from the same state will always do the same thing.
That you are not bright enough to detect the recursive
simulation non terminating behavior pattern is no rebuttal
at all.
So, how does a finite recursion, finite because every simulator in the
loop aborts its simulation at a given point, become non-halting.
I told you this at least dozens of times, go look up
what I already said.
On 7/5/2025 3:32 AM, Mikko wrote:
On 2025-07-04 12:34:39 +0000, olcott said:
On 7/4/2025 2:25 AM, Mikko wrote:
What HHH correctly or otherwise simulates is merely an implementation
detail.
It is a detail that defines a partial halt decider
that makes the "do the opposite" code unreachable.
No, it does. The proof that a counter-example can be constructed
does not refer to any implementation details, so it applies to
every implementation that is does not violate the requirements
so obviously that the proof is not needed.
What matters is the beahviour DD specifies.
The behavior that an input specifies is only correctly
measured by correctly simulating this input.
Wrong. It is correctly measured by a direct execution.
Since no Turing machine can possibly take another directly
executing Turing machine as an input this makes all directly
executed Turing machines outside of the domain of every Turing
machine based decider.
The requirement that a halt decider report on the behavior
of things outside of its domain has always been bogus.
Instead of this deciders must report on the behavior that
their input actually specifies.
On 7/5/2025 2:26 AM, Fred. Zwarts wrote:
Op 05.jul.2025 om 00:26 schreef olcott:
On 7/4/2025 3:45 PM, Richard Damon wrote:
On 7/4/25 3:15 PM, olcott wrote:
On 7/4/2025 2:09 PM, joes wrote:
Am Fri, 04 Jul 2025 13:37:25 -0500 schrieb olcott:
On 7/4/2025 1:23 PM, joes wrote:Lol, you could have responded immediately. You know how to look up >>>>>> posts.
Am Fri, 04 Jul 2025 12:30:43 -0500 schrieb olcott:
On 7/4/2025 8:37 AM, joes wrote:
Am Fri, 04 Jul 2025 07:16:23 -0500 schrieb olcott:
On 7/4/2025 3:55 AM, joes wrote:
The nesting is too deep to see what you are responding to.You are effectively saying that all programs that start with >>>>>>>>>>>> a call
to HHH are the same.
Don't complain later.Are you seriously suggesting that you can't compute what theYes it is, HHH should compute whether the code of DD halts >>>>>>>>>> when run.Likewise we should also compute the area of a square circle with a >>>>>>>>> radius of 2.
You can't be thinking that is uncomputable.
code of
DDD does when executed?
No disagreement; not my question.I HAVE PROVEN THAT DDD CORRECTLY SIMULATED BY HHH DOES NOT HAVEPartial halt deciders have never been allowed to report on the >>>>>>>>> behavior of any directly executed Turing machine. Instead of >>>>>>>>> this theyAnd you think that DDD's direct execution is not specified by its >>>>>>>> description?
have used the behavior that their input machine description
specifies
as a proxy.
THE SAME
BEHAVIOR AS DDD() THOUSANDS OF TIMES IN THE LAST THREE YEARS
So DDD specifies at least two different behaviours?You are using the wrong measure of correct.Now for the first time we see that DDD correctly simulated by >>>>>>>>> HHH *IS*executed* incorrectly.)
NOT A PROXY* for the behavior of the directly executed DDD(). >>>>>>>> Indeed, HHH does not simulate it correctly. (You can't mean that >>>>>>>> DDD is
*Yes. This sums it up quite well* (its only 1.5 pages long)
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
Then your system LIES and is based on lies.
"Code" is deterministic, and thus every instruction when starting
from the same state will always do the same thing.
That you are not bright enough to detect the recursive
simulation non terminating behavior pattern is no rebuttal
at all.
There is only *finite* recursive simulation, so everybody bright
enough understands that there is no non-terminating behaviour.
*It has never been whether it is finite or infinite*
It has always been: Would DDD simulated by HHH reach
its simulated final halt state in an infinite simulation?
Not understanding the difference between *finite* recursion and
*infinite* recursion shows who is not bright enough.
No it shows that you are not bothering to pay close attention
or like Richard cannot remember anything that I ever said in
prior posts.
On 7/5/2025 2:07 PM, Alan Mackenzie wrote:Why repeating this failure of HHH to reach the final halt state?
You lie. You don't have a proof. Many people in this group have pointed >> out lots of errors in various versions of your purported proof, which you
void DDD()
{
HHH(DDD);
return;
}
*They disagree with this truism* (that seems dishonest)
DDD simulated by HHH according to the semantics of the
C programming language cannot possibly reach its own
simulated "return" instruction final halt state.
just ignore. The section in Professor Linz's book you used to be so fond >> of citing will contain plenty of details, if only you would take the
trouble to understand it (assuming you're capable of such understanding).
I have addressed all of those details that you make sure
to ignore so that you can baselessly claim that I am wrong.
There cannot possibly be *AN ACTUAL INPUT* that does the
opposite of whatever its decider decides. All of the examples
of this have never been *ACTUAL INPUTS*
No Turing machine can possibly take another directly executing
Turing machine as in input, thus removing these from the
domain of every halt decider.
*Thus the requirement that HHH report on the behavior*
*of the directly executed DD has always been bogus*
Turing machine partial halt deciders compute the mapping
from their actual inputs to the actual behavior that these
inputs specify.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
DD simulated by HHH according to the semantics of the C
programming language cannot possibly halt when halting
is defined as reaching its own simulated "return"
statement final halt state.
On 7/5/2025 2:07 PM, Alan Mackenzie wrote:
You lie. You don't have a proof. Many people in this group have pointed
out lots of errors in various versions of your purported proof, which you
just ignore. The section in Professor Linz's book you used to be so fond
of citing will contain plenty of details, if only you would take the
trouble to understand it (assuming you're capable of such understanding).
I have addressed ....
.... all of those details that you make sure to ignore so that you can baselessly claim that I am wrong.
There cannot possibly be *AN ACTUAL INPUT* that does the
opposite of whatever its decider decides. All of the examples
of this have never been *ACTUAL INPUTS*
No Turing machine can possibly take another directly executing
Turing machine as in input, thus removing these from the
domain of every halt decider.
*Thus the requirement that HHH report on the behavior*
*of the directly executed DD has always been bogus*
Turing machine partial halt deciders compute the mapping
from their actual inputs to the actual behavior that these
inputs specify.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/6/2025 5:16 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/5/2025 2:07 PM, Alan Mackenzie wrote:
That's what I'm saying. Those proofs of the halting theorem are free
from mistakes.
More to the point, it is YOU who cannot point to any mistakes in them.
They are valid proofs. Your work, if it contradicts those proofs (which
isn't at all clear) can thus be dismissed without further consideration.
The is the ad ignorantiam error. https://en.wikipedia.org/wiki/Argument_from_ignorance
Atheists have made that their doctrine.
Turing machine partial halt deciders compute the mapping
from their actual inputs to the actual behavior that these
inputs specify.
And a fourth. There's some semblance of truth in there, but it's very >>>> confused.
It is not at all confused. I know exactly what it means.
It's very confused to everybody but you, then.
Sloppy wording is your technique to get people to go down to your level >>>> of discussion. That involves many posts trying just to tie you down to >>>> specific word meanings, and is very tiresome and unrewarding. I decline >>>> to get involved any further.
*Yet as I claimed you found no actual mistake*
I've found plenty of actual mistakes. I was a software developer by
profession.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
Let me tell you the punchline so that you can
see why I said those things.
Despite what I said last post, I will actually go to the trouble of
analysing your sloppy expression.
Because directly executed Turing machines cannot
possibly be inputs to Turing machine deciders this
makes them outside of the domain of these deciders.
It's entirely unclear what a "directly executed Turing machine" is. Most
of the time turing machines are theoretical constructs used for proving
theorems. They can be executed, but rarely are.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD); // DDD finite string of x86 code emulated by HHH
DDD(); // DDD directly executed
}
It's unclear what you mean by a turing machine being an input to a turing
machine. Read up about universal turing machines to get a bit of
background.
The directly executed DDD() is not an input to HHH.
We have the exact same thing in the Linz proof.
When Ĥ is applied to ⟨Ĥ⟩ // adapted from bottom of page 319
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt
Ĥ applied to ⟨Ĥ⟩ is the directly executed Ĥ ⟨Ĥ⟩
not ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
When a partial halt decider is required to report
on the direct execution of a machine this requirement
is bogus.
See above. That paragraph is meaningless.
That you do not understand a paragraph does not entail
that it is meaningless.
This means that the behavior of DD() is none of the damn
business of HHH, thus does not contradict HHH(DD)==0.
*If you disagree this only proves that you do not understand*
It's fully obscure what DD() and HHH mean, and thus impossible to
affirm or contradict the meaningless "HHH(DD)==0".
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code).
HHH(DD) does correctly detect that DD simulated by HHH
according to the semantics pf the C programming language
cannot possibly reach its own "return"statement final
halt state.
See above. By the way, people concerned with computation theory use
turing machines, which are well-defined, simple, and powerful. They lack
the complexity, ambiguity, and unsuitability for theoretical work of real
world programming languages like C.
Yet they have vagueness that C does not have.
C is a fully operational high level programming language.
TM's are at such a low level that it could take hundreds
of instructions to just move a single value in memory.
Any mindless idiot can disagree. Showing an error and proving
that it is an actual mistake requires much more than this.
Indeed. All you have done is disagree with one of the proofs of the
halting theorem. You have yet to show an error in it. That will be
difficult, because there aren't any.
There are two errors:
(1) The false assumption that TM's report on the behavior
of the directly executed machine "if Ĥ applied to ⟨Ĥ⟩ halts"
(see above).
(2) That simulating partial halt decider Ĥ.embedded_H is
incorrect to transition to Ĥ.qn on input ⟨Ĥ⟩ ⟨Ĥ⟩.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/6/2025 5:16 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/5/2025 2:07 PM, Alan Mackenzie wrote:
They are valid proofs. Your work, if it contradicts those proofs (which >>>> isn't at all clear) can thus be dismissed without further consideration.
The is the ad ignorantiam error.
https://en.wikipedia.org/wiki/Argument_from_ignorance
Atheists have made that their doctrine.
Garbage! I say again, if your proposition contradicts a known truth,
then it is necessarily false, and can be discarded.
There is a subtle difference between your original
statement and this one. Known truths are not exactly
the same thing as the result of a proof unless the
proof is inherently infallible.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.
Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
But analysing it a bit further, it is not clear exactly what
you mean by "simulated by HHH".
Do you have any idea what "simulation" means?
It's quite clear that DD will reach its
return statement if HHH(DD) returns 0.
So you can't see the recursive emulation non-halting
behavior pattern? DO you know what recursion is?
The directly executed DDD() is not an input to HHH.
Vague word salad again.
We have the exact same thing in the Linz proof.
You do not. There is no concept of "directly executed" in turing
machines, and Linz's proof concerns turing machines. Other people here
have said that one of the reasons you present your propositions as C, and
even some x86 assembly language, is to avoid the precision afforded by
turing machines. I'd tend to agree with them, here.
Ĥ is applied to ⟨Ĥ⟩ is the directly executed Ĥ.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not the directly
executed Ĥ.
DD simulated by HHH is a non-halting pattern that HHH does recognize.
See above. By the way, people concerned with computation theory use
turing machines, which are well-defined, simple, and powerful. They lack >>>> the complexity, ambiguity, and unsuitability for theoretical work of real >>>> world programming languages like C.
Yet they have vagueness that C does not have.
They do not. That assertion is down to your general lack of
understanding of abstract things.
I make abstract things 100% concrete so that vagueness
and ambiguity cannot possibly exist.
C is a fully operational high level programming language.
Yes. Which makes it unsuitable for proving things in computation theory.
Not at all. Many things can be proven in computation theory in C.
Hardly any real world algorithm requires unlimited memory. Every
single detail of all of human general knowledge is a finite set.
TM's are at such a low level that it could take hundreds
of instructions to just move a single value in memory.
That assertion is down to your general lack of understanding of abstract
things. Although true, it is utterly irrelevant to the normal use of
turing machines.
It seems dumb to stick with the ambiguity and vagueness
of abstractions when they can be translated into 100%
concrete specifications.
There are two errors:
(1) The false assumption that TM's report on the behavior
of the directly executed machine "if Ĥ applied to ⟨Ĥ⟩ halts"
(see above).
That assumption does not appear in the pertinent proofs. Indeed, those
proofs concern turing machines, which have no concept of "directly
executed", as explained above.
I already proved otherwise and you ignored the proof.
Ĥ applied to ⟨Ĥ⟩ is direct execution.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H *is not direct execution* of ⟨Ĥ⟩ ⟨Ĥ⟩
(2) That simulating partial halt decider Ĥ.embedded_H is
incorrect to transition to Ĥ.qn on input ⟨Ĥ⟩ ⟨Ĥ⟩.
The proofs concern purported halt deciders, not partial halt deciders.
The actual proofs themselves only actually deal with
one specific input. They purport to show one undecidable
example.
As I said, these proofs are correct.
That you believe that they are correct is not the
same thing as them actually being correct.
If humans are inherently infallible then we could
know that the proofs are correct.
I found mistakes and you could not understand
what I said or show that I am wrong.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:It is incomplete, because it has a call instruction, but does not
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as to be
near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a description
of what you mean by "simulation".
I specifically mean that this x86 machine code
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 ; push DD
[0000216b] e862f4ffff call 000015d2 ; call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Is emulated by an x86 emulator named HHH.
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny pieces
out of it and dealing with those. The proof you claim to refute has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.
It doesn't. See above.
It need not be a Turing machine to exactly match
the same pattern.
Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
It is a waste of time to discuss things at such an unnecessarily low
level of abstraction.
It is just like you are saying that all huge things
are always very tiny. The high level of abstraction
of C is not any low level of abstraction.
But analysing it a bit further, it is not clear exactly what
you mean by "simulated by HHH".
Do you have any idea what "simulation" means?
Yes. I'm not sure you do,
This should be something you learn in the first year of CS.
It is like an auto mechanic asking me: What is a spark plug?
The first thing that every programmer learns is that an
C language interpreter is not the same thing as a compiler.
though, which is why I was prompting you to be
more concrete. When Alan Turing published his seminal paper, he took a
very great deal of space specifying exactly what he meant by a "machine".
[ .... ]
It's quite clear that DD will reach its
return statement if HHH(DD) returns 0.
So you can't see the recursive emulation non-halting
behavior pattern? DO you know what recursion is?
Whether endless recursion happens depends on whether HHH(DD) returns 0.
Not at all. Anyone should instantly see that no HHH
can possibly ever return to any simulated DD.
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Others have pointed out problems with your reasoning here over a long
period of time. I don't want to repeat that.
No one has ever pointed out any actual error
in this reasoning. Others have kept acting
like they have no idea what recursion is.
[ .... ]
The directly executed DDD() is not an input to HHH.
Vague word salad again.
We have the exact same thing in the Linz proof.
You do not. There is no concept of "directly executed" in turing
machines, and Linz's proof concerns turing machines. Other people here >>>> have said that one of the reasons you present your propositions as
C, and
even some x86 assembly language, is to avoid the precision afforded by >>>> turing machines. I'd tend to agree with them, here.
Ĥ is applied to ⟨Ĥ⟩ is the directly executed Ĥ.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not the directly
executed Ĥ.
OK, that's a start, but it doesn't apply to turing machines.
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
[ .... ]
DD simulated by HHH is a non-halting pattern that HHH does recognize.
That is disputed by everybody else on this newsgroup.
*Yet they cannot ever point out even a single actual mistake*
I make abstract things 100% concrete so that vagueness
and ambiguity cannot possibly exist.
Your postings are stuffed full of vagueness and ambiguity.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The above x86 machine code emulated by HHH according
to the semantics of the x86 language has zero vagueness
and zero ambiguity.
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as to be near >>>> valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a description
of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny pieces
out of it and dealing with those. The proof you claim to refute has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
It is a waste of time to discuss things at such an unnecessarily low
level of abstraction.
It is just like you are saying that all huge things
are always very tiny. The high level of abstraction
of C is not any low level of abstraction.
But analysing it a bit further, it is not clear exactly what
you mean by "simulated by HHH".
Do you have any idea what "simulation" means?
Yes. I'm not sure you do,
This should be something you learn in the first year of CS.
It is like an auto mechanic asking me: What is a spark plug?
The first thing that every programmer learns is that an
C language interpreter is not the same thing as a compiler.
though, which is why I was prompting you to be
more concrete. When Alan Turing published his seminal paper, he took a
very great deal of space specifying exactly what he meant by a "machine".
Whether endless recursion happens depends on whether HHH(DD) returns 0.
Not at all.
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Others have pointed out problems with your reasoning here over a long
period of time. I don't want to repeat that.
No one has ever pointed out any actual error
in this reasoning. Others have kept acting
like they have no idea what recursion is.
The above x86 machine code emulated by HHH according
to the semantics of the x86 language has zero vagueness
and zero ambiguity.
The above code roughly maps to the (TM equivalent)
RASP machine architecture.
Until you understand that DD emulated by HHH
according to the semantics of the x86 language
cannot possibly reach its own final halt state
your understanding will remain woefully deficient.
No sense going over any other points until after
you get this point.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 7/7/2025 2:49 AM, Fred. Zwarts wrote:
It is incomplete, because it has a call instruction, but does notYou are a damned liar.
specify how this call instruction could be simulated,
On 7/7/2025 2:49 AM, Fred. Zwarts wrote:
You are a damned liar.
Op 07.jul.2025 om 05:07 schreef olcott:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:It is incomplete, because it has a call instruction, but does not
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as to
be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a
description
of what you mean by "simulation".
I specifically mean that this x86 machine code
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 ; push DD
[0000216b] e862f4ffff call 000015d2 ; call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Is emulated by an x86 emulator named HHH.
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny
pieces
out of it and dealing with those. The proof you claim to refute has no >>>> notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.
It doesn't. See above.
It need not be a Turing machine to exactly match
the same pattern.
Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
It is a waste of time to discuss things at such an unnecessarily low
level of abstraction.
It is just like you are saying that all huge things
are always very tiny. The high level of abstraction
of C is not any low level of abstraction.
But analysing it a bit further, it is not clear exactly what
you mean by "simulated by HHH".
Do you have any idea what "simulation" means?
Yes. I'm not sure you do,
This should be something you learn in the first year of CS.
It is like an auto mechanic asking me: What is a spark plug?
The first thing that every programmer learns is that an
C language interpreter is not the same thing as a compiler.
though, which is why I was prompting you to beNot at all. Anyone should instantly see that no HHH
more concrete. When Alan Turing published his seminal paper, he took a >>>> very great deal of space specifying exactly what he meant by a
"machine".
[ .... ]
It's quite clear that DD will reach its
return statement if HHH(DD) returns 0.
So you can't see the recursive emulation non-halting
behavior pattern? DO you know what recursion is?
Whether endless recursion happens depends on whether HHH(DD) returns 0. >>>
can possibly ever return to any simulated DD.
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Others have pointed out problems with your reasoning here over a long
period of time. I don't want to repeat that.
No one has ever pointed out any actual error
in this reasoning. Others have kept acting
like they have no idea what recursion is.
[ .... ]
The directly executed DDD() is not an input to HHH.
Vague word salad again.
We have the exact same thing in the Linz proof.
You do not. There is no concept of "directly executed" in turing >>>>>> machines, and Linz's proof concerns turing machines. Other people >>>>>> here
have said that one of the reasons you present your propositions as >>>>>> C, and
even some x86 assembly language, is to avoid the precision
afforded by
turing machines. I'd tend to agree with them, here.
Ĥ is applied to ⟨Ĥ⟩ is the directly executed Ĥ.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not the directly
executed Ĥ.
OK, that's a start, but it doesn't apply to turing machines.
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
[ .... ]
DD simulated by HHH is a non-halting pattern that HHH does recognize. >>>>That is disputed by everybody else on this newsgroup.
*Yet they cannot ever point out even a single actual mistake*
I make abstract things 100% concrete so that vagueness
and ambiguity cannot possibly exist.
Your postings are stuffed full of vagueness and ambiguity.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The above x86 machine code emulated by HHH according
to the semantics of the x86 language has zero vagueness
and zero ambiguity.
specify how this call instruction could be simulated,
On 7/8/2025 3:22 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 20:40 schreef olcott:
On 7/7/2025 2:49 AM, Fred. Zwarts wrote:
You are a damned liar.
Op 07.jul.2025 om 05:07 schreef olcott:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:It is incomplete, because it has a call instruction, but does not
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a description
of what you mean by "simulation".
I specifically mean that this x86 machine code
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 ; push DD
[0000216b] e862f4ffff call 000015d2 ; call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Is emulated by an x86 emulator named HHH.
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny pieces
out of it and dealing with those. The proof you claim to refute has no >>>>>> notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.
It doesn't. See above.
It need not be a Turing machine to exactly match
the same pattern.
Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
It is a waste of time to discuss things at such an unnecessarily low >>>>>> level of abstraction.
It is just like you are saying that all huge things
are always very tiny. The high level of abstraction
of C is not any low level of abstraction.
But analysing it a bit further, it is not clear exactly what >>>>>>>> you mean by "simulated by HHH".
Do you have any idea what "simulation" means?
Yes. I'm not sure you do,
This should be something you learn in the first year of CS.
It is like an auto mechanic asking me: What is a spark plug?
The first thing that every programmer learns is that an
C language interpreter is not the same thing as a compiler.
though, which is why I was prompting you to beNot at all. Anyone should instantly see that no HHH
more concrete. When Alan Turing published his seminal paper, he took a >>>>>> very great deal of space specifying exactly what he meant by a "machine".
[ .... ]
It's quite clear that DD will reach its
return statement if HHH(DD) returns 0.
So you can't see the recursive emulation non-halting
behavior pattern? DO you know what recursion is?
Whether endless recursion happens depends on whether HHH(DD) returns 0. >>>>>
can possibly ever return to any simulated DD.
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Others have pointed out problems with your reasoning here over a long >>>>>> period of time. I don't want to repeat that.
No one has ever pointed out any actual error
in this reasoning. Others have kept acting
like they have no idea what recursion is.
[ .... ]
The directly executed DDD() is not an input to HHH.
Vague word salad again.
We have the exact same thing in the Linz proof.
You do not. There is no concept of "directly executed" in turing >>>>>>>> machines, and Linz's proof concerns turing machines. Other people here
have said that one of the reasons you present your propositions as C, and
even some x86 assembly language, is to avoid the precision afforded by >>>>>>>> turing machines. I'd tend to agree with them, here.
Ĥ is applied to ⟨Ĥ⟩ is the directly executed Ĥ.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not the directly >>>>>>> executed Ĥ.
OK, that's a start, but it doesn't apply to turing machines.
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
[ .... ]
DD simulated by HHH is a non-halting pattern that HHH does recognize. >>>>>>That is disputed by everybody else on this newsgroup.
*Yet they cannot ever point out even a single actual mistake*
I make abstract things 100% concrete so that vagueness
and ambiguity cannot possibly exist.
Your postings are stuffed full of vagueness and ambiguity.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The above x86 machine code emulated by HHH according
to the semantics of the x86 language has zero vagueness
and zero ambiguity.
specify how this call instruction could be simulated,
As usual, no rebuttal, but claims without evidence.
I proved my statement in the part you removed from the quote.
Not telling the whole truth also counts as lying. Lying is dishonest.
When I explain something 500 times and people say
I never said it that is sufficient evidence to call
them a liar (or they have dementia).
On 7/8/2025 3:22 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 20:40 schreef olcott:
On 7/7/2025 2:49 AM, Fred. Zwarts wrote:
You are a damned liar.
Op 07.jul.2025 om 05:07 schreef olcott:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:It is incomplete, because it has a call instruction, but does not
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as >>>>>>>> to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a
description
of what you mean by "simulation".
I specifically mean that this x86 machine code
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 ; push DD
[0000216b] e862f4ffff call 000015d2 ; call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Is emulated by an x86 emulator named HHH.
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny >>>>>> pieces
out of it and dealing with those. The proof you claim to refute
has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.
It doesn't. See above.
It need not be a Turing machine to exactly match
the same pattern.
Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
It is a waste of time to discuss things at such an unnecessarily low >>>>>> level of abstraction.
It is just like you are saying that all huge things
are always very tiny. The high level of abstraction
of C is not any low level of abstraction.
But analysing it a bit further, it is not clear exactly what >>>>>>>> you mean by "simulated by HHH".
Do you have any idea what "simulation" means?
Yes. I'm not sure you do,
This should be something you learn in the first year of CS.
It is like an auto mechanic asking me: What is a spark plug?
The first thing that every programmer learns is that an
C language interpreter is not the same thing as a compiler.
though, which is why I was prompting you to be
more concrete. When Alan Turing published his seminal paper, he
took a
very great deal of space specifying exactly what he meant by a
"machine".
[ .... ]
It's quite clear that DD will reach its
return statement if HHH(DD) returns 0.
So you can't see the recursive emulation non-halting
behavior pattern? DO you know what recursion is?
Whether endless recursion happens depends on whether HHH(DD)
returns 0.
Not at all. Anyone should instantly see that no HHH
can possibly ever return to any simulated DD.
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Others have pointed out problems with your reasoning here over a long >>>>>> period of time. I don't want to repeat that.
No one has ever pointed out any actual error
in this reasoning. Others have kept acting
like they have no idea what recursion is.
[ .... ]
The directly executed DDD() is not an input to HHH.
Vague word salad again.
We have the exact same thing in the Linz proof.
You do not. There is no concept of "directly executed" in turing >>>>>>>> machines, and Linz's proof concerns turing machines. Other
people here
have said that one of the reasons you present your propositions >>>>>>>> as C, and
even some x86 assembly language, is to avoid the precision
afforded by
turing machines. I'd tend to agree with them, here.
Ĥ is applied to ⟨Ĥ⟩ is the directly executed Ĥ.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not the directly >>>>>>> executed Ĥ.
OK, that's a start, but it doesn't apply to turing machines.
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
[ .... ]
DD simulated by HHH is a non-halting pattern that HHH does
recognize.
That is disputed by everybody else on this newsgroup.
*Yet they cannot ever point out even a single actual mistake*
I make abstract things 100% concrete so that vagueness
and ambiguity cannot possibly exist.
Your postings are stuffed full of vagueness and ambiguity.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The above x86 machine code emulated by HHH according
to the semantics of the x86 language has zero vagueness
and zero ambiguity.
specify how this call instruction could be simulated,
As usual, no rebuttal, but claims without evidence.
100% complete proof that you cannot understand
remains 100% complete proof.
I have taken every computer science course for
a degree in computer science and have been a C++
software engineer for twenty years.
What are your credentials?
I proved my statement in the part you removed from the quote.
Not telling the whole truth also counts as lying. Lying is dishonest.
On 7/8/2025 3:22 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 20:40 schreef olcott:
On 7/7/2025 2:49 AM, Fred. Zwarts wrote:
You are a damned liar.
Op 07.jul.2025 om 05:07 schreef olcott:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:It is incomplete, because it has a call instruction, but does not
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as >>>>>>>> to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a
description
of what you mean by "simulation".
I specifically mean that this x86 machine code
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 ; push DD
[0000216b] e862f4ffff call 000015d2 ; call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Is emulated by an x86 emulator named HHH.
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny >>>>>> pieces
out of it and dealing with those. The proof you claim to refute
has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.
It doesn't. See above.
It need not be a Turing machine to exactly match
the same pattern.
Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
It is a waste of time to discuss things at such an unnecessarily low >>>>>> level of abstraction.
It is just like you are saying that all huge things
are always very tiny. The high level of abstraction
of C is not any low level of abstraction.
But analysing it a bit further, it is not clear exactly what >>>>>>>> you mean by "simulated by HHH".
Do you have any idea what "simulation" means?
Yes. I'm not sure you do,
This should be something you learn in the first year of CS.
It is like an auto mechanic asking me: What is a spark plug?
The first thing that every programmer learns is that an
C language interpreter is not the same thing as a compiler.
though, which is why I was prompting you to be
more concrete. When Alan Turing published his seminal paper, he
took a
very great deal of space specifying exactly what he meant by a
"machine".
[ .... ]
It's quite clear that DD will reach its
return statement if HHH(DD) returns 0.
So you can't see the recursive emulation non-halting
behavior pattern? DO you know what recursion is?
Whether endless recursion happens depends on whether HHH(DD)
returns 0.
Not at all. Anyone should instantly see that no HHH
can possibly ever return to any simulated DD.
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Others have pointed out problems with your reasoning here over a long >>>>>> period of time. I don't want to repeat that.
No one has ever pointed out any actual error
in this reasoning. Others have kept acting
like they have no idea what recursion is.
[ .... ]
The directly executed DDD() is not an input to HHH.
Vague word salad again.
We have the exact same thing in the Linz proof.
You do not. There is no concept of "directly executed" in turing >>>>>>>> machines, and Linz's proof concerns turing machines. Other
people here
have said that one of the reasons you present your propositions >>>>>>>> as C, and
even some x86 assembly language, is to avoid the precision
afforded by
turing machines. I'd tend to agree with them, here.
Ĥ is applied to ⟨Ĥ⟩ is the directly executed Ĥ.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not the directly >>>>>>> executed Ĥ.
OK, that's a start, but it doesn't apply to turing machines.
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
[ .... ]
DD simulated by HHH is a non-halting pattern that HHH does
recognize.
That is disputed by everybody else on this newsgroup.
*Yet they cannot ever point out even a single actual mistake*
I make abstract things 100% concrete so that vagueness
and ambiguity cannot possibly exist.
Your postings are stuffed full of vagueness and ambiguity.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The above x86 machine code emulated by HHH according
to the semantics of the x86 language has zero vagueness
and zero ambiguity.
specify how this call instruction could be simulated,
As usual, no rebuttal, but claims without evidence.
I proved my statement in the part you removed from the quote.
Not telling the whole truth also counts as lying. Lying is dishonest.
When I explain something 500 times and people say
I never said it that is sufficient evidence to call
them a liar (or they have dementia).
Here is the full execution trace of HHH(DDD)
that included HHH emulating itself emulating DDD. https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On 7/8/2025 3:22 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 20:40 schreef olcott:
On 7/7/2025 2:49 AM, Fred. Zwarts wrote:
You are a damned liar.
Op 07.jul.2025 om 05:07 schreef olcott:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:It is incomplete, because it has a call instruction, but does not
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as >>>>>>>> to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a
description
of what you mean by "simulation".
I specifically mean that this x86 machine code
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 ; push DD
[0000216b] e862f4ffff call 000015d2 ; call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Is emulated by an x86 emulator named HHH.
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny >>>>>> pieces
out of it and dealing with those. The proof you claim to refute
has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.
It doesn't. See above.
It need not be a Turing machine to exactly match
the same pattern.
Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
It is a waste of time to discuss things at such an unnecessarily low >>>>>> level of abstraction.
It is just like you are saying that all huge things
are always very tiny. The high level of abstraction
of C is not any low level of abstraction.
But analysing it a bit further, it is not clear exactly what >>>>>>>> you mean by "simulated by HHH".
Do you have any idea what "simulation" means?
Yes. I'm not sure you do,
This should be something you learn in the first year of CS.
It is like an auto mechanic asking me: What is a spark plug?
The first thing that every programmer learns is that an
C language interpreter is not the same thing as a compiler.
though, which is why I was prompting you to be
more concrete. When Alan Turing published his seminal paper, he
took a
very great deal of space specifying exactly what he meant by a
"machine".
[ .... ]
It's quite clear that DD will reach its
return statement if HHH(DD) returns 0.
So you can't see the recursive emulation non-halting
behavior pattern? DO you know what recursion is?
Whether endless recursion happens depends on whether HHH(DD)
returns 0.
Not at all. Anyone should instantly see that no HHH
can possibly ever return to any simulated DD.
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Others have pointed out problems with your reasoning here over a long >>>>>> period of time. I don't want to repeat that.
No one has ever pointed out any actual error
in this reasoning. Others have kept acting
like they have no idea what recursion is.
[ .... ]
The directly executed DDD() is not an input to HHH.
Vague word salad again.
We have the exact same thing in the Linz proof.
You do not. There is no concept of "directly executed" in turing >>>>>>>> machines, and Linz's proof concerns turing machines. Other
people here
have said that one of the reasons you present your propositions >>>>>>>> as C, and
even some x86 assembly language, is to avoid the precision
afforded by
turing machines. I'd tend to agree with them, here.
Ĥ is applied to ⟨Ĥ⟩ is the directly executed Ĥ.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not the directly >>>>>>> executed Ĥ.
OK, that's a start, but it doesn't apply to turing machines.
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
[ .... ]
DD simulated by HHH is a non-halting pattern that HHH does
recognize.
That is disputed by everybody else on this newsgroup.
*Yet they cannot ever point out even a single actual mistake*
I make abstract things 100% concrete so that vagueness
and ambiguity cannot possibly exist.
Your postings are stuffed full of vagueness and ambiguity.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The above x86 machine code emulated by HHH according
to the semantics of the x86 language has zero vagueness
and zero ambiguity.
specify how this call instruction could be simulated,
As usual, no rebuttal, but claims without evidence.
I proved my statement in the part you removed from the quote.
Not telling the whole truth also counts as lying. Lying is dishonest.
When I explain something 500 times and people say
I never said it that is sufficient evidence to call
them a liar (or they have dementia).
Here is the full execution trace of HHH(DDD)
that included HHH emulating itself emulating DDD. https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On 7/9/2025 3:50 AM, Fred. Zwarts wrote:Those are opposites.
Op 08.jul.2025 om 17:03 schreef olcott:
On 7/8/2025 3:22 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 20:40 schreef olcott:
On 7/7/2025 2:49 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:07 schreef olcott:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
It is really weird that you are calling a 100% complete concrete >>>>>>>>> specification "a low level of abstraction".
It is valueless; DDD does halt.Thus HHH(DD) does correctly determine that the halting problem's >>>>>>>>> counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
Your HHH is more concrete than just talking about a halt decider.It is just like you are saying that all huge things are always
very tiny. The high level of abstraction of C is not any low level >>>>>>> of abstraction.
Yes, HHH is not a decider.Not at all. Anyone should instantly see that no HHH can possibly >>>>>>> ever return to any simulated DD.
Not convincing.100% complete proof that you cannot understand remains 100% complete
proof.
...past the call to itself, which you vehemently agree to. Like this one:As usual no rebuttal, but claims without evidence.One of these "errors" was that HHH cannot simulate itself at all.
Many errors have been pointed out in your '100% proof', but you ignore
He just disagrees with it. You are the one who ignores everyI proved my statement in the part of the quotation that you deleted.I stop at your first big mistake because I found that my reviewers
Closing your eyes for a proof does not make it disappear. It would be
childish to say that.
has a very hard time paying any attention at all to a single point. I
can make the same single point to Richard 500 times and he never notices
that I said it even once.
On 7/9/2025 3:26 AM, Mikko wrote:
On 2025-07-08 14:33:26 +0000, olcott said:
On 7/8/2025 3:22 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 20:40 schreef olcott:
On 7/7/2025 2:49 AM, Fred. Zwarts wrote:
You are a damned liar.
Op 07.jul.2025 om 05:07 schreef olcott:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:It is incomplete, because it has a call instruction, but does not
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a description
of what you mean by "simulation".
I specifically mean that this x86 machine code
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 ; push DD
[0000216b] e862f4ffff call 000015d2 ; call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Is emulated by an x86 emulator named HHH.
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny pieces
out of it and dealing with those. The proof you claim to refute has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.
It doesn't. See above.
It need not be a Turing machine to exactly match
the same pattern.
Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
It is a waste of time to discuss things at such an unnecessarily low >>>>>>>> level of abstraction.
It is just like you are saying that all huge things
are always very tiny. The high level of abstraction
of C is not any low level of abstraction.
But analysing it a bit further, it is not clear exactly what >>>>>>>>>> you mean by "simulated by HHH".
Do you have any idea what "simulation" means?
Yes. I'm not sure you do,
This should be something you learn in the first year of CS.
It is like an auto mechanic asking me: What is a spark plug?
The first thing that every programmer learns is that an
C language interpreter is not the same thing as a compiler.
though, which is why I was prompting you to be
more concrete. When Alan Turing published his seminal paper, he took a
very great deal of space specifying exactly what he meant by a "machine".
[ .... ]
It's quite clear that DD will reach its
return statement if HHH(DD) returns 0.
So you can't see the recursive emulation non-halting
behavior pattern? DO you know what recursion is?
Whether endless recursion happens depends on whether HHH(DD) returns 0.
Not at all. Anyone should instantly see that no HHH
can possibly ever return to any simulated DD.
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Others have pointed out problems with your reasoning here over a long >>>>>>>> period of time. I don't want to repeat that.
No one has ever pointed out any actual error
in this reasoning. Others have kept acting
like they have no idea what recursion is.
[ .... ]
The directly executed DDD() is not an input to HHH.
Vague word salad again.
We have the exact same thing in the Linz proof.
You do not. There is no concept of "directly executed" in turing >>>>>>>>>> machines, and Linz's proof concerns turing machines. Other people here
have said that one of the reasons you present your propositions as C, and
even some x86 assembly language, is to avoid the precision afforded by
turing machines. I'd tend to agree with them, here.
Ĥ is applied to ⟨Ĥ⟩ is the directly executed Ĥ.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not the directly >>>>>>>>> executed Ĥ.
OK, that's a start, but it doesn't apply to turing machines.
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
[ .... ]
DD simulated by HHH is a non-halting pattern that HHH does recognize. >>>>>>>>That is disputed by everybody else on this newsgroup.
*Yet they cannot ever point out even a single actual mistake*
I make abstract things 100% concrete so that vagueness
and ambiguity cannot possibly exist.
Your postings are stuffed full of vagueness and ambiguity.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The above x86 machine code emulated by HHH according
to the semantics of the x86 language has zero vagueness
and zero ambiguity.
specify how this call instruction could be simulated,
As usual, no rebuttal, but claims without evidence.
I proved my statement in the part you removed from the quote.
Not telling the whole truth also counts as lying. Lying is dishonest.
When I explain something 500 times and people say
I never said it that is sufficient evidence to call
them a liar (or they have dementia).
You never explain. You can't even answer a simple question. Usually
you just repeat your lies or post something irrelevant pretending
that it be an answer.
I can answer questions. Whenever I do the answer is baseless denied.
On 7/9/2025 3:50 AM, Fred. Zwarts wrote:
Op 08.jul.2025 om 17:03 schreef olcott:
On 7/8/2025 3:22 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 20:40 schreef olcott:
On 7/7/2025 2:49 AM, Fred. Zwarts wrote:
You are a damned liar.
Op 07.jul.2025 om 05:07 schreef olcott:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:It is incomplete, because it has a call instruction, but does not
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as >>>>>>>>>> to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a
description
of what you mean by "simulation".
I specifically mean that this x86 machine code
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 ; push DD
[0000216b] e862f4ffff call 000015d2 ; call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Is emulated by an x86 emulator named HHH.
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping
tiny pieces
out of it and dealing with those. The proof you claim to refute >>>>>>>> has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.
It doesn't. See above.
It need not be a Turing machine to exactly match
the same pattern.
Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
It is a waste of time to discuss things at such an unnecessarily >>>>>>>> low
level of abstraction.
It is just like you are saying that all huge things
are always very tiny. The high level of abstraction
of C is not any low level of abstraction.
But analysing it a bit further, it is not clear exactly what >>>>>>>>>> you mean by "simulated by HHH".
Do you have any idea what "simulation" means?
Yes. I'm not sure you do,
This should be something you learn in the first year of CS.
It is like an auto mechanic asking me: What is a spark plug?
The first thing that every programmer learns is that an
C language interpreter is not the same thing as a compiler.
though, which is why I was prompting you to be
more concrete. When Alan Turing published his seminal paper, he >>>>>>>> took a
very great deal of space specifying exactly what he meant by a >>>>>>>> "machine".
[ .... ]
It's quite clear that DD will reach its
return statement if HHH(DD) returns 0.
So you can't see the recursive emulation non-halting
behavior pattern? DO you know what recursion is?
Whether endless recursion happens depends on whether HHH(DD)
returns 0.
Not at all. Anyone should instantly see that no HHH
can possibly ever return to any simulated DD.
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Others have pointed out problems with your reasoning here over a >>>>>>>> long
period of time. I don't want to repeat that.
No one has ever pointed out any actual error
in this reasoning. Others have kept acting
like they have no idea what recursion is.
[ .... ]
The directly executed DDD() is not an input to HHH.
Vague word salad again.
We have the exact same thing in the Linz proof.
You do not. There is no concept of "directly executed" in turing >>>>>>>>>> machines, and Linz's proof concerns turing machines. Other >>>>>>>>>> people here
have said that one of the reasons you present your
propositions as C, and
even some x86 assembly language, is to avoid the precision >>>>>>>>>> afforded by
turing machines. I'd tend to agree with them, here.
Ĥ is applied to ⟨Ĥ⟩ is the directly executed Ĥ.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not the directly >>>>>>>>> executed Ĥ.
OK, that's a start, but it doesn't apply to turing machines.
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
[ .... ]
DD simulated by HHH is a non-halting pattern that HHH does
recognize.
That is disputed by everybody else on this newsgroup.
*Yet they cannot ever point out even a single actual mistake*
I make abstract things 100% concrete so that vagueness
and ambiguity cannot possibly exist.
Your postings are stuffed full of vagueness and ambiguity.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The above x86 machine code emulated by HHH according
to the semantics of the x86 language has zero vagueness
and zero ambiguity.
specify how this call instruction could be simulated,
As usual, no rebuttal, but claims without evidence.
100% complete proof that you cannot understand
remains 100% complete proof.
As usual no rebuttal, but claims without evidence.
Many errors have been pointed out in your '100% proof', but you ignore
One of these "errors" was that HHH cannot simulate itself at all.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
them. (Although, a closer look tells me that you do not even say that
you presented a 100% proof.)
This code is 100% complete proof. https://github.com/plolcott/x86utm/blob/master/Halt7.c
I proved my statement in the part of the quotation that you deleted.
Closing your eyes for a proof does not make it disappear. It would be
childish to say that.
I stop at your first big mistake because
I found that my reviewers (especially Richard)
has a very hard time paying any attention at all
to a single point. I can make the same single
point to Richard 500 times and he never notices
that I said it even once.
On 7/9/2025 3:53 AM, Fred. Zwarts wrote:
Op 08.jul.2025 om 16:33 schreef olcott:
On 7/8/2025 3:22 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 20:40 schreef olcott:
On 7/7/2025 2:49 AM, Fred. Zwarts wrote:
You are a damned liar.
Op 07.jul.2025 om 05:07 schreef olcott:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:It is incomplete, because it has a call instruction, but does not
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as >>>>>>>>>> to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a
description
of what you mean by "simulation".
I specifically mean that this x86 machine code
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 ; push DD
[0000216b] e862f4ffff call 000015d2 ; call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Is emulated by an x86 emulator named HHH.
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping
tiny pieces
out of it and dealing with those. The proof you claim to refute >>>>>>>> has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.
It doesn't. See above.
It need not be a Turing machine to exactly match
the same pattern.
Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
It is a waste of time to discuss things at such an unnecessarily >>>>>>>> low
level of abstraction.
It is just like you are saying that all huge things
are always very tiny. The high level of abstraction
of C is not any low level of abstraction.
But analysing it a bit further, it is not clear exactly what >>>>>>>>>> you mean by "simulated by HHH".
Do you have any idea what "simulation" means?
Yes. I'm not sure you do,
This should be something you learn in the first year of CS.
It is like an auto mechanic asking me: What is a spark plug?
The first thing that every programmer learns is that an
C language interpreter is not the same thing as a compiler.
though, which is why I was prompting you to be
more concrete. When Alan Turing published his seminal paper, he >>>>>>>> took a
very great deal of space specifying exactly what he meant by a >>>>>>>> "machine".
[ .... ]
It's quite clear that DD will reach its
return statement if HHH(DD) returns 0.
So you can't see the recursive emulation non-halting
behavior pattern? DO you know what recursion is?
Whether endless recursion happens depends on whether HHH(DD)
returns 0.
Not at all. Anyone should instantly see that no HHH
can possibly ever return to any simulated DD.
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Others have pointed out problems with your reasoning here over a >>>>>>>> long
period of time. I don't want to repeat that.
No one has ever pointed out any actual error
in this reasoning. Others have kept acting
like they have no idea what recursion is.
[ .... ]
The directly executed DDD() is not an input to HHH.
Vague word salad again.
We have the exact same thing in the Linz proof.
You do not. There is no concept of "directly executed" in turing >>>>>>>>>> machines, and Linz's proof concerns turing machines. Other >>>>>>>>>> people here
have said that one of the reasons you present your
propositions as C, and
even some x86 assembly language, is to avoid the precision >>>>>>>>>> afforded by
turing machines. I'd tend to agree with them, here.
Ĥ is applied to ⟨Ĥ⟩ is the directly executed Ĥ.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not the directly >>>>>>>>> executed Ĥ.
OK, that's a start, but it doesn't apply to turing machines.
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
[ .... ]
DD simulated by HHH is a non-halting pattern that HHH does
recognize.
That is disputed by everybody else on this newsgroup.
*Yet they cannot ever point out even a single actual mistake*
I make abstract things 100% concrete so that vagueness
and ambiguity cannot possibly exist.
Your postings are stuffed full of vagueness and ambiguity.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The above x86 machine code emulated by HHH according
to the semantics of the x86 language has zero vagueness
and zero ambiguity.
specify how this call instruction could be simulated,
As usual, no rebuttal, but claims without evidence.
I proved my statement in the part you removed from the quote.
Not telling the whole truth also counts as lying. Lying is dishonest.
When I explain something 500 times and people say
I never said it that is sufficient evidence to call
them a liar (or they have dementia).
Here is the full execution trace of HHH(DDD)
that included HHH emulating itself emulating DDD.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
You can repeat your errors even more often, but that does not make
them true.
Even the trace proves that HHH aborts prematurely, before it can see
that the finite recursion would reach the final halt state only one
cycle later.
Sure
and infinite loops end when you wait until
the heat death of the universe.
Your 'proofs' turns out to be false claims without evidence.
On 7/9/2025 3:26 AM, Mikko wrote:
On 2025-07-08 14:33:26 +0000, olcott said:
On 7/8/2025 3:22 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 20:40 schreef olcott:
On 7/7/2025 2:49 AM, Fred. Zwarts wrote:
You are a damned liar.
Op 07.jul.2025 om 05:07 schreef olcott:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:It is incomplete, because it has a call instruction, but does not
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as >>>>>>>>>> to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a
description
of what you mean by "simulation".
I specifically mean that this x86 machine code
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 ; push DD
[0000216b] e862f4ffff call 000015d2 ; call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Is emulated by an x86 emulator named HHH.
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping
tiny pieces
out of it and dealing with those. The proof you claim to refute >>>>>>>> has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.
It doesn't. See above.
It need not be a Turing machine to exactly match
the same pattern.
Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
It is a waste of time to discuss things at such an unnecessarily >>>>>>>> low
level of abstraction.
It is just like you are saying that all huge things
are always very tiny. The high level of abstraction
of C is not any low level of abstraction.
But analysing it a bit further, it is not clear exactly what >>>>>>>>>> you mean by "simulated by HHH".
Do you have any idea what "simulation" means?
Yes. I'm not sure you do,
This should be something you learn in the first year of CS.
It is like an auto mechanic asking me: What is a spark plug?
The first thing that every programmer learns is that an
C language interpreter is not the same thing as a compiler.
though, which is why I was prompting you to be
more concrete. When Alan Turing published his seminal paper, he >>>>>>>> took a
very great deal of space specifying exactly what he meant by a >>>>>>>> "machine".
[ .... ]
It's quite clear that DD will reach its
return statement if HHH(DD) returns 0.
So you can't see the recursive emulation non-halting
behavior pattern? DO you know what recursion is?
Whether endless recursion happens depends on whether HHH(DD)
returns 0.
Not at all. Anyone should instantly see that no HHH
can possibly ever return to any simulated DD.
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Others have pointed out problems with your reasoning here over a >>>>>>>> long
period of time. I don't want to repeat that.
No one has ever pointed out any actual error
in this reasoning. Others have kept acting
like they have no idea what recursion is.
[ .... ]
The directly executed DDD() is not an input to HHH.
Vague word salad again.
We have the exact same thing in the Linz proof.
You do not. There is no concept of "directly executed" in turing >>>>>>>>>> machines, and Linz's proof concerns turing machines. Other >>>>>>>>>> people here
have said that one of the reasons you present your
propositions as C, and
even some x86 assembly language, is to avoid the precision >>>>>>>>>> afforded by
turing machines. I'd tend to agree with them, here.
Ĥ is applied to ⟨Ĥ⟩ is the directly executed Ĥ.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not the directly >>>>>>>>> executed Ĥ.
OK, that's a start, but it doesn't apply to turing machines.
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
[ .... ]
DD simulated by HHH is a non-halting pattern that HHH does
recognize.
That is disputed by everybody else on this newsgroup.
*Yet they cannot ever point out even a single actual mistake*
I make abstract things 100% concrete so that vagueness
and ambiguity cannot possibly exist.
Your postings are stuffed full of vagueness and ambiguity.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The above x86 machine code emulated by HHH according
to the semantics of the x86 language has zero vagueness
and zero ambiguity.
specify how this call instruction could be simulated,
As usual, no rebuttal, but claims without evidence.
I proved my statement in the part you removed from the quote.
Not telling the whole truth also counts as lying. Lying is dishonest.
When I explain something 500 times and people say
I never said it that is sufficient evidence to call
them a liar (or they have dementia).
You never explain. You can't even answer a simple question. Usually
you just repeat your lies or post something irrelevant pretending
that it be an answer.
I can answer questions. Whenever I do the answer is baseless denied.
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself at all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself correctly
*up to the end*.
Exactly what is your professional programming experience?
I have 20 years in C++ and became a professional programmer
in 1986.
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself at all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself correctly
*up to the end*.
Exactly what is your professional programming experience?
I have 20 years in C++ and became a professional programmer
in 1986.
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself at all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to the
end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself
correctly *up to the end*.
Exactly what is your professional programming experience?
I have 20 years in C++ and became a professional programmer
in 1986.
Irrelevant, even when it is more than your experience.
void DDD()
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
Even a proof of a first year student can be a correct proof.
Apparently you ran out of counter arguments and try the authority card.
I want to see if you have the capacity to understand.
COBOL experience counts as zero programming experience
relative to anything about recursion.
So, we see that HHH cannot possibly simulate itself up to the end.
Because DDD unconditionally calls HHH(DDD).
Do you know what unconditionally means?
This failure of HHH is
entirely your own misconception.
an important fact in your code, because it shows that simulation is
not the right tool for all inputs.
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself at all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to the
end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself
correctly *up to the end*.
Exactly what is your professional programming experience?
I have 20 years in C++ and became a professional programmer
in 1986.
Irrelevant, even when it is more than your experience.
void DDD()
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
Even a proof of a first year student can be a correct proof.
Apparently you ran out of counter arguments and try the authority card.
I want to see if you have the capacity to understand.
COBOL experience counts as zero programming experience
relative to anything about recursion.
So, we see that HHH cannot possibly simulate itself up to the end.
Because DDD unconditionally calls HHH(DDD).
Do you know what unconditionally means?
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:That means that HHH reports itself as not being a decider.
Op 10.jul.2025 om 16:30 schreef olcott:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf Is the full
execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself
correctly *up to the end*.
void DDD()
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH cannot possibly reach
its own "return" instruction (a) Has woefully deficient knowledge (b) Is
a liar.
--So, we see that HHH cannot possibly simulate itself up to the end.Because DDD unconditionally calls HHH(DDD).
On 7/12/25 12:42 AM, olcott wrote:
On 7/11/2025 6:34 PM, Richard Damon wrote:
On 7/10/25 10:30 AM, olcott wrote:What of kind of systems did you work with?
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:So? I started programming for pay in 1974, where as an undergraduate I
Op 09.jul.2025 om 14:54 schreef olcott:>>Exactly what is your professional programming experience? I have 20
One of these "errors" was that HHH cannot simulate itself at all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to the
end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf Is the full
execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself
correctly *up to the end*.
years in C++ and became a professional programmer in 1986.
was using my programming from High School to build Data Analsys
programs, an inter-computer link to make a computer with a vector
graphics dispaly usable by the main frame, and the OS and data
collection programs for a laboratory.
In 1982, with my MASTERS degree, I was employed to write programs, as
well as design hardware for an industrial firm.
It seems I have many years over you, and it sounds like I may have
well written more programs than you have.
I started using C from K&R in the late 70s and C++ using Cfront in the
mid 80s. (so like 40 years of experience).
I programmed AutoCAD in C++ creating new architectural engineering
automations. This was mostly analytical geometry. I worked in C++ and
some C for the last 22 years. I worked on NPOESS
https://en.wikipedia.org/wiki/NPOESS for Northrup Grumman
In otherwords, you let an existing program do most of the work, and you
added some fonctionality to it.
As to NPOESS, just "working on it" doesn't give much idea of your responsibilities, and tha fact that it was a FAILED system, scrubbed due
to progtram issues doesn't say much for what you can do.
It seems that in all your work, you might never have produced an actual "program", only pieces of systems, which explains why you don't
understand what a "program" actually is.
Most of my work has been in embedded system, where I built the hardware around a processor for some function, and then fully programmed the
processor from the ground up to complete the product. I also wrote PC
side support for control of the embedded application.
As part of this, I have produced a large library of support functions to allow the building of similar programs by others, which has become the
basis for much of the work produced at the company I work for.
I will note that I am STILL active in the profession, and now spend part
of my time training others in the company to improve their skills, while
it seems you are no longer at work, and I doubt you get many calls
asking for advice about how to do things.
On Sat, 12 Jul 2025 08:20:59 -0400, Richard Damon wrote:
On 7/12/25 12:42 AM, olcott wrote:
On 7/11/2025 6:34 PM, Richard Damon wrote:
On 7/10/25 10:30 AM, olcott wrote:What of kind of systems did you work with?
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:So? I started programming for pay in 1974, where as an undergraduate I >>>> was using my programming from High School to build Data Analsys
Op 09.jul.2025 om 14:54 schreef olcott:>>Exactly what is your professional programming experience? I have 20
One of these "errors" was that HHH cannot simulate itself at all. >>>>>>As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to the >>>>>> end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf Is the full
execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself
correctly *up to the end*.
years in C++ and became a professional programmer in 1986.
programs, an inter-computer link to make a computer with a vector
graphics dispaly usable by the main frame, and the OS and data
collection programs for a laboratory.
In 1982, with my MASTERS degree, I was employed to write programs, as
well as design hardware for an industrial firm.
It seems I have many years over you, and it sounds like I may have
well written more programs than you have.
I started using C from K&R in the late 70s and C++ using Cfront in the >>>> mid 80s. (so like 40 years of experience).
I programmed AutoCAD in C++ creating new architectural engineering
automations. This was mostly analytical geometry. I worked in C++ and
some C for the last 22 years. I worked on NPOESS
https://en.wikipedia.org/wiki/NPOESS for Northrup Grumman
In otherwords, you let an existing program do most of the work, and you
added some fonctionality to it.
As to NPOESS, just "working on it" doesn't give much idea of your
responsibilities, and tha fact that it was a FAILED system, scrubbed due
to progtram issues doesn't say much for what you can do.
It seems that in all your work, you might never have produced an actual
"program", only pieces of systems, which explains why you don't
understand what a "program" actually is.
Most of my work has been in embedded system, where I built the hardware
around a processor for some function, and then fully programmed the
processor from the ground up to complete the product. I also wrote PC
side support for control of the embedded application.
As part of this, I have produced a large library of support functions to
allow the building of similar programs by others, which has become the
basis for much of the work produced at the company I work for.
I will note that I am STILL active in the profession, and now spend part
of my time training others in the company to improve their skills, while
it seems you are no longer at work, and I doubt you get many calls
asking for advice about how to do things.
Your personality really is quite obnoxious isn't it, Damon?
/Flibble
On 7/12/25 8:30 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 08:20:59 -0400, Richard Damon wrote:
On 7/12/25 12:42 AM, olcott wrote:
On 7/11/2025 6:34 PM, Richard Damon wrote:
On 7/10/25 10:30 AM, olcott wrote:What of kind of systems did you work with?
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:So? I started programming for pay in 1974, where as an undergraduate >>>>> I was using my programming from High School to build Data Analsys
Op 09.jul.2025 om 14:54 schreef olcott:>>Exactly what is your professional programming experience? I have 20 >>>>>> years in C++ and became a professional programmer in 1986.
One of these "errors" was that HHH cannot simulate itself at all. >>>>>>>As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to the >>>>>>> end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf Is the full
execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself
correctly *up to the end*.
programs, an inter-computer link to make a computer with a vector
graphics dispaly usable by the main frame, and the OS and data
collection programs for a laboratory.
In 1982, with my MASTERS degree, I was employed to write programs,
as well as design hardware for an industrial firm.
It seems I have many years over you, and it sounds like I may have
well written more programs than you have.
I started using C from K&R in the late 70s and C++ using Cfront in
the mid 80s. (so like 40 years of experience).
I programmed AutoCAD in C++ creating new architectural engineering
automations. This was mostly analytical geometry. I worked in C++ and
some C for the last 22 years. I worked on NPOESS
https://en.wikipedia.org/wiki/NPOESS for Northrup Grumman
In otherwords, you let an existing program do most of the work, and
you added some fonctionality to it.
As to NPOESS, just "working on it" doesn't give much idea of your
responsibilities, and tha fact that it was a FAILED system, scrubbed
due to progtram issues doesn't say much for what you can do.
It seems that in all your work, you might never have produced an
actual "program", only pieces of systems, which explains why you don't
understand what a "program" actually is.
Most of my work has been in embedded system, where I built the
hardware around a processor for some function, and then fully
programmed the processor from the ground up to complete the product. I
also wrote PC side support for control of the embedded application.
As part of this, I have produced a large library of support functions
to allow the building of similar programs by others, which has become
the basis for much of the work produced at the company I work for.
I will note that I am STILL active in the profession, and now spend
part of my time training others in the company to improve their
skills, while it seems you are no longer at work, and I doubt you get
many calls asking for advice about how to do things.
Your personality really is quite obnoxious isn't it, Damon?
/Flibble
HE asked the question.
HE claims to be an expert, with no actual credentials and calls me the
one who doesn't know what I am doing, even though I am much better
trained then him.
You and He are the "obnoxious" ones, that need to use ad hominim attacks
as you have no factual grounds to refute the errors pointed out.
On 7/11/2025 6:34 PM, Richard Damon wrote:
On 7/10/25 10:30 AM, olcott wrote:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself at all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to the
end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself
correctly *up to the end*.
Exactly what is your professional programming experience?
I have 20 years in C++ and became a professional programmer
in 1986.
So? I started programming for pay in 1974, where as an undergraduate I
was using my programming from High School to build Data Analsys
programs, an inter-computer link to make a computer with a vector
graphics dispaly usable by the main frame, and the OS and data
collection programs for a laboratory.
In 1982, with my MASTERS degree, I was employed to write programs, as
well as design hardware for an industrial firm.
It seems I have many years over you, and it sounds like I may have
well written more programs than you have.
I started using C from K&R in the late 70s and C++ using Cfront in the
mid 80s. (so like 40 years of experience).
What of kind of systems did you work with?
I programmed AutoCAD in C++ creating new architectural engineering automations. This was mostly analytical geometry. I worked in C++ and
some C for the last 22 years. I worked on NPOESS https://en.wikipedia.org/wiki/NPOESS for Northrup Grumman
It seems you have much to learn about these languages, as you don't
even seem to understand the basic meaning of some of the core terms,
like what a "program" is.
On 7/12/2025 5:49 AM, joes wrote:HHH is not a pure simulator.
Am Fri, 11 Jul 2025 16:23:19 -0500 schrieb olcott:
In other words you cannot understand that the behavior of DDD simulatedvoid DDD()That means that HHH reports itself as not being a decider.
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH cannot possibly reach
its own "return" instruction (a) Has woefully deficient knowledge (b)
Is a liar.
by a pure simulator HHH would be an infinite repetition of its first
line?
On 7/12/2025 2:46 PM, joes wrote:No, I get it. If HHH were a pure simulator it would nest copies of itself forever. A pure simulator running DDD as is would halt. If DDD called a
Am Sat, 12 Jul 2025 09:52:21 -0500 schrieb olcott:
On 7/12/2025 5:49 AM, joes wrote:
Am Fri, 11 Jul 2025 16:23:19 -0500 schrieb olcott:
We have to break it down to its simpler steps or don't seem to have any understanding at all.HHH is not a pure simulator.In other words you cannot understand that the behavior of DDDAnyone that cannot see that DDD simulated by HHH cannot possiblyThat means that HHH reports itself as not being a decider.
reach its own "return" instruction (a) Has woefully deficient
knowledge (b) Is a liar.
simulated by a pure simulator HHH would be an infinite repetition of
its first line?
(1) If HHH was a pure simulator it would endlessly
simulate the first instruction of DDD and never reach the "return"
statement.
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself at all. >>>>>>As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to the >>>>>> end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself
correctly *up to the end*.
Exactly what is your professional programming experience?
I have 20 years in C++ and became a professional programmer
in 1986.
Irrelevant, even when it is more than your experience.
void DDD()
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to simulate it
correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics
of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
You don't seem to understand what ordinary recursion is.
You have never proved that you understand what ordinary
recursion is.
Even a proof of a first year student can be a correct proof.I want to see if you have the capacity to understand.
Apparently you ran out of counter arguments and try the authority card. >>>
COBOL experience counts as zero programming experience
relative to anything about recursion.
Irrelevant. We know that when it turns out that I have more
experience, you will find another irrelevant reason to ignore the facts.
So, we see that HHH cannot possibly simulate itself up to the end.
Because DDD unconditionally calls HHH(DDD).
Do you know what unconditionally means?
Yes I do. It means that the halting of DDD depends on the halting of
HHH and HHH has conditional branch instructions, which make that it
returns to DDD, so that DDD reaches its final halt state, if not
disturbed by a premature abort.
Your misconception is that you think that the behaviour of DDD does
not depend on the behaviour of HHH.
On Sat, 12 Jul 2025 08:36:55 -0400, Richard Damon wrote:
On 7/12/25 8:30 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 08:20:59 -0400, Richard Damon wrote:
On 7/12/25 12:42 AM, olcott wrote:
On 7/11/2025 6:34 PM, Richard Damon wrote:
On 7/10/25 10:30 AM, olcott wrote:What of kind of systems did you work with?
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:So? I started programming for pay in 1974, where as an undergraduate >>>>>> I was using my programming from High School to build Data Analsys
Op 09.jul.2025 om 14:54 schreef olcott:>>Exactly what is your professional programming experience? I have 20 >>>>>>> years in C++ and became a professional programmer in 1986.
One of these "errors" was that HHH cannot simulate itself at all. >>>>>>>>As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to the >>>>>>>> end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf Is the full
execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself
correctly *up to the end*.
programs, an inter-computer link to make a computer with a vector
graphics dispaly usable by the main frame, and the OS and data
collection programs for a laboratory.
In 1982, with my MASTERS degree, I was employed to write programs, >>>>>> as well as design hardware for an industrial firm.
It seems I have many years over you, and it sounds like I may have >>>>>> well written more programs than you have.
I started using C from K&R in the late 70s and C++ using Cfront in >>>>>> the mid 80s. (so like 40 years of experience).
I programmed AutoCAD in C++ creating new architectural engineering
automations. This was mostly analytical geometry. I worked in C++ and >>>>> some C for the last 22 years. I worked on NPOESS
https://en.wikipedia.org/wiki/NPOESS for Northrup Grumman
In otherwords, you let an existing program do most of the work, and
you added some fonctionality to it.
As to NPOESS, just "working on it" doesn't give much idea of your
responsibilities, and tha fact that it was a FAILED system, scrubbed
due to progtram issues doesn't say much for what you can do.
It seems that in all your work, you might never have produced an
actual "program", only pieces of systems, which explains why you don't >>>> understand what a "program" actually is.
Most of my work has been in embedded system, where I built the
hardware around a processor for some function, and then fully
programmed the processor from the ground up to complete the product. I >>>> also wrote PC side support for control of the embedded application.
As part of this, I have produced a large library of support functions
to allow the building of similar programs by others, which has become
the basis for much of the work produced at the company I work for.
I will note that I am STILL active in the profession, and now spend
part of my time training others in the company to improve their
skills, while it seems you are no longer at work, and I doubt you get
many calls asking for advice about how to do things.
Your personality really is quite obnoxious isn't it, Damon?
/Flibble
HE asked the question.
HE claims to be an expert, with no actual credentials and calls me the
one who doesn't know what I am doing, even though I am much better
trained then him.
You and He are the "obnoxious" ones, that need to use ad hominim attacks
as you have no factual grounds to refute the errors pointed out.
You make more ad hominum attacks than anyone else on here, Damon.
/Flibble
On 7/12/2025 7:20 AM, Richard Damon wrote:
On 7/12/25 12:42 AM, olcott wrote:
On 7/11/2025 6:34 PM, Richard Damon wrote:
On 7/10/25 10:30 AM, olcott wrote:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself at all. >>>>>>As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to the >>>>>> end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself
correctly *up to the end*.
Exactly what is your professional programming experience?
I have 20 years in C++ and became a professional programmer
in 1986.
So? I started programming for pay in 1974, where as an undergraduate
I was using my programming from High School to build Data Analsys
programs, an inter-computer link to make a computer with a vector
graphics dispaly usable by the main frame, and the OS and data
collection programs for a laboratory.
In 1982, with my MASTERS degree, I was employed to write programs,
as well as design hardware for an industrial firm.
It seems I have many years over you, and it sounds like I may have
well written more programs than you have.
I started using C from K&R in the late 70s and C++ using Cfront in
the mid 80s. (so like 40 years of experience).
What of kind of systems did you work with?
I programmed AutoCAD in C++ creating new architectural engineering
automations. This was mostly analytical geometry. I worked in C++ and
some C for the last 22 years. I worked on NPOESS
https://en.wikipedia.org/wiki/NPOESS for Northrup Grumman
In otherwords, you let an existing program do most of the work, and
you added some fonctionality to it.
All of my AutoCAD work was fully operational programs
that automated some part of the architectural engineering
process. One of these programs found all of the doorways
in an AutoCAD drawing and then automatically drew doors.
As to NPOESS, just "working on it" doesn't give much idea of your
responsibilities, and tha fact that it was a FAILED system, scrubbed
due to progtram issues doesn't say much for what you can do.
It seems that in all your work, you might never have produced an
actual "program", only pieces of systems, which explains why you don't
understand what a "program" actually is.
Most of my work has been in embedded system, where I built the
hardware around a processor for some function, and then fully
programmed the processor from the ground up to complete the product. I
also wrote PC side support for control of the embedded application.
I provided a Windows interface to an operating system
that executed on a smart card. It was just like those
white cards that unlocked doors, yet also verified the
user's fingerprint before unlocking.
As part of this, I have produced a large library of support functions
to allow the building of similar programs by others, which has become
the basis for much of the work produced at the company I work for.
I will note that I am STILL active in the profession, and now spend
part of my time training others in the company to improve their
skills, while it seems you are no longer at work, and I doubt you get
many calls asking for advice about how to do things.
What computer languages?
It seems you have much to learn about these languages, as you don't
even seem to understand the basic meaning of some of the core terms,
like what a "program" is.
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:There is no non-halting pattern. It is the failure of HHH to detect a non-existing pattern.
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself at all. >>>>>>As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to the >>>>>> end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself
correctly *up to the end*.
Exactly what is your professional programming experience?
I have 20 years in C++ and became a professional programmer
in 1986.
Irrelevant, even when it is more than your experience.
void DDD()
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to simulate it
correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics
of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
On 7/12/2025 4:25 PM, joes wrote:Contrary to you I can handle multiple steps at a time. I already answered
Am Sat, 12 Jul 2025 14:54:28 -0500 schrieb olcott:*You jumped too many steps ahead*
On 7/12/2025 2:46 PM, joes wrote:No, I get it. If HHH were a pure simulator it would nest copies of
Am Sat, 12 Jul 2025 09:52:21 -0500 schrieb olcott:
On 7/12/2025 5:49 AM, joes wrote:
Am Fri, 11 Jul 2025 16:23:19 -0500 schrieb olcott:
We have to break it down to its simpler steps or don't seem to haveHHH is not a pure simulator.In other words you cannot understand that the behavior of DDDAnyone that cannot see that DDD simulated by HHH cannot possibly >>>>>>> reach its own "return" instruction (a) Has woefully deficientThat means that HHH reports itself as not being a decider.
knowledge (b) Is a liar.
simulated by a pure simulator HHH would be an infinite repetition of >>>>> its first line?
any understanding at all.
(1) If HHH was a pure simulator it would endlessly
simulate the first instruction of DDD and never reach the
"return"
statement.
itself forever. A pure simulator running DDD as is would halt. If DDD
called a pure simulator, HHH would correctly return "doesn't halt". And
HHH running DDD does so incorrectly. You confuse that with the second
case.
There is only this one step:
If HHH was a pure simulator would DDD simulated by HHH reach its own
"return" instruction?
I have another micro-step immediately after this one so if you jump
ahead we have to keep repeating this step over and over until we are
done with this step.
On 7/12/2025 6:09 PM, Richard Damon wrote:
On 7/12/25 10:39 AM, olcott wrote:
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself at all. >>>>>>>>As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to >>>>>>>> the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself
correctly *up to the end*.
Exactly what is your professional programming experience?
I have 20 years in C++ and became a professional programmer
in 1986.
Irrelevant, even when it is more than your experience.
void DDD()
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to simulate
it correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics
of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
But thst pattern *ISN'T* a "non-halting" pattern, as it also occurs in
the direct execution of DDD, which you admit halts.
Thus, the claim of non-halting is just based on a lie.
Since you seem to have sufficient technical competence and
you know that halting is reaching a final halt state then
you know that when 0 to ∞ steps are correctly simulated by
some HHH according to the semantics of the C programming language
that no DDD simulated by any HHH ever reaches its final halt state.
On 7/13/2025 5:26 AM, joes wrote:I did answer in the affirmative. Where's the difference?
Am Sat, 12 Jul 2025 16:45:50 -0500 schrieb olcott:
On 7/12/2025 4:25 PM, joes wrote:
Am Sat, 12 Jul 2025 14:54:28 -0500 schrieb olcott:
On 7/12/2025 2:46 PM, joes wrote:
Am Sat, 12 Jul 2025 09:52:21 -0500 schrieb olcott:
On 7/12/2025 5:49 AM, joes wrote:
No you answered a similar question not the exact same question. Can DDD simulated by pure simulator HHH ever reach its "return" instruction?Contrary to you I can handle multiple steps at a time. I already*You jumped too many steps ahead*No, I get it. If HHH were a pure simulator it would nest copies ofWe have to break it down to its simpler steps or don't seem to haveHHH is not a pure simulator.That means that HHH reports itself as not being a decider.In other words you cannot understand that the behavior of DDD
simulated by a pure simulator HHH would be an infinite repetition >>>>>>> of its first line?
any understanding at all.
(1) If HHH was a pure simulator it would endlessly
simulate the first instruction of DDD and never reach the
"return"
statement.
itself forever. A pure simulator running DDD as is would halt. If DDD
called a pure simulator, HHH would correctly return "doesn't halt".
And HHH running DDD does so incorrectly. You confuse that with the
second case.
There is only this one step:
If HHH was a pure simulator would DDD simulated by HHH reach its own
"return" instruction?
I have another micro-step immediately after this one so if you jump
ahead we have to keep repeating this step over and over until we are
done with this step.
answered your question above. What's your next step?
On 7/13/2025 5:26 AM, joes wrote:
Am Sat, 12 Jul 2025 16:45:50 -0500 schrieb olcott:
On 7/12/2025 4:25 PM, joes wrote:Contrary to you I can handle multiple steps at a time. I already answered
Am Sat, 12 Jul 2025 14:54:28 -0500 schrieb olcott:*You jumped too many steps ahead*
On 7/12/2025 2:46 PM, joes wrote:No, I get it. If HHH were a pure simulator it would nest copies of
Am Sat, 12 Jul 2025 09:52:21 -0500 schrieb olcott:
On 7/12/2025 5:49 AM, joes wrote:
Am Fri, 11 Jul 2025 16:23:19 -0500 schrieb olcott:
We have to break it down to its simpler steps or don't seem to haveHHH is not a pure simulator.In other words you cannot understand that the behavior of DDDAnyone that cannot see that DDD simulated by HHH cannot possibly >>>>>>>>> reach its own "return" instruction (a) Has woefully deficient >>>>>>>>> knowledge (b) Is a liar.That means that HHH reports itself as not being a decider.
simulated by a pure simulator HHH would be an infinite repetition of >>>>>>> its first line?
any understanding at all.
(1) If HHH was a pure simulator it would endlessly
simulate the first instruction of DDD and never reach the >>>>> "return"
statement.
itself forever. A pure simulator running DDD as is would halt. If DDD
called a pure simulator, HHH would correctly return "doesn't halt". And >>>> HHH running DDD does so incorrectly. You confuse that with the second
case.
There is only this one step:
If HHH was a pure simulator would DDD simulated by HHH reach its own
"return" instruction?
I have another micro-step immediately after this one so if you jump
ahead we have to keep repeating this step over and over until we are
done with this step.
your question above. What's your next step?
No you answered a similar question not the exact same
question. Can DDD simulated by pure simulator HHH ever
reach its "return" instruction?
On 7/13/2025 7:04 AM, Richard Damon wrote:
On 7/12/25 7:40 PM, olcott wrote:
On 7/12/2025 6:09 PM, Richard Damon wrote:
On 7/12/25 10:39 AM, olcott wrote:
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself at >>>>>>>>>>> all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to >>>>>>>>>> the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself >>>>>>>>>> correctly *up to the end*.
Exactly what is your professional programming experience?
I have 20 years in C++ and became a professional programmer
in 1986.
Irrelevant, even when it is more than your experience.
void DDD()
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to
simulate it correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics
of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
But thst pattern *ISN'T* a "non-halting" pattern, as it also occurs
in the direct execution of DDD, which you admit halts.
Thus, the claim of non-halting is just based on a lie.
Since you seem to have sufficient technical competence and
you know that halting is reaching a final halt state then
you know that when 0 to ∞ steps are correctly simulated by
some HHH according to the semantics of the C programming language
that no DDD simulated by any HHH ever reaches its final halt state.
Halting is the *PROGRAM* reaching a final stste when it is run.
This same thing can be applied to C functions reaching
their "return" instructions. The field of termination
analysis breaks programs down to their constituent parts.
When a called function cannot return this entails that
the caller will not stop running.
On 7/13/2025 1:06 AM, Fred. Zwarts wrote:
Op 12.jul.2025 om 16:39 schreef olcott:
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:There is no non-halting pattern.
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself at all. >>>>>>>>As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to >>>>>>>> the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself
correctly *up to the end*.
Exactly what is your professional programming experience?
I have 20 years in C++ and became a professional programmer
in 1986.
Irrelevant, even when it is more than your experience.
void DDD()
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to simulate
it correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics
of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
*When you keep ignoring my correction to your mistakes*
*then you never notice that you made any mistakes*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
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
It is a tautology that any input D to simulating termination
analyzer H that *would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
It is the failure of HHH to detect a non-existing pattern.
The semantics of the x86 language determine a halting pattern, as is
proven by many world-class simulators and even by direct execution of
exactly the same input. That HHH does not see that, is a failure,
proving that simulation is not the right tool for such input.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD emulated by HHH according to the semantics
of the x86 language cannot possibly get past
its own machine address [0000219a] whether HHH
aborts its simulation or not.
That you don't understand this is your own lack
of understanding NOT ANY ACTUAL REBUTTAL AT ALL.
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:No, every input is decidable, but not the whole problem by a single
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
An argument like this is at such a low level of abstraction as to
be near valuless.
It is really weird that you are calling a 100% complete concrete
specification "a low level of abstraction". That HHH(DD) correctly
determines that DD simulated by HHH cannot possibly halt is a proven >>>>> fact.
A complete concrete specification would necessarily include a
description of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to say what
you mean by an "x86 emulator". The name you give it is irrelevant
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny
pieces out of it and dealing with those. The proof you claim to
refute has no notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function returns true
or false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable input for HHH.
This is its counter example refuting the claim that a universal halt
decider can exist.
On 7/13/2025 1:32 PM, joes wrote:Have you heard of paraphrasing? What IS the difference now?
Am Sun, 13 Jul 2025 09:14:56 -0500 schrieb olcott:It must perfectly 100% specific about DDD simulated by pure simulator
On 7/13/2025 5:26 AM, joes wrote:I did answer in the affirmative. Where's the difference?
Am Sat, 12 Jul 2025 16:45:50 -0500 schrieb olcott:
On 7/12/2025 4:25 PM, joes wrote:
Am Sat, 12 Jul 2025 14:54:28 -0500 schrieb olcott:
On 7/12/2025 2:46 PM, joes wrote:
Am Sat, 12 Jul 2025 09:52:21 -0500 schrieb olcott:
On 7/12/2025 5:49 AM, joes wrote:
No you answered a similar question not the exact same question. CanContrary to you I can handle multiple steps at a time. I already*You jumped too many steps ahead*No, I get it. If HHH were a pure simulator it would nest copies of >>>>>> itself forever. A pure simulator running DDD as is would halt. IfWe have to break it down to its simpler steps or don't seem toHHH is not a pure simulator.That means that HHH reports itself as not being a decider. >>>>>>>>>>In other words you cannot understand that the behavior of DDD >>>>>>>>> simulated by a pure simulator HHH would be an infinite
repetition of its first line?
have any understanding at all.
(1) If HHH was a pure simulator it would endlessly
simulate the first instruction of DDD and never reach the >>>>>>> "return"
statement.
DDD called a pure simulator, HHH would correctly return "doesn't
halt". And HHH running DDD does so incorrectly. You confuse that
with the second case.
There is only this one step:
If HHH was a pure simulator would DDD simulated by HHH reach its own >>>>> "return" instruction?
I have another micro-step immediately after this one so if you jump
ahead we have to keep repeating this step over and over until we are >>>>> done with this step.
answered your question above. What's your next step?
DDD simulated by pure simulator HHH ever reach its "return"
instruction?
HHH NOT REACHING ITS OWN RETURN INSTRUCTION.
When I ask a YES or NO question say YES or NO don't freaking change the
words *AT ALL* and then answer a different question.
Richard has been using that dishonest ploy to dodge the point *FOR THREE F-ING YEARS*
On 7/13/2025 3:27 PM, Richard Damon wrote:
On 7/13/25 11:22 AM, olcott wrote:
On 7/13/2025 7:04 AM, Richard Damon wrote:
On 7/12/25 7:40 PM, olcott wrote:
On 7/12/2025 6:09 PM, Richard Damon wrote:
On 7/12/25 10:39 AM, olcott wrote:
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself >>>>>>>>>>>>> at all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up >>>>>>>>>>>> to the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdfAnd it also proves my claim that HHH did not simulate itself >>>>>>>>>>>> correctly *up to the end*.
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>
Exactly what is your professional programming experience? >>>>>>>>>>> I have 20 years in C++ and became a professional programmer >>>>>>>>>>> in 1986.
Irrelevant, even when it is more than your experience.
void DDD()
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to
simulate it correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics
of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
But thst pattern *ISN'T* a "non-halting" pattern, as it also
occurs in the direct execution of DDD, which you admit halts.
Thus, the claim of non-halting is just based on a lie.
Since you seem to have sufficient technical competence and
you know that halting is reaching a final halt state then
you know that when 0 to ∞ steps are correctly simulated by
some HHH according to the semantics of the C programming language
that no DDD simulated by any HHH ever reaches its final halt state.
Halting is the *PROGRAM* reaching a final stste when it is run.
This same thing can be applied to C functions reaching
their "return" instructions. The field of termination
analysis breaks programs down to their constituent parts.
When a called function cannot return this entails that
the caller will not stop running.
Right, but only for C functions that meet the definition of a
Computation Program, and thus INCLUDE all the code they call.
DDD correctly simulated by HHH cannot possibly
ever reach its own return instruction.
On 7/13/2025 4:05 PM, joes wrote:
Am Sun, 13 Jul 2025 13:53:00 -0500 schrieb olcott:
On 7/13/2025 1:32 PM, joes wrote:Have you heard of paraphrasing? What IS the difference now?
Am Sun, 13 Jul 2025 09:14:56 -0500 schrieb olcott:It must perfectly 100% specific about DDD simulated by pure simulator
On 7/13/2025 5:26 AM, joes wrote:I did answer in the affirmative. Where's the difference?
Am Sat, 12 Jul 2025 16:45:50 -0500 schrieb olcott:
On 7/12/2025 4:25 PM, joes wrote:
Am Sat, 12 Jul 2025 14:54:28 -0500 schrieb olcott:
On 7/12/2025 2:46 PM, joes wrote:
Am Sat, 12 Jul 2025 09:52:21 -0500 schrieb olcott:
On 7/12/2025 5:49 AM, joes wrote:
No you answered a similar question not the exact same question. CanContrary to you I can handle multiple steps at a time. I already*You jumped too many steps ahead*No, I get it. If HHH were a pure simulator it would nest copies of >>>>>>>> itself forever. A pure simulator running DDD as is would halt. If >>>>>>>> DDD called a pure simulator, HHH would correctly return "doesn't >>>>>>>> halt". And HHH running DDD does so incorrectly. You confuse that >>>>>>>> with the second case.We have to break it down to its simpler steps or don't seem to >>>>>>>>> have any understanding at all.HHH is not a pure simulator.That means that HHH reports itself as not being a decider. >>>>>>>>>>>>In other words you cannot understand that the behavior of DDD >>>>>>>>>>> simulated by a pure simulator HHH would be an infinite
repetition of its first line?
(1) If HHH was a pure simulator it would endlessly
simulate the first instruction of DDD and never reach the
"return"
statement.
There is only this one step:
If HHH was a pure simulator would DDD simulated by HHH reach its own >>>>>>> "return" instruction?
I have another micro-step immediately after this one so if you jump >>>>>>> ahead we have to keep repeating this step over and over until we are >>>>>>> done with this step.
answered your question above. What's your next step?
DDD simulated by pure simulator HHH ever reach its "return"
instruction?
HHH NOT REACHING ITS OWN RETURN INSTRUCTION.
When I ask a YES or NO question say YES or NO don't freaking change the
words *AT ALL* and then answer a different question.
Richard has been using that dishonest ploy to dodge the point *FOR THREE >>> F-ING YEARS*
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as to
be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a
description
of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to say what
you mean by an "x86 emulator". The name you give it is irrelevant
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny
pieces
out of it and dealing with those. The proof you claim to refute has no >>>> notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function returns true or
false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable
input for HHH. This is its counter example refuting the
claim that a universal halt decider can exist.
On 7/13/2025 3:34 PM, Richard Damon wrote:
On 7/13/25 11:31 AM, olcott wrote:
On 7/13/2025 1:06 AM, Fred. Zwarts wrote:
Op 12.jul.2025 om 16:39 schreef olcott:
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:There is no non-halting pattern.
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself at >>>>>>>>>>> all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to >>>>>>>>>> the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself >>>>>>>>>> correctly *up to the end*.
Exactly what is your professional programming experience?
I have 20 years in C++ and became a professional programmer
in 1986.
Irrelevant, even when it is more than your experience.
void DDD()
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to
simulate it correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics
of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
*When you keep ignoring my correction to your mistakes*
*then you never notice that you made any mistakes*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
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
It is a tautology that any input D to simulating termination
analyzer H that *would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
Right, but sinde the D is based on the H that you claim to give the
answer, and that H DOES abort, the claim doesn't work.
DDD correctly simulated by HHH cannot possibly
ever reach its own return instruction.
On 7/13/2025 3:56 PM, joes wrote:
Am Sun, 13 Jul 2025 15:43:31 -0500 schrieb olcott:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:No, every input is decidable,
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
An argument like this is at such a low level of abstraction as to >>>>>>>> be near valuless.
It is really weird that you are calling a 100% complete concrete >>>>>>> specification "a low level of abstraction". That HHH(DD) correctly >>>>>>> determines that DD simulated by HHH cannot possibly halt is a proven >>>>>>> fact.
A complete concrete specification would necessarily include a
description of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to say what >>>> you mean by an "x86 emulator". The name you give it is irrelevant
But my point was that rather than*Not at all there are two pieces*
sticking to the abstract nature of the proof, you're chipping tiny >>>>>> pieces out of it and dealing with those. The proof you claim to
refute has no notion of simulation, for example; it doesn't need it. >>>>
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function returns true >>>> or false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable input for HHH. >>> This is its counter example refuting the claim that a universal halt
decider can exist.
undecidable input *for HHH*
*for HHH*
*for HHH*
*for HHH*
*for HHH*
but not the whole problem by a single
decider. HHH isn't even a total decider.
On 7/13/2025 1:32 PM, joes wrote:
Am Sun, 13 Jul 2025 09:14:56 -0500 schrieb olcott:
On 7/13/2025 5:26 AM, joes wrote:I did answer in the affirmative. Where's the difference?
Am Sat, 12 Jul 2025 16:45:50 -0500 schrieb olcott:
On 7/12/2025 4:25 PM, joes wrote:
Am Sat, 12 Jul 2025 14:54:28 -0500 schrieb olcott:
On 7/12/2025 2:46 PM, joes wrote:
Am Sat, 12 Jul 2025 09:52:21 -0500 schrieb olcott:
On 7/12/2025 5:49 AM, joes wrote:
No you answered a similar question not the exact same question. Can DDDContrary to you I can handle multiple steps at a time. I already*You jumped too many steps ahead*No, I get it. If HHH were a pure simulator it would nest copies of >>>>>> itself forever. A pure simulator running DDD as is would halt. If DDD >>>>>> called a pure simulator, HHH would correctly return "doesn't halt". >>>>>> And HHH running DDD does so incorrectly. You confuse that with the >>>>>> second case.We have to break it down to its simpler steps or don't seem to have >>>>>>> any understanding at all.HHH is not a pure simulator.That means that HHH reports itself as not being a decider. >>>>>>>>>>In other words you cannot understand that the behavior of DDD >>>>>>>>> simulated by a pure simulator HHH would be an infinite repetition >>>>>>>>> of its first line?
(1) If HHH was a pure simulator it would endlessly
simulate the first instruction of DDD and never reach the
"return"
statement.
There is only this one step:
If HHH was a pure simulator would DDD simulated by HHH reach its own >>>>> "return" instruction?
I have another micro-step immediately after this one so if you jump
ahead we have to keep repeating this step over and over until we are >>>>> done with this step.
answered your question above. What's your next step?
simulated by pure simulator HHH ever reach its "return" instruction?
When HHH is a pure simulator then DDD correctly
simulated by HHH cannot possibly reach its own
"return" instruction.
When HHH is changed so that it only simulates
N instructions of DDD then this DDD still never
reaches its "return" instruction no matter what
the value of N is.
On 7/13/2025 8:31 PM, Richard Damon wrote:We have pointed out many times that this is an incomplete input. It
On 7/13/25 5:14 PM, olcott wrote:
On 7/13/2025 4:05 PM, joes wrote:
Am Sun, 13 Jul 2025 13:53:00 -0500 schrieb olcott:
On 7/13/2025 1:32 PM, joes wrote:Have you heard of paraphrasing? What IS the difference now?
Am Sun, 13 Jul 2025 09:14:56 -0500 schrieb olcott:It must perfectly 100% specific about DDD simulated by pure simulator >>>>> HHH NOT REACHING ITS OWN RETURN INSTRUCTION.
On 7/13/2025 5:26 AM, joes wrote:I did answer in the affirmative. Where's the difference?
Am Sat, 12 Jul 2025 16:45:50 -0500 schrieb olcott:
On 7/12/2025 4:25 PM, joes wrote:
Am Sat, 12 Jul 2025 14:54:28 -0500 schrieb olcott:
On 7/12/2025 2:46 PM, joes wrote:
Am Sat, 12 Jul 2025 09:52:21 -0500 schrieb olcott:
On 7/12/2025 5:49 AM, joes wrote:
No you answered a similar question not the exact same question. Can >>>>>>> DDD simulated by pure simulator HHH ever reach its "return"Contrary to you I can handle multiple steps at a time. I already >>>>>>>> answered your question above. What's your next step?*You jumped too many steps ahead*No, I get it. If HHH were a pure simulator it would nestWe have to break it down to its simpler steps or don't seem to >>>>>>>>>>> have any understanding at all.HHH is not a pure simulator.That means that HHH reports itself as not being a decider. >>>>>>>>>>>>>>In other words you cannot understand that the behavior of DDD >>>>>>>>>>>>> simulated by a pure simulator HHH would be an infinite >>>>>>>>>>>>> repetition of its first line?
(1) If HHH was a pure simulator it would endlessly
simulate the first instruction of DDD and never >>>>>>>>>>> reach the
"return"
statement.
copies of
itself forever. A pure simulator running DDD as is would halt. If >>>>>>>>>> DDD called a pure simulator, HHH would correctly return "doesn't >>>>>>>>>> halt". And HHH running DDD does so incorrectly. You confuse that >>>>>>>>>> with the second case.
There is only this one step:
If HHH was a pure simulator would DDD simulated by HHH reach >>>>>>>>> its own
"return" instruction?
I have another micro-step immediately after this one so if you >>>>>>>>> jump
ahead we have to keep repeating this step over and over until >>>>>>>>> we are
done with this step.
instruction?
When I ask a YES or NO question say YES or NO don't freaking change
the
words *AT ALL* and then answer a different question.
Richard has been using that dishonest ploy to dodge the point *FOR
THREE
F-ING YEARS*
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
Wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
On 7/13/2025 1:06 AM, Fred. Zwarts wrote:
Op 12.jul.2025 om 16:39 schreef olcott:
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:There is no non-halting pattern.
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself at all. >>>>>>>>As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to >>>>>>>> the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself
correctly *up to the end*.
Exactly what is your professional programming experience?
I have 20 years in C++ and became a professional programmer
in 1986.
Irrelevant, even when it is more than your experience.
void DDD()
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to simulate
it correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics
of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
*When you keep ignoring my correction to your mistakes*
*then you never notice that you made any mistakes*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
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
It is a tautology that any input D to simulating termination
analyzer H that *would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
It is the failure of HHH to detect a non-existing pattern.
The semantics of the x86 language determine a halting pattern, as is
proven by many world-class simulators and even by direct execution of
exactly the same input. That HHH does not see that, is a failure,
proving that simulation is not the right tool for such input.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD emulated by HHH according to the semantics
of the x86 language cannot possibly get past
its own machine address [0000219a] whether HHH
aborts its simulation or not.
That you don't understand this is your own lack
of understanding NOT ANY ACTUAL REBUTTAL AT ALL.
On 7/13/2025 8:28 PM, Richard Damon wrote:
On 7/13/25 5:17 PM, olcott wrote:
On 7/13/2025 3:27 PM, Richard Damon wrote:
On 7/13/25 11:22 AM, olcott wrote:
On 7/13/2025 7:04 AM, Richard Damon wrote:
On 7/12/25 7:40 PM, olcott wrote:
On 7/12/2025 6:09 PM, Richard Damon wrote:
On 7/12/25 10:39 AM, olcott wrote:
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself >>>>>>>>>>>>>>> at all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly >>>>>>>>>>>>>> *up to the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdfAnd it also proves my claim that HHH did not simulate >>>>>>>>>>>>>> itself correctly *up to the end*.
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>
Exactly what is your professional programming experience? >>>>>>>>>>>>> I have 20 years in C++ and became a professional programmer >>>>>>>>>>>>> in 1986.
Irrelevant, even when it is more than your experience.
void DDD()
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to >>>>>>>>>> simulate it correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics
of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
But thst pattern *ISN'T* a "non-halting" pattern, as it also
occurs in the direct execution of DDD, which you admit halts.
Thus, the claim of non-halting is just based on a lie.
Since you seem to have sufficient technical competence and
you know that halting is reaching a final halt state then
you know that when 0 to ∞ steps are correctly simulated by
some HHH according to the semantics of the C programming language >>>>>>> that no DDD simulated by any HHH ever reaches its final halt state. >>>>>>>
Halting is the *PROGRAM* reaching a final stste when it is run.
This same thing can be applied to C functions reaching
their "return" instructions. The field of termination
analysis breaks programs down to their constituent parts.
When a called function cannot return this entails that
the caller will not stop running.
Right, but only for C functions that meet the definition of a
Computation Program, and thus INCLUDE all the code they call.
DDD correctly simulated by HHH cannot possibly
ever reach its own return instruction.
So?
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "return" statement.
DDD is this exact machine code and each HHH is
at machine address 000015d2:
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
On 7/13/2025 8:33 PM, Richard Damon wrote:
On 7/13/25 4:43 PM, olcott wrote:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as >>>>>>>> to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a
description
of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to say what >>>> you mean by an "x86 emulator". The name you give it is irrelevant
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny >>>>>> pieces
out of it and dealing with those. The proof you claim to refute
has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function returns
true or
false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable
input for HHH. This is its counter example refuting the
claim that a universal halt decider can exist.
But since your DD by your own admission is a category error for a halt
decider, as you have specifically stated it isn't a program as the
input doesn't include the code of the specific HHH that it calls, you
proof is just invalid.
Sorry, all you proved is that you don't know what you are talking about.
That you keep trying to get away with refuting
this easily verified fact says a about about you
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
On 7/13/2025 8:34 PM, Richard Damon wrote:
On 7/13/25 5:13 PM, olcott wrote:
On 7/13/2025 3:56 PM, joes wrote:
Am Sun, 13 Jul 2025 15:43:31 -0500 schrieb olcott:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:No, every input is decidable,
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
An argument like this is at such a low level of abstraction as to >>>>>>>>>> be near valuless.
It is really weird that you are calling a 100% complete concrete >>>>>>>>> specification "a low level of abstraction". That HHH(DD) correctly >>>>>>>>> determines that DD simulated by HHH cannot possibly halt is a >>>>>>>>> proven
fact.
A complete concrete specification would necessarily include a
description of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to say >>>>>> what
you mean by an "x86 emulator". The name you give it is irrelevant >>>>>>
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny >>>>>>>> pieces out of it and dealing with those. The proof you claim to >>>>>>>> refute has no notion of simulation, for example; it doesn't need >>>>>>>> it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function returns
true
or false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable input for
HHH.
This is its counter example refuting the claim that a universal halt >>>>> decider can exist.
undecidable input *for HHH*
No such term.
PROBLEMS are undecidable.
Inputs are either correct or incorrect decided.
There is no existing term for the meaning that
I must express. *undecidable input* was as close
as I could get with existing terms.
Any TM decider input D to decider H such that transitioning
to an accept state H.Y or a reject state H.N are both the
wrong answer.
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:Each program has either halting or non-halting behaviour. If this is undecidable input for HHH, the only interpretation is: HHH is not the
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as to
be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a
description
of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to say what
you mean by an "x86 emulator". The name you give it is irrelevant
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny
pieces
out of it and dealing with those. The proof you claim to refute has no >>>> notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function returns true or
false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable
input for HHH. This is its counter example refuting the
claim that a universal halt decider can exist.
On 7/13/2025 8:31 PM, Richard Damon wrote:
On 7/13/25 5:14 PM, olcott wrote:
On 7/13/2025 4:05 PM, joes wrote:
Am Sun, 13 Jul 2025 13:53:00 -0500 schrieb olcott:
On 7/13/2025 1:32 PM, joes wrote:Have you heard of paraphrasing? What IS the difference now?
Am Sun, 13 Jul 2025 09:14:56 -0500 schrieb olcott:It must perfectly 100% specific about DDD simulated by pure simulator >>>>> HHH NOT REACHING ITS OWN RETURN INSTRUCTION.
On 7/13/2025 5:26 AM, joes wrote:I did answer in the affirmative. Where's the difference?
Am Sat, 12 Jul 2025 16:45:50 -0500 schrieb olcott:
On 7/12/2025 4:25 PM, joes wrote:
Am Sat, 12 Jul 2025 14:54:28 -0500 schrieb olcott:
On 7/12/2025 2:46 PM, joes wrote:
Am Sat, 12 Jul 2025 09:52:21 -0500 schrieb olcott:
On 7/12/2025 5:49 AM, joes wrote:
No you answered a similar question not the exact same question. Can >>>>>>> DDD simulated by pure simulator HHH ever reach its "return"Contrary to you I can handle multiple steps at a time. I already >>>>>>>> answered your question above. What's your next step?*You jumped too many steps ahead*No, I get it. If HHH were a pure simulator it would nestWe have to break it down to its simpler steps or don't seem to >>>>>>>>>>> have any understanding at all.HHH is not a pure simulator.That means that HHH reports itself as not being a decider. >>>>>>>>>>>>>>In other words you cannot understand that the behavior of DDD >>>>>>>>>>>>> simulated by a pure simulator HHH would be an infinite >>>>>>>>>>>>> repetition of its first line?
(1) If HHH was a pure simulator it would endlessly
simulate the first instruction of DDD and never >>>>>>>>>>> reach the
"return"
statement.
copies of
itself forever. A pure simulator running DDD as is would halt. If >>>>>>>>>> DDD called a pure simulator, HHH would correctly return "doesn't >>>>>>>>>> halt". And HHH running DDD does so incorrectly. You confuse that >>>>>>>>>> with the second case.
There is only this one step:
If HHH was a pure simulator would DDD simulated by HHH reach >>>>>>>>> its own
"return" instruction?
I have another micro-step immediately after this one so if you >>>>>>>>> jump
ahead we have to keep repeating this step over and over until >>>>>>>>> we are
done with this step.
instruction?
When I ask a YES or NO question say YES or NO don't freaking change
the
words *AT ALL* and then answer a different question.
Richard has been using that dishonest ploy to dodge the point *FOR
THREE
F-ING YEARS*
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
Wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
*Whenever I challenge you to show the details of how I am wrong*
just like Trump's TACO: Richard always chickens out.
On 7/13/2025 8:33 PM, Richard Damon wrote:
On 7/13/25 4:43 PM, olcott wrote:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as >>>>>>>> to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a
description
of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to say what >>>> you mean by an "x86 emulator". The name you give it is irrelevant
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny >>>>>> pieces
out of it and dealing with those. The proof you claim to refute
has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function returns
true or
false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable
input for HHH. This is its counter example refuting the
claim that a universal halt decider can exist.
But since your DD by your own admission is a category error for a halt
decider, as you have specifically stated it isn't a program as the
input doesn't include the code of the specific HHH that it calls, you
proof is just invalid.
Sorry, all you proved is that you don't know what you are talking about.
That you keep trying to get away with refuting
this easily verified fact says a about about you
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
On 7/13/2025 8:34 PM, Richard Damon wrote:
On 7/13/25 5:13 PM, olcott wrote:
On 7/13/2025 3:56 PM, joes wrote:
Am Sun, 13 Jul 2025 15:43:31 -0500 schrieb olcott:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:No, every input is decidable,
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
An argument like this is at such a low level of abstraction as to >>>>>>>>>> be near valuless.
It is really weird that you are calling a 100% complete concrete >>>>>>>>> specification "a low level of abstraction". That HHH(DD) correctly >>>>>>>>> determines that DD simulated by HHH cannot possibly halt is a >>>>>>>>> proven
fact.
A complete concrete specification would necessarily include a
description of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to say >>>>>> what
you mean by an "x86 emulator". The name you give it is irrelevant >>>>>>
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny >>>>>>>> pieces out of it and dealing with those. The proof you claim to >>>>>>>> refute has no notion of simulation, for example; it doesn't need >>>>>>>> it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function returns
true
or false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable input for
HHH.
This is its counter example refuting the claim that a universal halt >>>>> decider can exist.
undecidable input *for HHH*
No such term.
PROBLEMS are undecidable.
Inputs are either correct or incorrect decided.
There is no existing term for the meaning that
I must express. *undecidable input* was as close
as I could get with existing terms.
Any TM decider input D to decider H such that transitioning
to an accept state H.Y or a reject state H.N are both the
wrong answer.
On 7/13/2025 8:28 PM, Richard Damon wrote:
On 7/13/25 5:17 PM, olcott wrote:
On 7/13/2025 3:27 PM, Richard Damon wrote:
On 7/13/25 11:22 AM, olcott wrote:
On 7/13/2025 7:04 AM, Richard Damon wrote:
On 7/12/25 7:40 PM, olcott wrote:
On 7/12/2025 6:09 PM, Richard Damon wrote:
On 7/12/25 10:39 AM, olcott wrote:
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself >>>>>>>>>>>>>>> at all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly >>>>>>>>>>>>>> *up to the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdfAnd it also proves my claim that HHH did not simulate >>>>>>>>>>>>>> itself correctly *up to the end*.
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>
Exactly what is your professional programming experience? >>>>>>>>>>>>> I have 20 years in C++ and became a professional programmer >>>>>>>>>>>>> in 1986.
Irrelevant, even when it is more than your experience.
void DDD()
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to >>>>>>>>>> simulate it correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics
of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
But thst pattern *ISN'T* a "non-halting" pattern, as it also
occurs in the direct execution of DDD, which you admit halts.
Thus, the claim of non-halting is just based on a lie.
Since you seem to have sufficient technical competence and
you know that halting is reaching a final halt state then
you know that when 0 to ∞ steps are correctly simulated by
some HHH according to the semantics of the C programming language >>>>>>> that no DDD simulated by any HHH ever reaches its final halt state. >>>>>>>
Halting is the *PROGRAM* reaching a final stste when it is run.
This same thing can be applied to C functions reaching
their "return" instructions. The field of termination
analysis breaks programs down to their constituent parts.
When a called function cannot return this entails that
the caller will not stop running.
Right, but only for C functions that meet the definition of a
Computation Program, and thus INCLUDE all the code they call.
DDD correctly simulated by HHH cannot possibly
ever reach its own return instruction.
So?
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "return" statement.
DDD is this exact machine code and each HHH is
at machine address 000015d2:
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
On 7/12/25 8:48 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 08:36:55 -0400, Richard Damon wrote:
On 7/12/25 8:30 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 08:20:59 -0400, Richard Damon wrote:
On 7/12/25 12:42 AM, olcott wrote:
On 7/11/2025 6:34 PM, Richard Damon wrote:
On 7/10/25 10:30 AM, olcott wrote:What of kind of systems did you work with?
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:So? I started programming for pay in 1974, where as an
Op 09.jul.2025 om 14:54 schreef olcott:>>Exactly what is your professional programming experience? I have >>>>>>>> 20 years in C++ and became a professional programmer in 1986.
One of these "errors" was that HHH cannot simulate itself at >>>>>>>>>> all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to >>>>>>>>> the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf Is the full >>>>>>>>>> execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself >>>>>>>>> correctly *up to the end*.
undergraduate I was using my programming from High School to build >>>>>>> Data Analsys programs, an inter-computer link to make a computer >>>>>>> with a vector graphics dispaly usable by the main frame, and the >>>>>>> OS and data collection programs for a laboratory.
In 1982, with my MASTERS degree, I was employed to write programs, >>>>>>> as well as design hardware for an industrial firm.
It seems I have many years over you, and it sounds like I may have >>>>>>> well written more programs than you have.
I started using C from K&R in the late 70s and C++ using Cfront in >>>>>>> the mid 80s. (so like 40 years of experience).
I programmed AutoCAD in C++ creating new architectural engineering >>>>>> automations. This was mostly analytical geometry. I worked in C++
and some C for the last 22 years. I worked on NPOESS
https://en.wikipedia.org/wiki/NPOESS for Northrup Grumman
In otherwords, you let an existing program do most of the work, and
you added some fonctionality to it.
As to NPOESS, just "working on it" doesn't give much idea of your
responsibilities, and tha fact that it was a FAILED system, scrubbed >>>>> due to progtram issues doesn't say much for what you can do.
It seems that in all your work, you might never have produced an
actual "program", only pieces of systems, which explains why you
don't understand what a "program" actually is.
Most of my work has been in embedded system, where I built the
hardware around a processor for some function, and then fully
programmed the processor from the ground up to complete the product. >>>>> I also wrote PC side support for control of the embedded
application.
As part of this, I have produced a large library of support
functions to allow the building of similar programs by others, which >>>>> has become the basis for much of the work produced at the company I
work for.
I will note that I am STILL active in the profession, and now spend
part of my time training others in the company to improve their
skills, while it seems you are no longer at work, and I doubt you
get many calls asking for advice about how to do things.
Your personality really is quite obnoxious isn't it, Damon?
/Flibble
HE asked the question.
HE claims to be an expert, with no actual credentials and calls me the
one who doesn't know what I am doing, even though I am much better
trained then him.
You and He are the "obnoxious" ones, that need to use ad hominim
attacks as you have no factual grounds to refute the errors pointed
out.
You make more ad hominum attacks than anyone else on here, Damon.
/Flibble
Really? When have I ever said someone was wrong just because they were
stupid or some other aspect of them.
I have always pointed out the factual and logical reason they were
wrong, and then pointed out that the repeated saying of that error shows
they are stupid.
I guess you don't know what ad hominum means, perhaps because you are
just too stupid. (Note, that statement is not ad hominum, as I don't use
your stupidity as the arguement for your error, but that the error demonstrates the stupidity).
On 7/14/2025 6:26 AM, Richard Damon wrote:
On 7/13/25 10:39 PM, olcott wrote:
On 7/13/2025 8:31 PM, Richard Damon wrote:
On 7/13/25 5:14 PM, olcott wrote:
On 7/13/2025 4:05 PM, joes wrote:
Am Sun, 13 Jul 2025 13:53:00 -0500 schrieb olcott:
On 7/13/2025 1:32 PM, joes wrote:Have you heard of paraphrasing? What IS the difference now?
Am Sun, 13 Jul 2025 09:14:56 -0500 schrieb olcott:It must perfectly 100% specific about DDD simulated by pure
On 7/13/2025 5:26 AM, joes wrote:I did answer in the affirmative. Where's the difference?
Am Sat, 12 Jul 2025 16:45:50 -0500 schrieb olcott:
On 7/12/2025 4:25 PM, joes wrote:
Am Sat, 12 Jul 2025 14:54:28 -0500 schrieb olcott:
On 7/12/2025 2:46 PM, joes wrote:
Am Sat, 12 Jul 2025 09:52:21 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/12/2025 5:49 AM, joes wrote:
No you answered a similar question not the exact same question. >>>>>>>>> CanContrary to you I can handle multiple steps at a time. I already >>>>>>>>>> answered your question above. What's your next step?*You jumped too many steps ahead*No, I get it. If HHH were a pure simulator it would nest >>>>>>>>>>>> copies ofWe have to break it down to its simpler steps or don't seem to >>>>>>>>>>>>> have any understanding at all.HHH is not a pure simulator.That means that HHH reports itself as not being a decider. >>>>>>>>>>>>>>>>In other words you cannot understand that the behavior of >>>>>>>>>>>>>>> DDD
simulated by a pure simulator HHH would be an infinite >>>>>>>>>>>>>>> repetition of its first line?
(1) If HHH was a pure simulator it would endlessly
simulate the first instruction of DDD and never >>>>>>>>>>>>> reach the
"return"
statement.
itself forever. A pure simulator running DDD as is would >>>>>>>>>>>> halt. If
DDD called a pure simulator, HHH would correctly return >>>>>>>>>>>> "doesn't
halt". And HHH running DDD does so incorrectly. You confuse >>>>>>>>>>>> that
with the second case.
There is only this one step:
If HHH was a pure simulator would DDD simulated by HHH reach >>>>>>>>>>> its own
"return" instruction?
I have another micro-step immediately after this one so if >>>>>>>>>>> you jump
ahead we have to keep repeating this step over and over until >>>>>>>>>>> we are
done with this step.
DDD simulated by pure simulator HHH ever reach its "return"
instruction?
simulator
HHH NOT REACHING ITS OWN RETURN INSTRUCTION.
When I ask a YES or NO question say YES or NO don't freaking
change the
words *AT ALL* and then answer a different question.
Richard has been using that dishonest ploy to dodge the point
*FOR THREE
F-ING YEARS*
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
Wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
*Whenever I challenge you to show the details of how I am wrong*
just like Trump's TACO: Richard always chickens out.
Look at the trace of HHH1.
Changing the subject from DDD emulated by HHH
to DDD emulated by HHH1 is deception.
What are the exact steps of DDD emulated by HHH
such that this DDD emulated by HHH reaches its
"ret" instruction?
On 7/14/2025 6:23 AM, Richard Damon wrote:
On 7/13/25 10:36 PM, olcott wrote:
On 7/13/2025 8:28 PM, Richard Damon wrote:
On 7/13/25 5:17 PM, olcott wrote:
On 7/13/2025 3:27 PM, Richard Damon wrote:
On 7/13/25 11:22 AM, olcott wrote:
On 7/13/2025 7:04 AM, Richard Damon wrote:
On 7/12/25 7:40 PM, olcott wrote:
On 7/12/2025 6:09 PM, Richard Damon wrote:
On 7/12/25 10:39 AM, olcott wrote:
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:void DDD()
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate >>>>>>>>>>>>>>>>> itself at all.
As usual you twist the words of your reviewers. >>>>>>>>>>>>>>>> The claim was that no HHH can simulate itself correctly >>>>>>>>>>>>>>>> *up to the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >>>>>>>>>>>>>>>>> Is the full execution trace ofAnd it also proves my claim that HHH did not simulate >>>>>>>>>>>>>>>> itself correctly *up to the end*.
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>>>
Exactly what is your professional programming experience? >>>>>>>>>>>>>>> I have 20 years in C++ and became a professional programmer >>>>>>>>>>>>>>> in 1986.
Irrelevant, even when it is more than your experience. >>>>>>>>>>>>>
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to >>>>>>>>>>>> simulate it correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics
of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
But thst pattern *ISN'T* a "non-halting" pattern, as it also >>>>>>>>>> occurs in the direct execution of DDD, which you admit halts. >>>>>>>>>>
Thus, the claim of non-halting is just based on a lie.
Since you seem to have sufficient technical competence and
you know that halting is reaching a final halt state then
you know that when 0 to ∞ steps are correctly simulated by >>>>>>>>> some HHH according to the semantics of the C programming language >>>>>>>>> that no DDD simulated by any HHH ever reaches its final halt >>>>>>>>> state.
Halting is the *PROGRAM* reaching a final stste when it is run. >>>>>>>>
This same thing can be applied to C functions reaching
their "return" instructions. The field of termination
analysis breaks programs down to their constituent parts.
When a called function cannot return this entails that
the caller will not stop running.
Right, but only for C functions that meet the definition of a
Computation Program, and thus INCLUDE all the code they call.
DDD correctly simulated by HHH cannot possibly
ever reach its own return instruction.
So?
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "return" statement.
SO, you believe in Strawmen and the Truth Fairy.
When all of the elements of a set of HHH/DDD pairs
have the same property DDD does not reach its final
halt state, then we correctly conclude that no DDD
simulated by any HHH reaches its final halt state
as a tautology.
That you are trying to get away for saying that a
tautology is the strawman error is a lame attempt
at deception.
On Sat, 12 Jul 2025 19:13:18 -0400, Richard Damon wrote:
On 7/12/25 8:48 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 08:36:55 -0400, Richard Damon wrote:
On 7/12/25 8:30 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 08:20:59 -0400, Richard Damon wrote:
On 7/12/25 12:42 AM, olcott wrote:
On 7/11/2025 6:34 PM, Richard Damon wrote:
On 7/10/25 10:30 AM, olcott wrote:What of kind of systems did you work with?
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:So? I started programming for pay in 1974, where as an
Op 09.jul.2025 om 14:54 schreef olcott:>>Exactly what is your professional programming experience? I have >>>>>>>>> 20 years in C++ and became a professional programmer in 1986. >>>>>>>>>
One of these "errors" was that HHH cannot simulate itself at >>>>>>>>>>> all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to >>>>>>>>>> the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf Is the full >>>>>>>>>>> execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself >>>>>>>>>> correctly *up to the end*.
undergraduate I was using my programming from High School to build >>>>>>>> Data Analsys programs, an inter-computer link to make a computer >>>>>>>> with a vector graphics dispaly usable by the main frame, and the >>>>>>>> OS and data collection programs for a laboratory.
In 1982, with my MASTERS degree, I was employed to write programs, >>>>>>>> as well as design hardware for an industrial firm.
It seems I have many years over you, and it sounds like I may have >>>>>>>> well written more programs than you have.
I started using C from K&R in the late 70s and C++ using Cfront in >>>>>>>> the mid 80s. (so like 40 years of experience).
I programmed AutoCAD in C++ creating new architectural engineering >>>>>>> automations. This was mostly analytical geometry. I worked in C++ >>>>>>> and some C for the last 22 years. I worked on NPOESS
https://en.wikipedia.org/wiki/NPOESS for Northrup Grumman
In otherwords, you let an existing program do most of the work, and >>>>>> you added some fonctionality to it.
As to NPOESS, just "working on it" doesn't give much idea of your
responsibilities, and tha fact that it was a FAILED system, scrubbed >>>>>> due to progtram issues doesn't say much for what you can do.
It seems that in all your work, you might never have produced an
actual "program", only pieces of systems, which explains why you
don't understand what a "program" actually is.
Most of my work has been in embedded system, where I built the
hardware around a processor for some function, and then fully
programmed the processor from the ground up to complete the product. >>>>>> I also wrote PC side support for control of the embedded
application.
As part of this, I have produced a large library of support
functions to allow the building of similar programs by others, which >>>>>> has become the basis for much of the work produced at the company I >>>>>> work for.
I will note that I am STILL active in the profession, and now spend >>>>>> part of my time training others in the company to improve their
skills, while it seems you are no longer at work, and I doubt you
get many calls asking for advice about how to do things.
Your personality really is quite obnoxious isn't it, Damon?
/Flibble
HE asked the question.
HE claims to be an expert, with no actual credentials and calls me the >>>> one who doesn't know what I am doing, even though I am much better
trained then him.
You and He are the "obnoxious" ones, that need to use ad hominim
attacks as you have no factual grounds to refute the errors pointed
out.
You make more ad hominum attacks than anyone else on here, Damon.
/Flibble
Really? When have I ever said someone was wrong just because they were
stupid or some other aspect of them.
I have always pointed out the factual and logical reason they were
wrong, and then pointed out that the repeated saying of that error shows
they are stupid.
I guess you don't know what ad hominum means, perhaps because you are
just too stupid. (Note, that statement is not ad hominum, as I don't use
your stupidity as the arguement for your error, but that the error
demonstrates the stupidity).
Ad hominem (often misspelled as "ad hominum" in the statement) is a
logical fallacy where an argument is rebutted by attacking the character, motive, or other attribute of the person making it, rather than addressing the substance of the argument itself. It's essentially dismissing a claim based on who is saying it, not on its merits.
In the described approach—pointing out factual and logical flaws in someone's claim first, then concluding that repeated errors indicate stupidity—that sequence isn't inherently ad hominem. The core rebuttal targets the argument's content (facts and logic), and the insult follows
as a separate judgment on the person's pattern of behavior. Insults alone don't constitute ad hominem if they're not used as the basis for rejecting the argument. For example:
- Ad hominem: "Your point about climate change is wrong because you're an idiot."
- Not ad hominem: "Your point about climate change is wrong because the
data shows X, Y, and Z are inaccurate—and repeating such basic errors suggests you're not thinking critically."
However, the specific example given ("I guess you don't know what ad
hominum means, perhaps because you are just too stupid") veers closer to
ad hominem territory. It asserts an error (not knowing the meaning)
without providing any factual or logical explanation for why the understanding is incorrect. Instead, it immediately attributes the
supposed error to stupidity as the explanatory cause. This implies the dismissal is rooted in the personal attack rather than a substantive refutation. The parenthetical note claims the error demonstrates the stupidity, but the statement doesn't actually demonstrate or explain the error—it assumes it and jumps to the insult. To avoid ad hominem entirely, the logical rebuttal should come first and stand on its own, with any personal commentary clearly separated and not presented as the reason for
the disagreement.
If the goal is productive discussion, avoiding insults altogether is
usually better, as they can escalate conflicts without adding value. If
this is part of a broader conversation, providing the full context could
help refine the analysis.
On 7/14/2025 6:37 AM, Richard Damon wrote:
On 7/13/25 10:46 PM, olcott wrote:Reaching a final halt state <is> the definition of halting.
On 7/13/2025 8:33 PM, Richard Damon wrote:
On 7/13/25 4:43 PM, olcott wrote:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as >>>>>>>>>> to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a
description
of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to say >>>>>> what
you mean by an "x86 emulator". The name you give it is irrelevant >>>>>>
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping
tiny pieces
out of it and dealing with those. The proof you claim to refute >>>>>>>> has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function returns
true or
false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable
input for HHH. This is its counter example refuting the
claim that a universal halt decider can exist.
But since your DD by your own admission is a category error for a
halt decider, as you have specifically stated it isn't a program as
the input doesn't include the code of the specific HHH that it
calls, you proof is just invalid.
Sorry, all you proved is that you don't know what you are talking
about.
That you keep trying to get away with refuting
this easily verified fact says a about about you
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
Which isn't the definition of Non-Halting,
On 7/14/2025 8:54 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 19:13:18 -0400, Richard Damon wrote:
On 7/12/25 8:48 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 08:36:55 -0400, Richard Damon wrote:
On 7/12/25 8:30 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 08:20:59 -0400, Richard Damon wrote:
On 7/12/25 12:42 AM, olcott wrote:
On 7/11/2025 6:34 PM, Richard Damon wrote:
On 7/10/25 10:30 AM, olcott wrote:What of kind of systems did you work with?
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:So? I started programming for pay in 1974, where as an
Op 09.jul.2025 om 14:54 schreef olcott:>>Exactly what is your professional programming experience? I have >>>>>>>>>> 20 years in C++ and became a professional programmer in 1986. >>>>>>>>>>
One of these "errors" was that HHH cannot simulate itself at >>>>>>>>>>>> all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to >>>>>>>>>>> the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf Is the full >>>>>>>>>>>> execution trace ofAnd it also proves my claim that HHH did not simulate itself >>>>>>>>>>> correctly *up to the end*.
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>
undergraduate I was using my programming from High School to build >>>>>>>>> Data Analsys programs, an inter-computer link to make a computer >>>>>>>>> with a vector graphics dispaly usable by the main frame, and the >>>>>>>>> OS and data collection programs for a laboratory.
In 1982, with my MASTERS degree, I was employed to write programs, >>>>>>>>> as well as design hardware for an industrial firm.
It seems I have many years over you, and it sounds like I may have >>>>>>>>> well written more programs than you have.
I started using C from K&R in the late 70s and C++ using Cfront in >>>>>>>>> the mid 80s. (so like 40 years of experience).
I programmed AutoCAD in C++ creating new architectural engineering >>>>>>>> automations. This was mostly analytical geometry. I worked in C++ >>>>>>>> and some C for the last 22 years. I worked on NPOESS
https://en.wikipedia.org/wiki/NPOESS for Northrup Grumman
In otherwords, you let an existing program do most of the work, and >>>>>>> you added some fonctionality to it.
As to NPOESS, just "working on it" doesn't give much idea of your >>>>>>> responsibilities, and tha fact that it was a FAILED system, scrubbed >>>>>>> due to progtram issues doesn't say much for what you can do.
It seems that in all your work, you might never have produced an >>>>>>> actual "program", only pieces of systems, which explains why you >>>>>>> don't understand what a "program" actually is.
Most of my work has been in embedded system, where I built the
hardware around a processor for some function, and then fully
programmed the processor from the ground up to complete the product. >>>>>>> I also wrote PC side support for control of the embedded
application.
As part of this, I have produced a large library of support
functions to allow the building of similar programs by others, which >>>>>>> has become the basis for much of the work produced at the company I >>>>>>> work for.
I will note that I am STILL active in the profession, and now spend >>>>>>> part of my time training others in the company to improve their
skills, while it seems you are no longer at work, and I doubt you >>>>>>> get many calls asking for advice about how to do things.
Your personality really is quite obnoxious isn't it, Damon?
/Flibble
HE asked the question.
HE claims to be an expert, with no actual credentials and calls me the >>>>> one who doesn't know what I am doing, even though I am much better
trained then him.
You and He are the "obnoxious" ones, that need to use ad hominim
attacks as you have no factual grounds to refute the errors pointed
out.
You make more ad hominum attacks than anyone else on here, Damon.
/Flibble
Really? When have I ever said someone was wrong just because they were
stupid or some other aspect of them.
I have always pointed out the factual and logical reason they were
wrong, and then pointed out that the repeated saying of that error shows >>> they are stupid.
I guess you don't know what ad hominum means, perhaps because you are
just too stupid. (Note, that statement is not ad hominum, as I don't use >>> your stupidity as the arguement for your error, but that the error
demonstrates the stupidity).
Ad hominem (often misspelled as "ad hominum" in the statement) is a
logical fallacy where an argument is rebutted by attacking the character,
motive, or other attribute of the person making it, rather than
addressing
the substance of the argument itself. It's essentially dismissing a claim
based on who is saying it, not on its merits.
In the described approach—pointing out factual and logical flaws in
someone's claim first, then concluding that repeated errors indicate
stupidity—that sequence isn't inherently ad hominem. The core rebuttal
targets the argument's content (facts and logic), and the insult follows
as a separate judgment on the person's pattern of behavior. Insults alone
don't constitute ad hominem if they're not used as the basis for
rejecting
the argument. For example:
- Ad hominem: "Your point about climate change is wrong because you're an
idiot."
- Not ad hominem: "Your point about climate change is wrong because the
data shows X, Y, and Z are inaccurate—and repeating such basic errors
suggests you're not thinking critically."
However, the specific example given ("I guess you don't know what ad
hominum means, perhaps because you are just too stupid") veers closer to
ad hominem territory. It asserts an error (not knowing the meaning)
without providing any factual or logical explanation for why the
understanding is incorrect. Instead, it immediately attributes the
supposed error to stupidity as the explanatory cause. This implies the
dismissal is rooted in the personal attack rather than a substantive
refutation. The parenthetical note claims the error demonstrates the
stupidity, but the statement doesn't actually demonstrate or explain the
error—it assumes it and jumps to the insult. To avoid ad hominem
entirely,
the logical rebuttal should come first and stand on its own, with any
personal commentary clearly separated and not presented as the reason for
the disagreement.
If the goal is productive discussion, avoiding insults altogether is
usually better, as they can escalate conflicts without adding value. If
this is part of a broader conversation, providing the full context could
help refine the analysis.
He is a troll not interested in an honest dialogue.
On 7/14/2025 4:51 AM, Fred. Zwarts wrote:
Op 14.jul.2025 om 04:46 schreef olcott:
On 7/13/2025 8:33 PM, Richard Damon wrote:
On 7/13/25 4:43 PM, olcott wrote:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as >>>>>>>>>> to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a
description
of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to say >>>>>> what
you mean by an "x86 emulator". The name you give it is irrelevant >>>>>>
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping
tiny pieces
out of it and dealing with those. The proof you claim to refute >>>>>>>> has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function returns
true or
false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable
input for HHH. This is its counter example refuting the
claim that a universal halt decider can exist.
But since your DD by your own admission is a category error for a
halt decider, as you have specifically stated it isn't a program as
the input doesn't include the code of the specific HHH that it
calls, you proof is just invalid.
Sorry, all you proved is that you don't know what you are talking
about.
That you keep trying to get away with refuting
this easily verified fact says a about about you
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
Which illustrates that simulation is not the right tool for a decider,
When DDD is emulated by HHH according to the semantics of
the x86 language the actual behavior that this input actually
specifies is demonstrated. The semantics of the x86 language
*is* the ultimate measure of the behavior of the input.
HHH could incorrectly "interpret" "push ebp" to mean
"jmp 000021a3" incorrectly giving the behavior that
you expect. There is no correct way for HHH to do this.
On 7/14/2025 4:38 AM, Fred. Zwarts wrote:
Op 14.jul.2025 om 04:39 schreef olcott:
On 7/13/2025 8:31 PM, Richard Damon wrote:
On 7/13/25 5:14 PM, olcott wrote:
On 7/13/2025 4:05 PM, joes wrote:
Am Sun, 13 Jul 2025 13:53:00 -0500 schrieb olcott:
On 7/13/2025 1:32 PM, joes wrote:Have you heard of paraphrasing? What IS the difference now?
Am Sun, 13 Jul 2025 09:14:56 -0500 schrieb olcott:It must perfectly 100% specific about DDD simulated by pure
On 7/13/2025 5:26 AM, joes wrote:I did answer in the affirmative. Where's the difference?
Am Sat, 12 Jul 2025 16:45:50 -0500 schrieb olcott:
On 7/12/2025 4:25 PM, joes wrote:
Am Sat, 12 Jul 2025 14:54:28 -0500 schrieb olcott:
On 7/12/2025 2:46 PM, joes wrote:
Am Sat, 12 Jul 2025 09:52:21 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/12/2025 5:49 AM, joes wrote:
No you answered a similar question not the exact same question. >>>>>>>>> CanContrary to you I can handle multiple steps at a time. I already >>>>>>>>>> answered your question above. What's your next step?*You jumped too many steps ahead*No, I get it. If HHH were a pure simulator it would nest >>>>>>>>>>>> copies ofWe have to break it down to its simpler steps or don't seem to >>>>>>>>>>>>> have any understanding at all.HHH is not a pure simulator.That means that HHH reports itself as not being a decider. >>>>>>>>>>>>>>>>In other words you cannot understand that the behavior of >>>>>>>>>>>>>>> DDD
simulated by a pure simulator HHH would be an infinite >>>>>>>>>>>>>>> repetition of its first line?
(1) If HHH was a pure simulator it would endlessly
simulate the first instruction of DDD and never >>>>>>>>>>>>> reach the
"return"
statement.
itself forever. A pure simulator running DDD as is would >>>>>>>>>>>> halt. If
DDD called a pure simulator, HHH would correctly return >>>>>>>>>>>> "doesn't
halt". And HHH running DDD does so incorrectly. You confuse >>>>>>>>>>>> that
with the second case.
There is only this one step:
If HHH was a pure simulator would DDD simulated by HHH reach >>>>>>>>>>> its own
"return" instruction?
I have another micro-step immediately after this one so if >>>>>>>>>>> you jump
ahead we have to keep repeating this step over and over until >>>>>>>>>>> we are
done with this step.
DDD simulated by pure simulator HHH ever reach its "return"
instruction?
simulator
HHH NOT REACHING ITS OWN RETURN INSTRUCTION.
When I ask a YES or NO question say YES or NO don't freaking
change the
words *AT ALL* and then answer a different question.
Richard has been using that dishonest ploy to dodge the point
*FOR THREE
F-ING YEARS*
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
Wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
We have pointed out many times that this is an incomplete input.
That you keep ignoring my corrections to your mistake
IS NOT ANY REBUTTAL WHAT-SO-EVER.
It suggests it is complete, because even the size is mentioned.
No chatbot (of four) needed more than this to figure
out that DDD specifies non-halting recursive simulation:
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
On 7/14/2025 9:57 PM, Richard Damon wrote:
On 7/14/25 11:53 AM, olcott wrote:
On 7/14/2025 6:37 AM, Richard Damon wrote:
On 7/13/25 10:46 PM, olcott wrote:Reaching a final halt state <is> the definition of halting.
On 7/13/2025 8:33 PM, Richard Damon wrote:
On 7/13/25 4:43 PM, olcott wrote:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction >>>>>>>>>>>> as to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a >>>>>>>>>> description
of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to >>>>>>>> say what
you mean by an "x86 emulator". The name you give it is irrelevant >>>>>>>>
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping >>>>>>>>>> tiny pieces
out of it and dealing with those. The proof you claim to >>>>>>>>>> refute has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function
returns true or
false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable
input for HHH. This is its counter example refuting the
claim that a universal halt decider can exist.
But since your DD by your own admission is a category error for a
halt decider, as you have specifically stated it isn't a program
as the input doesn't include the code of the specific HHH that it
calls, you proof is just invalid.
Sorry, all you proved is that you don't know what you are talking
about.
That you keep trying to get away with refuting
this easily verified fact says a about about you
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
Which isn't the definition of Non-Halting,
Right, but the OBJECT that measures that it the exectution of the
Program, or a complete simulation.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
Do you really think that you can get away with
disagreeing with the x86 language?
On 7/14/2025 4:46 AM, Fred. Zwarts wrote:
Op 13.jul.2025 om 17:31 schreef olcott:WHEN I PROVIDE COMPLETE PROOF THAT
On 7/13/2025 1:06 AM, Fred. Zwarts wrote:
Op 12.jul.2025 om 16:39 schreef olcott:
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:There is no non-halting pattern.
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate itself at >>>>>>>>>>> all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to >>>>>>>>>> the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Is the full execution trace of
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
And it also proves my claim that HHH did not simulate itself >>>>>>>>>> correctly *up to the end*.
Exactly what is your professional programming experience?
I have 20 years in C++ and became a professional programmer
in 1986.
Irrelevant, even when it is more than your experience.
void DDD()
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to
simulate it correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics
of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
*When you keep ignoring my correction to your mistakes*
*then you never notice that you made any mistakes*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
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
It is a tautology that any input D to simulating termination
analyzer H that *would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
At usual no rebuttal, but repeated claims without any evidence.
YOU ARE UNABLE TO UNDERSTAND THIS
REMAINS COMPLETE PROOF.
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
All of the Chatbots could figure out that DDD
simulated by HHH cannot possibly reach its own
"return" statement because of recursive emulation,
from the above specification and no more.
On 7/14/2025 4:54 AM, Fred. Zwarts wrote:
Op 14.jul.2025 om 04:53 schreef olcott:
On 7/13/2025 8:34 PM, Richard Damon wrote:
On 7/13/25 5:13 PM, olcott wrote:
On 7/13/2025 3:56 PM, joes wrote:
Am Sun, 13 Jul 2025 15:43:31 -0500 schrieb olcott:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:No, every input is decidable,
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
An argument like this is at such a low level of abstraction >>>>>>>>>>>> as to
be near valuless.
It is really weird that you are calling a 100% complete concrete >>>>>>>>>>> specification "a low level of abstraction". That HHH(DD) >>>>>>>>>>> correctly
determines that DD simulated by HHH cannot possibly halt is a >>>>>>>>>>> proven
fact.
A complete concrete specification would necessarily include a >>>>>>>>>> description of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to >>>>>>>> say what
you mean by an "x86 emulator". The name you give it is irrelevant >>>>>>>>
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping >>>>>>>>>> tiny
pieces out of it and dealing with those. The proof you claim to >>>>>>>>>> refute has no notion of simulation, for example; it doesn't >>>>>>>>>> need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function
returns true
or false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable input
for HHH.
This is its counter example refuting the claim that a universal halt >>>>>>> decider can exist.
undecidable input *for HHH*
No such term.
PROBLEMS are undecidable.
Inputs are either correct or incorrect decided.
There is no existing term for the meaning that
I must express. *undecidable input* was as close
as I could get with existing terms.
Any TM decider input D to decider H such that transitioning
to an accept state H.Y or a reject state H.N are both the
wrong answer.
Each program has either halting, or non-halting behaviour.
It has never ever been about programs.
It has always been about behavior specified by finite strings.
On 7/14/2025 4:34 AM, Fred. Zwarts wrote:
Op 13.jul.2025 om 21:12 schreef olcott:
On 7/13/2025 1:32 PM, joes wrote:
Am Sun, 13 Jul 2025 09:14:56 -0500 schrieb olcott:
On 7/13/2025 5:26 AM, joes wrote:I did answer in the affirmative. Where's the difference?
Am Sat, 12 Jul 2025 16:45:50 -0500 schrieb olcott:
On 7/12/2025 4:25 PM, joes wrote:
Am Sat, 12 Jul 2025 14:54:28 -0500 schrieb olcott:
On 7/12/2025 2:46 PM, joes wrote:
Am Sat, 12 Jul 2025 09:52:21 -0500 schrieb olcott:
On 7/12/2025 5:49 AM, joes wrote:
No you answered a similar question not the exact same question. CanContrary to you I can handle multiple steps at a time. I already*You jumped too many steps ahead*No, I get it. If HHH were a pure simulator it would nest copies of >>>>>>>> itself forever. A pure simulator running DDD as is would halt. >>>>>>>> If DDDWe have to break it down to its simpler steps or don't seem to >>>>>>>>> haveHHH is not a pure simulator.That means that HHH reports itself as not being a decider. >>>>>>>>>>>>In other words you cannot understand that the behavior of DDD >>>>>>>>>>> simulated by a pure simulator HHH would be an infinite
repetition
of its first line?
any understanding at all.
(1) If HHH was a pure simulator it would endlessly
simulate the first instruction of DDD and never reach the
"return"
statement.
called a pure simulator, HHH would correctly return "doesn't halt". >>>>>>>> And HHH running DDD does so incorrectly. You confuse that with the >>>>>>>> second case.
There is only this one step:
If HHH was a pure simulator would DDD simulated by HHH reach its own >>>>>>> "return" instruction?
I have another micro-step immediately after this one so if you jump >>>>>>> ahead we have to keep repeating this step over and over until we are >>>>>>> done with this step.
answered your question above. What's your next step?
DDD
simulated by pure simulator HHH ever reach its "return" instruction?
When HHH is a pure simulator then DDD correctly
simulated by HHH cannot possibly reach its own
"return" instruction.
So it fails to simulate correctly the program specified in the input
up to the end.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When DDD is emulated by pure simulator HHH
according to the semantics of the x86 language
HHH emulates DDD that calls HHH(DDD) then
HHH emulates itself emulating DDD this process
endlessly repeats.
People not knowing anything about programming
will never get this.
On 7/14/2025 4:56 AM, Fred. Zwarts wrote:
Op 13.jul.2025 om 22:43 schreef olcott:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:Each program has either halting or non-halting behaviour.
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as >>>>>>>> to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a
description
of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to say what >>>> you mean by an "x86 emulator". The name you give it is irrelevant
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny >>>>>> pieces
out of it and dealing with those. The proof you claim to refute
has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function returns
true or
false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable
input for HHH. This is its counter example refuting the
claim that a universal halt decider can exist.
It has never ever been about programs.
It has always been about behavior specified by finite strings.
If this is undecidable input for HHH, the only interpretation is: HHH
is not the correct decider for this input, try to find a better decider.
On 7/14/2025 4:49 AM, Fred. Zwarts wrote:
Op 14.jul.2025 om 04:36 schreef olcott:
On 7/13/2025 8:28 PM, Richard Damon wrote:
On 7/13/25 5:17 PM, olcott wrote:
On 7/13/2025 3:27 PM, Richard Damon wrote:
On 7/13/25 11:22 AM, olcott wrote:
On 7/13/2025 7:04 AM, Richard Damon wrote:
On 7/12/25 7:40 PM, olcott wrote:
On 7/12/2025 6:09 PM, Richard Damon wrote:
On 7/12/25 10:39 AM, olcott wrote:
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:void DDD()
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>>
One of these "errors" was that HHH cannot simulate >>>>>>>>>>>>>>>>> itself at all.
As usual you twist the words of your reviewers. >>>>>>>>>>>>>>>> The claim was that no HHH can simulate itself correctly >>>>>>>>>>>>>>>> *up to the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >>>>>>>>>>>>>>>>> Is the full execution trace ofAnd it also proves my claim that HHH did not simulate >>>>>>>>>>>>>>>> itself correctly *up to the end*.
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>>>
Exactly what is your professional programming experience? >>>>>>>>>>>>>>> I have 20 years in C++ and became a professional programmer >>>>>>>>>>>>>>> in 1986.
Irrelevant, even when it is more than your experience. >>>>>>>>>>>>>
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH
cannot possibly reach its own "return" instruction
(a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to >>>>>>>>>>>> simulate it correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics
of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
But thst pattern *ISN'T* a "non-halting" pattern, as it also >>>>>>>>>> occurs in the direct execution of DDD, which you admit halts. >>>>>>>>>>
Thus, the claim of non-halting is just based on a lie.
Since you seem to have sufficient technical competence and
you know that halting is reaching a final halt state then
you know that when 0 to ∞ steps are correctly simulated by >>>>>>>>> some HHH according to the semantics of the C programming language >>>>>>>>> that no DDD simulated by any HHH ever reaches its final halt >>>>>>>>> state.
Halting is the *PROGRAM* reaching a final stste when it is run. >>>>>>>>
This same thing can be applied to C functions reaching
their "return" instructions. The field of termination
analysis breaks programs down to their constituent parts.
When a called function cannot return this entails that
the caller will not stop running.
Right, but only for C functions that meet the definition of a
Computation Program, and thus INCLUDE all the code they call.
DDD correctly simulated by HHH cannot possibly
ever reach its own return instruction.
So?
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "return" statement.
DDD is this exact machine code and each HHH is
at machine address 000015d2:
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Why repeating this failure of HHH to reach the final halt state of the
program specified in the input?
You don't seem to understand the notion of recursion.
Please provide me with the details of your programming
experience. Richard did this and proved he has technical
competence.
A correct simulation (which HHH cannot do) would show that HHH returns
with a value 0 and DDD reaches its final halt state.
Incompetent people will not understand that a simulated
input cannot possibly return to its simulator.
On 7/14/2025 9:53 PM, Richard Damon wrote:All competent experts have told you that your reasoning fails.
On 7/14/25 11:13 AM, olcott wrote:
On 7/14/2025 8:54 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 19:13:18 -0400, Richard Damon wrote:
On 7/12/25 8:48 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 08:36:55 -0400, Richard Damon wrote:
On 7/12/25 8:30 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 08:20:59 -0400, Richard Damon wrote:
On 7/12/25 12:42 AM, olcott wrote:
On 7/11/2025 6:34 PM, Richard Damon wrote:
On 7/10/25 10:30 AM, olcott wrote:What of kind of systems did you work with?
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:So? I started programming for pay in 1974, where as an
Op 09.jul.2025 om 14:54 schreef olcott:>>Exactly what is your professional programming experience? I >>>>>>>>>>>> have
One of these "errors" was that HHH cannot simulate itself at >>>>>>>>>>>>>> all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to >>>>>>>>>>>>> the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf Is the full >>>>>>>>>>>>>> execution trace ofAnd it also proves my claim that HHH did not simulate itself >>>>>>>>>>>>> correctly *up to the end*.
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>
20 years in C++ and became a professional programmer in 1986. >>>>>>>>>>>>
undergraduate I was using my programming from High School to >>>>>>>>>>> build
Data Analsys programs, an inter-computer link to make a computer >>>>>>>>>>> with a vector graphics dispaly usable by the main frame, and the >>>>>>>>>>> OS and data collection programs for a laboratory.
In 1982, with my MASTERS degree, I was employed to write >>>>>>>>>>> programs,
as well as design hardware for an industrial firm.
It seems I have many years over you, and it sounds like I may >>>>>>>>>>> have
well written more programs than you have.
I started using C from K&R in the late 70s and C++ using >>>>>>>>>>> Cfront in
the mid 80s. (so like 40 years of experience).
I programmed AutoCAD in C++ creating new architectural
engineering
automations. This was mostly analytical geometry. I worked in C++ >>>>>>>>>> and some C for the last 22 years. I worked on NPOESS
https://en.wikipedia.org/wiki/NPOESS for Northrup Grumman
In otherwords, you let an existing program do most of the work, >>>>>>>>> and
you added some fonctionality to it.
As to NPOESS, just "working on it" doesn't give much idea of your >>>>>>>>> responsibilities, and tha fact that it was a FAILED system,
scrubbed
due to progtram issues doesn't say much for what you can do. >>>>>>>>>
It seems that in all your work, you might never have produced an >>>>>>>>> actual "program", only pieces of systems, which explains why you >>>>>>>>> don't understand what a "program" actually is.
Most of my work has been in embedded system, where I built the >>>>>>>>> hardware around a processor for some function, and then fully >>>>>>>>> programmed the processor from the ground up to complete the
product.
I also wrote PC side support for control of the embedded
application.
As part of this, I have produced a large library of support
functions to allow the building of similar programs by others, >>>>>>>>> which
has become the basis for much of the work produced at the
company I
work for.
I will note that I am STILL active in the profession, and now >>>>>>>>> spend
part of my time training others in the company to improve their >>>>>>>>> skills, while it seems you are no longer at work, and I doubt you >>>>>>>>> get many calls asking for advice about how to do things.
Your personality really is quite obnoxious isn't it, Damon?
/Flibble
HE asked the question.
HE claims to be an expert, with no actual credentials and calls
me the
one who doesn't know what I am doing, even though I am much better >>>>>>> trained then him.
You and He are the "obnoxious" ones, that need to use ad hominim >>>>>>> attacks as you have no factual grounds to refute the errors pointed >>>>>>> out.
You make more ad hominum attacks than anyone else on here, Damon.
/Flibble
Really? When have I ever said someone was wrong just because they were >>>>> stupid or some other aspect of them.
I have always pointed out the factual and logical reason they were
wrong, and then pointed out that the repeated saying of that error
shows
they are stupid.
I guess you don't know what ad hominum means, perhaps because you are >>>>> just too stupid. (Note, that statement is not ad hominum, as I
don't use
your stupidity as the arguement for your error, but that the error
demonstrates the stupidity).
Ad hominem (often misspelled as "ad hominum" in the statement) is a
logical fallacy where an argument is rebutted by attacking the
character,
motive, or other attribute of the person making it, rather than
addressing
the substance of the argument itself. It's essentially dismissing a
claim
based on who is saying it, not on its merits.
In the described approach—pointing out factual and logical flaws in
someone's claim first, then concluding that repeated errors indicate
stupidity—that sequence isn't inherently ad hominem. The core rebuttal >>>> targets the argument's content (facts and logic), and the insult
follows
as a separate judgment on the person's pattern of behavior. Insults
alone
don't constitute ad hominem if they're not used as the basis for
rejecting
the argument. For example:
- Ad hominem: "Your point about climate change is wrong because
you're an
idiot."
- Not ad hominem: "Your point about climate change is wrong because the >>>> data shows X, Y, and Z are inaccurate—and repeating such basic errors >>>> suggests you're not thinking critically."
However, the specific example given ("I guess you don't know what ad
hominum means, perhaps because you are just too stupid") veers
closer to
ad hominem territory. It asserts an error (not knowing the meaning)
without providing any factual or logical explanation for why the
understanding is incorrect. Instead, it immediately attributes the
supposed error to stupidity as the explanatory cause. This implies the >>>> dismissal is rooted in the personal attack rather than a substantive
refutation. The parenthetical note claims the error demonstrates the
stupidity, but the statement doesn't actually demonstrate or explain
the
error—it assumes it and jumps to the insult. To avoid ad hominem
entirely,
the logical rebuttal should come first and stand on its own, with any
personal commentary clearly separated and not presented as the
reason for
the disagreement.
If the goal is productive discussion, avoiding insults altogether is
usually better, as they can escalate conflicts without adding value. If >>>> this is part of a broader conversation, providing the full context
could
help refine the analysis.
He is a troll not interested in an honest dialogue.
No, you meet the definition of the Troll.
Try using actual facts and respond.
The insults only come when you just blindly repeat you errors.
I prove my point about HHH(DDD) with simple reasoning that
anyone that is an expert at the C or C++ programming language
understands as dead obviously correct. You deny it anyway thus
condemning your own soul to Hell.
On 7/14/2025 9:33 PM, Richard Damon wrote:
On 7/14/25 11:30 AM, olcott wrote:*I have said this thousands of times and YOU NEVER GET IT*
On 7/14/2025 6:23 AM, Richard Damon wrote:
On 7/13/25 10:36 PM, olcott wrote:
On 7/13/2025 8:28 PM, Richard Damon wrote:
On 7/13/25 5:17 PM, olcott wrote:
On 7/13/2025 3:27 PM, Richard Damon wrote:
On 7/13/25 11:22 AM, olcott wrote:
On 7/13/2025 7:04 AM, Richard Damon wrote:
On 7/12/25 7:40 PM, olcott wrote:
On 7/12/2025 6:09 PM, Richard Damon wrote:
On 7/12/25 10:39 AM, olcott wrote:
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:void DDD()
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>> >>>>>>>>>>>>>>>>>>> One of these "errors" was that HHH cannot simulate >>>>>>>>>>>>>>>>>>> itself at all.
As usual you twist the words of your reviewers. >>>>>>>>>>>>>>>>>> The claim was that no HHH can simulate itself >>>>>>>>>>>>>>>>>> correctly *up to the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >>>>>>>>>>>>>>>>>>> Is the full execution trace ofAnd it also proves my claim that HHH did not simulate >>>>>>>>>>>>>>>>>> itself correctly *up to the end*.
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>>>>>
Exactly what is your professional programming experience? >>>>>>>>>>>>>>>>> I have 20 years in C++ and became a professional >>>>>>>>>>>>>>>>> programmer
in 1986.
Irrelevant, even when it is more than your experience. >>>>>>>>>>>>>>>
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH >>>>>>>>>>>>>>> cannot possibly reach its own "return" instruction >>>>>>>>>>>>>>> (a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to >>>>>>>>>>>>>> simulate it correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics >>>>>>>>>>>>> of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
But thst pattern *ISN'T* a "non-halting" pattern, as it also >>>>>>>>>>>> occurs in the direct execution of DDD, which you admit halts. >>>>>>>>>>>>
Thus, the claim of non-halting is just based on a lie. >>>>>>>>>>>>
Since you seem to have sufficient technical competence and >>>>>>>>>>> you know that halting is reaching a final halt state then >>>>>>>>>>> you know that when 0 to ∞ steps are correctly simulated by >>>>>>>>>>> some HHH according to the semantics of the C programming >>>>>>>>>>> language
that no DDD simulated by any HHH ever reaches its final halt >>>>>>>>>>> state.
Halting is the *PROGRAM* reaching a final stste when it is run. >>>>>>>>>>
This same thing can be applied to C functions reaching
their "return" instructions. The field of termination
analysis breaks programs down to their constituent parts.
When a called function cannot return this entails that
the caller will not stop running.
Right, but only for C functions that meet the definition of a
Computation Program, and thus INCLUDE all the code they call.
DDD correctly simulated by HHH cannot possibly
ever reach its own return instruction.
So?
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "return" statement.
SO, you believe in Strawmen and the Truth Fairy.
When all of the elements of a set of HHH/DDD pairs
have the same property DDD does not reach its final
halt state, then we correctly conclude that no DDD
simulated by any HHH reaches its final halt state
as a tautology.
That you are trying to get away for saying that a
tautology is the strawman error is a lame attempt
at deception.
But that is just an admitted strawman, proving your stupidity.
In fact, for EVERY HHH/DDD pair where HHH(DDD) returns an answer, DDD
reaches a final state,
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
On 7/14/2025 9:40 PM, Richard Damon wrote:
On 7/14/25 11:50 AM, olcott wrote:No I am not. You are the one condemning your own soul to Hell.
On 7/14/2025 6:26 AM, Richard Damon wrote:
On 7/13/25 10:39 PM, olcott wrote:
On 7/13/2025 8:31 PM, Richard Damon wrote:
On 7/13/25 5:14 PM, olcott wrote:
On 7/13/2025 4:05 PM, joes wrote:
Am Sun, 13 Jul 2025 13:53:00 -0500 schrieb olcott:
On 7/13/2025 1:32 PM, joes wrote:Have you heard of paraphrasing? What IS the difference now?
Am Sun, 13 Jul 2025 09:14:56 -0500 schrieb olcott:It must perfectly 100% specific about DDD simulated by pure
On 7/13/2025 5:26 AM, joes wrote:I did answer in the affirmative. Where's the difference?
Am Sat, 12 Jul 2025 16:45:50 -0500 schrieb olcott:
On 7/12/2025 4:25 PM, joes wrote:
Am Sat, 12 Jul 2025 14:54:28 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/12/2025 2:46 PM, joes wrote:
Am Sat, 12 Jul 2025 09:52:21 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/12/2025 5:49 AM, joes wrote:
No you answered a similar question not the exact sameContrary to you I can handle multiple steps at a time. I >>>>>>>>>>>> already*You jumped too many steps ahead*No, I get it. If HHH were a pure simulator it would nest >>>>>>>>>>>>>> copies ofWe have to break it down to its simpler steps or don't >>>>>>>>>>>>>>> seem toHHH is not a pure simulator.That means that HHH reports itself as not being a >>>>>>>>>>>>>>>>>> decider.In other words you cannot understand that the behavior >>>>>>>>>>>>>>>>> of DDD
simulated by a pure simulator HHH would be an infinite >>>>>>>>>>>>>>>>> repetition of its first line?
have any understanding at all.
(1) If HHH was a pure simulator it would endlessly >>>>>>>>>>>>>>> simulate the first instruction of DDD and never
reach the
"return"
statement.
itself forever. A pure simulator running DDD as is would >>>>>>>>>>>>>> halt. If
DDD called a pure simulator, HHH would correctly return >>>>>>>>>>>>>> "doesn't
halt". And HHH running DDD does so incorrectly. You >>>>>>>>>>>>>> confuse that
with the second case.
There is only this one step:
If HHH was a pure simulator would DDD simulated by HHH >>>>>>>>>>>>> reach its own
"return" instruction?
I have another micro-step immediately after this one so if >>>>>>>>>>>>> you jump
ahead we have to keep repeating this step over and over >>>>>>>>>>>>> until we are
done with this step.
answered your question above. What's your next step?
question. Can
DDD simulated by pure simulator HHH ever reach its "return" >>>>>>>>>>> instruction?
simulator
HHH NOT REACHING ITS OWN RETURN INSTRUCTION.
When I ask a YES or NO question say YES or NO don't freaking >>>>>>>>> change the
words *AT ALL* and then answer a different question.
Richard has been using that dishonest ploy to dodge the point >>>>>>>>> *FOR THREE
F-ING YEARS*
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
Wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
*Whenever I challenge you to show the details of how I am wrong*
just like Trump's TACO: Richard always chickens out.
Look at the trace of HHH1.
Changing the subject from DDD emulated by HHH
to DDD emulated by HHH1 is deception.
Then I guess you are admitting to that deception
You are the one that thinks that sadistic trollish head games
don't count as lies.
On 7/14/2025 9:53 PM, Richard Damon wrote:
On 7/14/25 11:13 AM, olcott wrote:
On 7/14/2025 8:54 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 19:13:18 -0400, Richard Damon wrote:
On 7/12/25 8:48 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 08:36:55 -0400, Richard Damon wrote:
On 7/12/25 8:30 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 08:20:59 -0400, Richard Damon wrote:
On 7/12/25 12:42 AM, olcott wrote:
On 7/11/2025 6:34 PM, Richard Damon wrote:
On 7/10/25 10:30 AM, olcott wrote:What of kind of systems did you work with?
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:So? I started programming for pay in 1974, where as an
Op 09.jul.2025 om 14:54 schreef olcott:>>Exactly what is your professional programming experience? I >>>>>>>>>>>> have
One of these "errors" was that HHH cannot simulate itself at >>>>>>>>>>>>>> all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly *up to >>>>>>>>>>>>> the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf Is the full >>>>>>>>>>>>>> execution trace ofAnd it also proves my claim that HHH did not simulate itself >>>>>>>>>>>>> correctly *up to the end*.
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>
20 years in C++ and became a professional programmer in 1986. >>>>>>>>>>>>
undergraduate I was using my programming from High School to >>>>>>>>>>> build
Data Analsys programs, an inter-computer link to make a computer >>>>>>>>>>> with a vector graphics dispaly usable by the main frame, and the >>>>>>>>>>> OS and data collection programs for a laboratory.
In 1982, with my MASTERS degree, I was employed to write >>>>>>>>>>> programs,
as well as design hardware for an industrial firm.
It seems I have many years over you, and it sounds like I may >>>>>>>>>>> have
well written more programs than you have.
I started using C from K&R in the late 70s and C++ using >>>>>>>>>>> Cfront in
the mid 80s. (so like 40 years of experience).
I programmed AutoCAD in C++ creating new architectural
engineering
automations. This was mostly analytical geometry. I worked in C++ >>>>>>>>>> and some C for the last 22 years. I worked on NPOESS
https://en.wikipedia.org/wiki/NPOESS for Northrup Grumman
In otherwords, you let an existing program do most of the work, >>>>>>>>> and
you added some fonctionality to it.
As to NPOESS, just "working on it" doesn't give much idea of your >>>>>>>>> responsibilities, and tha fact that it was a FAILED system,
scrubbed
due to progtram issues doesn't say much for what you can do. >>>>>>>>>
It seems that in all your work, you might never have produced an >>>>>>>>> actual "program", only pieces of systems, which explains why you >>>>>>>>> don't understand what a "program" actually is.
Most of my work has been in embedded system, where I built the >>>>>>>>> hardware around a processor for some function, and then fully >>>>>>>>> programmed the processor from the ground up to complete the
product.
I also wrote PC side support for control of the embedded
application.
As part of this, I have produced a large library of support
functions to allow the building of similar programs by others, >>>>>>>>> which
has become the basis for much of the work produced at the
company I
work for.
I will note that I am STILL active in the profession, and now >>>>>>>>> spend
part of my time training others in the company to improve their >>>>>>>>> skills, while it seems you are no longer at work, and I doubt you >>>>>>>>> get many calls asking for advice about how to do things.
Your personality really is quite obnoxious isn't it, Damon?
/Flibble
HE asked the question.
HE claims to be an expert, with no actual credentials and calls
me the
one who doesn't know what I am doing, even though I am much better >>>>>>> trained then him.
You and He are the "obnoxious" ones, that need to use ad hominim >>>>>>> attacks as you have no factual grounds to refute the errors pointed >>>>>>> out.
You make more ad hominum attacks than anyone else on here, Damon.
/Flibble
Really? When have I ever said someone was wrong just because they were >>>>> stupid or some other aspect of them.
I have always pointed out the factual and logical reason they were
wrong, and then pointed out that the repeated saying of that error
shows
they are stupid.
I guess you don't know what ad hominum means, perhaps because you are >>>>> just too stupid. (Note, that statement is not ad hominum, as I
don't use
your stupidity as the arguement for your error, but that the error
demonstrates the stupidity).
Ad hominem (often misspelled as "ad hominum" in the statement) is a
logical fallacy where an argument is rebutted by attacking the
character,
motive, or other attribute of the person making it, rather than
addressing
the substance of the argument itself. It's essentially dismissing a
claim
based on who is saying it, not on its merits.
In the described approach—pointing out factual and logical flaws in
someone's claim first, then concluding that repeated errors indicate
stupidity—that sequence isn't inherently ad hominem. The core rebuttal >>>> targets the argument's content (facts and logic), and the insult
follows
as a separate judgment on the person's pattern of behavior. Insults
alone
don't constitute ad hominem if they're not used as the basis for
rejecting
the argument. For example:
- Ad hominem: "Your point about climate change is wrong because
you're an
idiot."
- Not ad hominem: "Your point about climate change is wrong because the >>>> data shows X, Y, and Z are inaccurate—and repeating such basic errors >>>> suggests you're not thinking critically."
However, the specific example given ("I guess you don't know what ad
hominum means, perhaps because you are just too stupid") veers
closer to
ad hominem territory. It asserts an error (not knowing the meaning)
without providing any factual or logical explanation for why the
understanding is incorrect. Instead, it immediately attributes the
supposed error to stupidity as the explanatory cause. This implies the >>>> dismissal is rooted in the personal attack rather than a substantive
refutation. The parenthetical note claims the error demonstrates the
stupidity, but the statement doesn't actually demonstrate or explain
the
error—it assumes it and jumps to the insult. To avoid ad hominem
entirely,
the logical rebuttal should come first and stand on its own, with any
personal commentary clearly separated and not presented as the
reason for
the disagreement.
If the goal is productive discussion, avoiding insults altogether is
usually better, as they can escalate conflicts without adding value. If >>>> this is part of a broader conversation, providing the full context
could
help refine the analysis.
He is a troll not interested in an honest dialogue.
No, you meet the definition of the Troll.
Try using actual facts and respond.
The insults only come when you just blindly repeat you errors.
I prove my point about HHH(DDD) with simple reasoning that
anyone that is an expert at the C or C++ programming language
understands as dead obviously correct. You deny it anyway thus
condemning your own soul to Hell.
On 7/14/2025 9:57 PM, Richard Damon wrote:
On 7/14/25 11:53 AM, olcott wrote:
On 7/14/2025 6:37 AM, Richard Damon wrote:
On 7/13/25 10:46 PM, olcott wrote:Reaching a final halt state <is> the definition of halting.
On 7/13/2025 8:33 PM, Richard Damon wrote:
On 7/13/25 4:43 PM, olcott wrote:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction >>>>>>>>>>>> as to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include a >>>>>>>>>> description
of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to >>>>>>>> say what
you mean by an "x86 emulator". The name you give it is irrelevant >>>>>>>>
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping >>>>>>>>>> tiny pieces
out of it and dealing with those. The proof you claim to >>>>>>>>>> refute has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function
returns true or
false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable
input for HHH. This is its counter example refuting the
claim that a universal halt decider can exist.
But since your DD by your own admission is a category error for a
halt decider, as you have specifically stated it isn't a program
as the input doesn't include the code of the specific HHH that it
calls, you proof is just invalid.
Sorry, all you proved is that you don't know what you are talking
about.
That you keep trying to get away with refuting
this easily verified fact says a about about you
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
Which isn't the definition of Non-Halting,
Right, but the OBJECT that measures that it the exectution of the
Program, or a complete simulation.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
Do you really think that you can get away with
disagreeing with the x86 language?
On 7/14/2025 9:33 PM, Richard Damon wrote:
On 7/14/25 11:30 AM, olcott wrote:*I have said this thousands of times and YOU NEVER GET IT*
On 7/14/2025 6:23 AM, Richard Damon wrote:
On 7/13/25 10:36 PM, olcott wrote:
On 7/13/2025 8:28 PM, Richard Damon wrote:
On 7/13/25 5:17 PM, olcott wrote:
On 7/13/2025 3:27 PM, Richard Damon wrote:
On 7/13/25 11:22 AM, olcott wrote:
On 7/13/2025 7:04 AM, Richard Damon wrote:
On 7/12/25 7:40 PM, olcott wrote:
On 7/12/2025 6:09 PM, Richard Damon wrote:
On 7/12/25 10:39 AM, olcott wrote:
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:void DDD()
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 14:54 schreef olcott:>> >>>>>>>>>>>>>>>>>>> One of these "errors" was that HHH cannot simulate >>>>>>>>>>>>>>>>>>> itself at all.
As usual you twist the words of your reviewers. >>>>>>>>>>>>>>>>>> The claim was that no HHH can simulate itself >>>>>>>>>>>>>>>>>> correctly *up to the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >>>>>>>>>>>>>>>>>>> Is the full execution trace ofAnd it also proves my claim that HHH did not simulate >>>>>>>>>>>>>>>>>> itself correctly *up to the end*.
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>>>>>
Exactly what is your professional programming experience? >>>>>>>>>>>>>>>>> I have 20 years in C++ and became a professional >>>>>>>>>>>>>>>>> programmer
in 1986.
Irrelevant, even when it is more than your experience. >>>>>>>>>>>>>>>
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH >>>>>>>>>>>>>>> cannot possibly reach its own "return" instruction >>>>>>>>>>>>>>> (a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH to >>>>>>>>>>>>>> simulate it correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics >>>>>>>>>>>>> of the x86 language until HHH does correctly detect
a non-halting behavior pattern.
But thst pattern *ISN'T* a "non-halting" pattern, as it also >>>>>>>>>>>> occurs in the direct execution of DDD, which you admit halts. >>>>>>>>>>>>
Thus, the claim of non-halting is just based on a lie. >>>>>>>>>>>>
Since you seem to have sufficient technical competence and >>>>>>>>>>> you know that halting is reaching a final halt state then >>>>>>>>>>> you know that when 0 to ∞ steps are correctly simulated by >>>>>>>>>>> some HHH according to the semantics of the C programming >>>>>>>>>>> language
that no DDD simulated by any HHH ever reaches its final halt >>>>>>>>>>> state.
Halting is the *PROGRAM* reaching a final stste when it is run. >>>>>>>>>>
This same thing can be applied to C functions reaching
their "return" instructions. The field of termination
analysis breaks programs down to their constituent parts.
When a called function cannot return this entails that
the caller will not stop running.
Right, but only for C functions that meet the definition of a
Computation Program, and thus INCLUDE all the code they call.
DDD correctly simulated by HHH cannot possibly
ever reach its own return instruction.
So?
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "return" statement.
SO, you believe in Strawmen and the Truth Fairy.
When all of the elements of a set of HHH/DDD pairs
have the same property DDD does not reach its final
halt state, then we correctly conclude that no DDD
simulated by any HHH reaches its final halt state
as a tautology.
That you are trying to get away for saying that a
tautology is the strawman error is a lame attempt
at deception.
But that is just an admitted strawman, proving your stupidity.
In fact, for EVERY HHH/DDD pair where HHH(DDD) returns an answer, DDD
reaches a final state,
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
DDD emulated by HHH. Not DDD directly executed.
On 7/14/25 11:20 PM, olcott wrote:
On 7/14/2025 9:57 PM, Richard Damon wrote:Why do YOU think you can?
On 7/14/25 11:53 AM, olcott wrote:_DDD()
On 7/14/2025 6:37 AM, Richard Damon wrote:Right, but the OBJECT that measures that it the exectution of the
On 7/13/25 10:46 PM, olcott wrote:Reaching a final halt state <is> the definition of halting.
On 7/13/2025 8:33 PM, Richard Damon wrote:Which isn't the definition of Non-Halting,
On 7/13/25 4:43 PM, olcott wrote:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:But since your DD by your own admission is a category error for a >>>>>>> halt decider, as you have specifically stated it isn't a program >>>>>>> as the input doesn't include the code of the specific HHH that it >>>>>>> calls, you proof is just invalid.
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH according to >>>>>>>>>>>>>> the semantics of the C programming language cannot possibly >>>>>>>>>>>>>> reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction >>>>>>>>>>>>> as to be near valuless.
It is really weird that you are calling a 100% complete >>>>>>>>>>>> concrete specification "a low level of abstraction". That >>>>>>>>>>>> HHH(DD) correctly determines that DD simulated by HHH cannot >>>>>>>>>>>> possibly halt is a proven fact.
A complete concrete specification would necessarily include a >>>>>>>>>>> description of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to >>>>>>>>> say what you mean by an "x86 emulator". The name you give it is >>>>>>>>> irrelevant
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping >>>>>>>>>>> tiny pieces out of it and dealing with those. The proof you >>>>>>>>>>> claim to refute has no notion of simulation, for example; it >>>>>>>>>>> doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function
returns true or false, i.e. whether it specifies non halting >>>>>>>>> behaviour.
The proof is purported to prove THAT DD is an undecidable input >>>>>>>> for HHH. This is its counter example refuting the claim that a >>>>>>>> universal halt decider can exist.
Sorry, all you proved is that you don't know what you are talking >>>>>>> about.
That you keep trying to get away with refuting this easily verified >>>>>> fact says a about about you
_DDD()
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH [0000219f] >>>>>> 83c404 add esp,+04 [000021a2] 5d pop ebp
[000021a3] c3 ret Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated according to the >>>>>> semantics of the x86 language by some HHH, no DDD ever reaches its >>>>>> "ret" instruction.
Program, or a complete simulation.
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 // push DDD [0000219a] >> e833f4ffff call 000015d2 // call HHH [0000219f] 83c404 add
esp,+04 [000021a2] 5d pop ebp [000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated according to the
semantics of the x86 language by some HHH, no DDD ever reaches its
"ret" instruction.
Do you really think that you can get away with disagreeing with the x86
language?
Your above "Input" can be simulated past the instruction at 0000219A
because we lack the data of what is next.
Your problem is you started with the lie to yourself that you could
change the rules, and thus made yourself into a pathological liar that
has just lost the rules of the game.
In this case, your problem is you tried to redefine what non-halting
means, becuase your mind just can't handle the actual definition, and
some of its consequences. Partial emulations, by themselves, NEVER
define a program to be non-halting, only complete execution or complete simulation. PERIOD.
Sorry, you just proved you are an idiot that has brainwashed himself and apparently lost the key to get out.
On 7/15/2025 6:31 AM, Richard Damon wrote:
On 7/14/25 11:08 PM, olcott wrote:
On 7/14/2025 9:33 PM, Richard Damon wrote:
On 7/14/25 11:30 AM, olcott wrote:*I have said this thousands of times and YOU NEVER GET IT*
On 7/14/2025 6:23 AM, Richard Damon wrote:
On 7/13/25 10:36 PM, olcott wrote:
On 7/13/2025 8:28 PM, Richard Damon wrote:
On 7/13/25 5:17 PM, olcott wrote:
On 7/13/2025 3:27 PM, Richard Damon wrote:
On 7/13/25 11:22 AM, olcott wrote:
On 7/13/2025 7:04 AM, Richard Damon wrote:
On 7/12/25 7:40 PM, olcott wrote:
On 7/12/2025 6:09 PM, Richard Damon wrote:
On 7/12/25 10:39 AM, olcott wrote:
On 7/12/2025 3:08 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:23 schreef olcott:
On 7/11/2025 4:07 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:30 schreef olcott:void DDD()
On 7/10/2025 6:24 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 09.jul.2025 om 14:54 schreef olcott:>> >>>>>>>>>>>>>>>>>>>>> One of these "errors" was that HHH cannot simulate >>>>>>>>>>>>>>>>>>>>> itself at all.
As usual you twist the words of your reviewers. >>>>>>>>>>>>>>>>>>>> The claim was that no HHH can simulate itself >>>>>>>>>>>>>>>>>>>> correctly *up to the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >>>>>>>>>>>>>>>>>>>>> Is the full execution trace of
executed HHH simulates DDD that calls emulated >>>>>>>>>>>>>>>>>>>>> HHH(DDD)
that simulates DDD that calls emulated emulated >>>>>>>>>>>>>>>>>>>>> HHH(DDD)
And it also proves my claim that HHH did not >>>>>>>>>>>>>>>>>>>> simulate itself correctly *up to the end*. >>>>>>>>>>>>>>>>>>>>
Exactly what is your professional programming >>>>>>>>>>>>>>>>>>> experience?
I have 20 years in C++ and became a professional >>>>>>>>>>>>>>>>>>> programmer
in 1986.
Irrelevant, even when it is more than your experience. >>>>>>>>>>>>>>>>>
{
HHH(DDD);
return;
}
Anyone that cannot see that DDD simulated by HHH >>>>>>>>>>>>>>>>> cannot possibly reach its own "return" instruction >>>>>>>>>>>>>>>>> (a) Has woefully deficient knowledge
(b) Is a liar.
No need to repeat it. Everyone sees this failure of HHH >>>>>>>>>>>>>>>> to simulate it correctly up to the end.
It is in fact not any failure of HHH.
HHH does emulate its input according to the semantics >>>>>>>>>>>>>>> of the x86 language until HHH does correctly detect >>>>>>>>>>>>>>> a non-halting behavior pattern.
But thst pattern *ISN'T* a "non-halting" pattern, as it >>>>>>>>>>>>>> also occurs in the direct execution of DDD, which you >>>>>>>>>>>>>> admit halts.
Thus, the claim of non-halting is just based on a lie. >>>>>>>>>>>>>>
Since you seem to have sufficient technical competence and >>>>>>>>>>>>> you know that halting is reaching a final halt state then >>>>>>>>>>>>> you know that when 0 to ∞ steps are correctly simulated by >>>>>>>>>>>>> some HHH according to the semantics of the C programming >>>>>>>>>>>>> language
that no DDD simulated by any HHH ever reaches its final >>>>>>>>>>>>> halt state.
Halting is the *PROGRAM* reaching a final stste when it is run. >>>>>>>>>>>>
This same thing can be applied to C functions reaching
their "return" instructions. The field of termination
analysis breaks programs down to their constituent parts. >>>>>>>>>>> When a called function cannot return this entails that
the caller will not stop running.
Right, but only for C functions that meet the definition of a >>>>>>>>>> Computation Program, and thus INCLUDE all the code they call. >>>>>>>>>>
DDD correctly simulated by HHH cannot possibly
ever reach its own return instruction.
So?
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "return" statement.
SO, you believe in Strawmen and the Truth Fairy.
When all of the elements of a set of HHH/DDD pairs
have the same property DDD does not reach its final
halt state, then we correctly conclude that no DDD
simulated by any HHH reaches its final halt state
as a tautology.
That you are trying to get away for saying that a
tautology is the strawman error is a lame attempt
at deception.
But that is just an admitted strawman, proving your stupidity.
In fact, for EVERY HHH/DDD pair where HHH(DDD) returns an answer,
DDD reaches a final state,
Then you are just admitting to lying with a strawman, as the PROBLEM
you claim to be working on is about the program the input describes
when it is directly executed.
That is an error with the problem definition.
The actual correct problem definition is that
HHH must report on the behavior that its finite
string input specifies.
DDD emulated by HHH according to the semantics
of the x86 language DOES NOT HALT.
For 90 years the HP problem has required a TM halt
decider to report on things outside of its domain
under the false assumption that this never makes any
difference.
HHH(DDD)==0 and HHH1(DDD)==1 proves that it does
make a difference.
On 7/15/2025 6:33 AM, Richard Damon wrote:
On 7/14/25 11:13 PM, olcott wrote:
On 7/14/2025 9:40 PM, Richard Damon wrote:
On 7/14/25 11:50 AM, olcott wrote:No I am not. You are the one condemning your own soul to Hell.
On 7/14/2025 6:26 AM, Richard Damon wrote:
On 7/13/25 10:39 PM, olcott wrote:
On 7/13/2025 8:31 PM, Richard Damon wrote:
On 7/13/25 5:14 PM, olcott wrote:
On 7/13/2025 4:05 PM, joes wrote:
Am Sun, 13 Jul 2025 13:53:00 -0500 schrieb olcott:
On 7/13/2025 1:32 PM, joes wrote:Have you heard of paraphrasing? What IS the difference now? >>>>>>>>>>
Am Sun, 13 Jul 2025 09:14:56 -0500 schrieb olcott:It must perfectly 100% specific about DDD simulated by pure >>>>>>>>>>> simulator
On 7/13/2025 5:26 AM, joes wrote:I did answer in the affirmative. Where's the difference? >>>>>>>>>>>>
Am Sat, 12 Jul 2025 16:45:50 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/12/2025 4:25 PM, joes wrote:
Am Sat, 12 Jul 2025 14:54:28 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/12/2025 2:46 PM, joes wrote:
Am Sat, 12 Jul 2025 09:52:21 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 7/12/2025 5:49 AM, joes wrote:
DDD simulated by pure simulator HHH ever reach its "return" >>>>>>>>>>>>> instruction?Contrary to you I can handle multiple steps at a time. I >>>>>>>>>>>>>> already*You jumped too many steps ahead*No, I get it. If HHH were a pure simulator it would nest >>>>>>>>>>>>>>>> copies ofWe have to break it down to its simpler steps or don't >>>>>>>>>>>>>>>>> seem toHHH is not a pure simulator.That means that HHH reports itself as not being a >>>>>>>>>>>>>>>>>>>> decider.In other words you cannot understand that the >>>>>>>>>>>>>>>>>>> behavior of DDD
simulated by a pure simulator HHH would be an infinite >>>>>>>>>>>>>>>>>>> repetition of its first line?
have any understanding at all.
(1) If HHH was a pure simulator it would endlessly >>>>>>>>>>>>>>>>> simulate the first instruction of DDD and >>>>>>>>>>>>>>>>> never reach the
"return"
statement.
itself forever. A pure simulator running DDD as is would >>>>>>>>>>>>>>>> halt. If
DDD called a pure simulator, HHH would correctly return >>>>>>>>>>>>>>>> "doesn't
halt". And HHH running DDD does so incorrectly. You >>>>>>>>>>>>>>>> confuse that
with the second case.
There is only this one step:
If HHH was a pure simulator would DDD simulated by HHH >>>>>>>>>>>>>>> reach its own
"return" instruction?
I have another micro-step immediately after this one so >>>>>>>>>>>>>>> if you jump
ahead we have to keep repeating this step over and over >>>>>>>>>>>>>>> until we are
done with this step.
answered your question above. What's your next step? >>>>>>>>>>>>> No you answered a similar question not the exact same >>>>>>>>>>>>> question. Can
HHH NOT REACHING ITS OWN RETURN INSTRUCTION.
When I ask a YES or NO question say YES or NO don't freaking >>>>>>>>>>> change the
words *AT ALL* and then answer a different question.
Richard has been using that dishonest ploy to dodge the point >>>>>>>>>>> *FOR THREE
F-ING YEARS*
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
"simulated DDD never reaches its return instruction"
Wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
*Whenever I challenge you to show the details of how I am wrong* >>>>>>> just like Trump's TACO: Richard always chickens out.
Look at the trace of HHH1.
Changing the subject from DDD emulated by HHH
to DDD emulated by HHH1 is deception.
Then I guess you are admitting to that deception
You are the one that thinks that sadistic trollish head games
don't count as lies.
Really? What Have I said that is a LIE?
That you have denied that DDD emulated by each
HHH according to the semantics of the x86 language
cannot possibly reach its own emulated "ret"
instruction may get you condemned to Hell.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
YOU are the one that began with the deception, and thus are
responsible for ALL your lies.
Another lie that could get you condemned to Hell.
YOU are the one that has refused to look at the actual truth, and the
refusal to look at truth is what condemns ones soul to Hell.
I use the semantics of the x86 language as the measure
of correct simulation.
TO you, actually being near the presence of God would be unbearably
painful and distructive, making the horrors of hell actually a
blessing to you, at least you will get to continue to live in your lies.
Time will tell who smells like Hell.
On Tue, 15 Jul 2025 07:42:56 -0400, Richard Damon wrote:
On 7/14/25 11:20 PM, olcott wrote:
On 7/14/2025 9:57 PM, Richard Damon wrote:Why do YOU think you can?
On 7/14/25 11:53 AM, olcott wrote:_DDD()
On 7/14/2025 6:37 AM, Richard Damon wrote:Right, but the OBJECT that measures that it the exectution of the
On 7/13/25 10:46 PM, olcott wrote:Reaching a final halt state <is> the definition of halting.
On 7/13/2025 8:33 PM, Richard Damon wrote:Which isn't the definition of Non-Halting,
On 7/13/25 4:43 PM, olcott wrote:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:But since your DD by your own admission is a category error for a >>>>>>>> halt decider, as you have specifically stated it isn't a program >>>>>>>> as the input doesn't include the code of the specific HHH that it >>>>>>>> calls, you proof is just invalid.
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH according to >>>>>>>>>>>>>>> the semantics of the C programming language cannot possibly >>>>>>>>>>>>>>> reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction >>>>>>>>>>>>>> as to be near valuless.
It is really weird that you are calling a 100% complete >>>>>>>>>>>>> concrete specification "a low level of abstraction". That >>>>>>>>>>>>> HHH(DD) correctly determines that DD simulated by HHH cannot >>>>>>>>>>>>> possibly halt is a proven fact.
A complete concrete specification would necessarily include a >>>>>>>>>>>> description of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to >>>>>>>>>> say what you mean by an "x86 emulator". The name you give it is >>>>>>>>>> irrelevant
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping >>>>>>>>>>>> tiny pieces out of it and dealing with those. The proof you >>>>>>>>>>>> claim to refute has no notion of simulation, for example; it >>>>>>>>>>>> doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function
returns true or false, i.e. whether it specifies non halting >>>>>>>>>> behaviour.
The proof is purported to prove THAT DD is an undecidable input >>>>>>>>> for HHH. This is its counter example refuting the claim that a >>>>>>>>> universal halt decider can exist.
Sorry, all you proved is that you don't know what you are talking >>>>>>>> about.
That you keep trying to get away with refuting this easily verified >>>>>>> fact says a about about you
_DDD()
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 // push DDD >>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH [0000219f] >>>>>>> 83c404 add esp,+04 [000021a2] 5d pop ebp
[000021a3] c3 ret Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated according to the >>>>>>> semantics of the x86 language by some HHH, no DDD ever reaches its >>>>>>> "ret" instruction.
Program, or a complete simulation.
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 // push DDD [0000219a]
e833f4ffff call 000015d2 // call HHH [0000219f] 83c404 add
esp,+04 [000021a2] 5d pop ebp [000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated according to the
semantics of the x86 language by some HHH, no DDD ever reaches its
"ret" instruction.
Do you really think that you can get away with disagreeing with the x86
language?
Your above "Input" can be simulated past the instruction at 0000219A
because we lack the data of what is next.
Your problem is you started with the lie to yourself that you could
change the rules, and thus made yourself into a pathological liar that
has just lost the rules of the game.
In this case, your problem is you tried to redefine what non-halting
means, becuase your mind just can't handle the actual definition, and
some of its consequences. Partial emulations, by themselves, NEVER
define a program to be non-halting, only complete execution or complete
simulation. PERIOD.
Sorry, you just proved you are an idiot that has brainwashed himself and
apparently lost the key to get out.
No. Partial simulation is a perfectly valid approach for a partial decider.
/Flibble
On 7/15/2025 6:42 AM, Richard Damon wrote:
On 7/14/25 11:20 PM, olcott wrote:
On 7/14/2025 9:57 PM, Richard Damon wrote:
On 7/14/25 11:53 AM, olcott wrote:
On 7/14/2025 6:37 AM, Richard Damon wrote:
On 7/13/25 10:46 PM, olcott wrote:Reaching a final halt state <is> the definition of halting.
On 7/13/2025 8:33 PM, Richard Damon wrote:
On 7/13/25 4:43 PM, olcott wrote:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of
abstraction as to be near
valuless.
It is really weird that you are calling a 100% complete >>>>>>>>>>>>> concrete specification "a low level of abstraction". >>>>>>>>>>>>> That HHH(DD) correctly determines that DD simulated by >>>>>>>>>>>>> HHH cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include >>>>>>>>>>>> a description
of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to >>>>>>>>>> say what
you mean by an "x86 emulator". The name you give it is
irrelevant
But my point was that rather than
sticking to the abstract nature of the proof, you're
chipping tiny pieces
out of it and dealing with those. The proof you claim to >>>>>>>>>>>> refute has no
notion of simulation, for example; it doesn't need it.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
The word "correctly" is fully redundant there.
The proof does not state whether the constructed function
returns true or
false, i.e. whether it specifies non halting behaviour.
The proof is purported to prove THAT DD is an undecidable
input for HHH. This is its counter example refuting the
claim that a universal halt decider can exist.
But since your DD by your own admission is a category error for >>>>>>>> a halt decider, as you have specifically stated it isn't a
program as the input doesn't include the code of the specific
HHH that it calls, you proof is just invalid.
Sorry, all you proved is that you don't know what you are
talking about.
That you keep trying to get away with refuting
this easily verified fact says a about about you
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
Which isn't the definition of Non-Halting,
Right, but the OBJECT that measures that it the exectution of the
Program, or a complete simulation.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
Do you really think that you can get away with
disagreeing with the x86 language?
Why do YOU think you can?
Your above "Input" can be simulated past the instruction at 0000219A
because we lack the data of what is next.
MAYBE YOU ARE A DAMNED LIAR AND NOT JUST A LIAR.
ALTERNATIVELY YOU HAVE DEMENTIA THAT PREVENTS
YOU FROM REMEMBERING WHAT WAS SAID FROM ONE POST
TO THE NEXT.
On 7/15/2025 6:38 AM, Richard Damon wrote:
On 7/14/25 11:17 PM, olcott wrote:
On 7/14/2025 9:53 PM, Richard Damon wrote:
On 7/14/25 11:13 AM, olcott wrote:
On 7/14/2025 8:54 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 19:13:18 -0400, Richard Damon wrote:
On 7/12/25 8:48 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 08:36:55 -0400, Richard Damon wrote:
On 7/12/25 8:30 AM, Mr Flibble wrote:
On Sat, 12 Jul 2025 08:20:59 -0400, Richard Damon wrote:
On 7/12/25 12:42 AM, olcott wrote:
On 7/11/2025 6:34 PM, Richard Damon wrote:In otherwords, you let an existing program do most of the >>>>>>>>>>> work, and
On 7/10/25 10:30 AM, olcott wrote:What of kind of systems did you work with?
On 7/10/2025 6:24 AM, Fred. Zwarts wrote:So? I started programming for pay in 1974, where as an >>>>>>>>>>>>> undergraduate I was using my programming from High School >>>>>>>>>>>>> to build
Op 09.jul.2025 om 14:54 schreef olcott:>>Exactly what is your professional programming experience? >>>>>>>>>>>>>> I have
One of these "errors" was that HHH cannot simulate >>>>>>>>>>>>>>>> itself at
all.
As usual you twist the words of your reviewers.
The claim was that no HHH can simulate itself correctly >>>>>>>>>>>>>>> *up to
the end*.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf Is the full >>>>>>>>>>>>>>>> execution trace ofAnd it also proves my claim that HHH did not simulate itself >>>>>>>>>>>>>>> correctly *up to the end*.
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>>
20 years in C++ and became a professional programmer in 1986. >>>>>>>>>>>>>>
Data Analsys programs, an inter-computer link to make a >>>>>>>>>>>>> computer
with a vector graphics dispaly usable by the main frame, >>>>>>>>>>>>> and the
OS and data collection programs for a laboratory.
In 1982, with my MASTERS degree, I was employed to write >>>>>>>>>>>>> programs,
as well as design hardware for an industrial firm.
It seems I have many years over you, and it sounds like I >>>>>>>>>>>>> may have
well written more programs than you have.
I started using C from K&R in the late 70s and C++ using >>>>>>>>>>>>> Cfront in
the mid 80s. (so like 40 years of experience).
I programmed AutoCAD in C++ creating new architectural >>>>>>>>>>>> engineering
automations. This was mostly analytical geometry. I worked >>>>>>>>>>>> in C++
and some C for the last 22 years. I worked on NPOESS
https://en.wikipedia.org/wiki/NPOESS for Northrup Grumman >>>>>>>>>>>
you added some fonctionality to it.
As to NPOESS, just "working on it" doesn't give much idea of >>>>>>>>>>> your
responsibilities, and tha fact that it was a FAILED system, >>>>>>>>>>> scrubbed
due to progtram issues doesn't say much for what you can do. >>>>>>>>>>>
It seems that in all your work, you might never have produced an >>>>>>>>>>> actual "program", only pieces of systems, which explains why you >>>>>>>>>>> don't understand what a "program" actually is.
Most of my work has been in embedded system, where I built the >>>>>>>>>>> hardware around a processor for some function, and then fully >>>>>>>>>>> programmed the processor from the ground up to complete the >>>>>>>>>>> product.
I also wrote PC side support for control of the embedded >>>>>>>>>>> application.
As part of this, I have produced a large library of support >>>>>>>>>>> functions to allow the building of similar programs by
others, which
has become the basis for much of the work produced at the >>>>>>>>>>> company I
work for.
I will note that I am STILL active in the profession, and now >>>>>>>>>>> spend
part of my time training others in the company to improve their >>>>>>>>>>> skills, while it seems you are no longer at work, and I doubt >>>>>>>>>>> you
get many calls asking for advice about how to do things.
Your personality really is quite obnoxious isn't it, Damon? >>>>>>>>>>
/Flibble
HE asked the question.
HE claims to be an expert, with no actual credentials and calls >>>>>>>>> me the
one who doesn't know what I am doing, even though I am much better >>>>>>>>> trained then him.
You and He are the "obnoxious" ones, that need to use ad hominim >>>>>>>>> attacks as you have no factual grounds to refute the errors
pointed
out.
You make more ad hominum attacks than anyone else on here, Damon. >>>>>>>>
/Flibble
Really? When have I ever said someone was wrong just because they >>>>>>> were
stupid or some other aspect of them.
I have always pointed out the factual and logical reason they were >>>>>>> wrong, and then pointed out that the repeated saying of that
error shows
they are stupid.
I guess you don't know what ad hominum means, perhaps because you >>>>>>> are
just too stupid. (Note, that statement is not ad hominum, as I
don't use
your stupidity as the arguement for your error, but that the error >>>>>>> demonstrates the stupidity).
Ad hominem (often misspelled as "ad hominum" in the statement) is a >>>>>> logical fallacy where an argument is rebutted by attacking the
character,
motive, or other attribute of the person making it, rather than
addressing
the substance of the argument itself. It's essentially dismissing
a claim
based on who is saying it, not on its merits.
In the described approach—pointing out factual and logical flaws in >>>>>> someone's claim first, then concluding that repeated errors indicate >>>>>> stupidity—that sequence isn't inherently ad hominem. The core
rebuttal
targets the argument's content (facts and logic), and the insult
follows
as a separate judgment on the person's pattern of behavior.
Insults alone
don't constitute ad hominem if they're not used as the basis for
rejecting
the argument. For example:
- Ad hominem: "Your point about climate change is wrong because
you're an
idiot."
- Not ad hominem: "Your point about climate change is wrong
because the
data shows X, Y, and Z are inaccurate—and repeating such basic errors >>>>>> suggests you're not thinking critically."
However, the specific example given ("I guess you don't know what ad >>>>>> hominum means, perhaps because you are just too stupid") veers
closer to
ad hominem territory. It asserts an error (not knowing the meaning) >>>>>> without providing any factual or logical explanation for why the
understanding is incorrect. Instead, it immediately attributes the >>>>>> supposed error to stupidity as the explanatory cause. This implies >>>>>> the
dismissal is rooted in the personal attack rather than a substantive >>>>>> refutation. The parenthetical note claims the error demonstrates the >>>>>> stupidity, but the statement doesn't actually demonstrate or
explain the
error—it assumes it and jumps to the insult. To avoid ad hominem >>>>>> entirely,
the logical rebuttal should come first and stand on its own, with any >>>>>> personal commentary clearly separated and not presented as the
reason for
the disagreement.
If the goal is productive discussion, avoiding insults altogether is >>>>>> usually better, as they can escalate conflicts without adding
value. If
this is part of a broader conversation, providing the full context >>>>>> could
help refine the analysis.
He is a troll not interested in an honest dialogue.
No, you meet the definition of the Troll.
Try using actual facts and respond.
The insults only come when you just blindly repeat you errors.
I prove my point about HHH(DDD) with simple reasoning that
anyone that is an expert at the C or C++ programming language
understands as dead obviously correct. You deny it anyway thus
condemning your own soul to Hell.
No, your "logic" is based on deception and changing definitions.
When the HP requires a TM halt decider to report on
elements that are not in its domain this requirement
is proved to be incorrect.
It is based on LIES.
If there is any liar here it is not me.
If your qualifications are as you stated then we
cannot take your disagreement with the verified
facts that I presented as any honest mistake.
Alternatively you lied about your qualifications.
It is based on the idea that non-programs can be treated like programs.
HHH is the test program and does not test itself.
DDD is the program under test.
HHH(DDD) does correctly determine that DDD simulated
by HHH cannot possibly terminate normally.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The official "received" view of the correct value that
HHH(DD) can return is "no one knows". AKA input DD to
decider HHH proves the undecidability of the HP.
It is based on the idea that a finite simulation is the same as an
unbounded one.
Lines 996 through 1006
https://github.com/plolcott/x86utm/blob/master/Halt7.c
correctly detect that that an unbounded emulation would
never terminate. That you can't understand that I am correct
is no actual rebuttal at all.
IT is based on the idea that different programs can be treated the same.
IT is based on a failed understanding of the basics of the field.
That you do not understand the details of recognizing
non-terminating recursive behavior patterns is your
ignorance and not my error.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How does the above DDD emulated by HHH reach
its own final state at machine address 000021a3?
Sorry, you haven't proven anything except that you are just a liar
that can't prove anything,
(1) You know that I am not even mistaken.
(2) Therefore calling me a liar is a lie.
You must really believe that sadistic trollish head
games don't count as a Revelations 21:8 lie.
because you fail at the first step of trying to build a proof, the
stating of the ACTUAL accepted premises that you are going to derive
you proof from.
HHH(DD) DOES REPORT ON THE BEHAVIOR SPECIFIED BY ITS INPUT.
THAT YOU CANNOT SHOW OTHERWISE PROVES THAT YOU ARE A LIAR.
Truth that is "obvious" is often just wrong, which is why true
logitians start with enumerated accepted facts and then use accepted
logic operations to get to their goal.
Using what seem "obvious" has been the root of most errors in history,
things like the proof that pi is 4.
Sorry, all you are doing is proving that you don't qualify as a
logical being.
On 7/15/25 7:48 AM, Mr Flibble wrote:
On Tue, 15 Jul 2025 07:42:56 -0400, Richard Damon wrote:
On 7/14/25 11:20 PM, olcott wrote:
On 7/14/2025 9:57 PM, Richard Damon wrote:Why do YOU think you can?
On 7/14/25 11:53 AM, olcott wrote:_DDD()
On 7/14/2025 6:37 AM, Richard Damon wrote:Right, but the OBJECT that measures that it the exectution of the
On 7/13/25 10:46 PM, olcott wrote:Reaching a final halt state <is> the definition of halting.
On 7/13/2025 8:33 PM, Richard Damon wrote:Which isn't the definition of Non-Halting,
On 7/13/25 4:43 PM, olcott wrote:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:But since your DD by your own admission is a category error for >>>>>>>>> a halt decider, as you have specifically stated it isn't a
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH according >>>>>>>>>>>>>>>> to the semantics of the C programming language cannot >>>>>>>>>>>>>>>> possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of
abstraction as to be near valuless.
It is really weird that you are calling a 100% complete >>>>>>>>>>>>>> concrete specification "a low level of abstraction". That >>>>>>>>>>>>>> HHH(DD) correctly determines that DD simulated by HHH >>>>>>>>>>>>>> cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include >>>>>>>>>>>>> a description of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to >>>>>>>>>>> say what you mean by an "x86 emulator". The name you give it >>>>>>>>>>> is irrelevant
But my point was that rather than
sticking to the abstract nature of the proof, you're >>>>>>>>>>>>> chipping tiny pieces out of it and dealing with those. The >>>>>>>>>>>>> proof you claim to refute has no notion of simulation, for >>>>>>>>>>>>> example; it doesn't need it.
*Not at all there are two pieces*The word "correctly" is fully redundant there.
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this. >>>>>>>>>>>
The proof does not state whether the constructed function >>>>>>>>>>> returns true or false, i.e. whether it specifies non halting >>>>>>>>>>> behaviour.
The proof is purported to prove THAT DD is an undecidable input >>>>>>>>>> for HHH. This is its counter example refuting the claim that a >>>>>>>>>> universal halt decider can exist.
program as the input doesn't include the code of the specific >>>>>>>>> HHH that it calls, you proof is just invalid.
Sorry, all you proved is that you don't know what you are
talking about.
That you keep trying to get away with refuting this easily
verified fact says a about about you
_DDD()
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 // push DDD >>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH [0000219f] >>>>>>>> 83c404 add esp,+04 [000021a2] 5d pop ebp
[000021a3] c3 ret Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated according to >>>>>>>> the semantics of the x86 language by some HHH, no DDD ever
reaches its "ret" instruction.
Program, or a complete simulation.
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH [0000219f]
83c404 add esp,+04 [000021a2] 5d pop ebp
[000021a3] c3 ret Size in bytes:(0018) [000021a3] >>>>
When one or more instructions of DDD are emulated according to the
semantics of the x86 language by some HHH, no DDD ever reaches its
"ret" instruction.
Do you really think that you can get away with disagreeing with the
x86 language?
Your above "Input" can be simulated past the instruction at 0000219A
because we lack the data of what is next.
Your problem is you started with the lie to yourself that you could
change the rules, and thus made yourself into a pathological liar that
has just lost the rules of the game.
In this case, your problem is you tried to redefine what non-halting
means, becuase your mind just can't handle the actual definition, and
some of its consequences. Partial emulations, by themselves, NEVER
define a program to be non-halting, only complete execution or
complete simulation. PERIOD.
Sorry, you just proved you are an idiot that has brainwashed himself
and apparently lost the key to get out.
No. Partial simulation is a perfectly valid approach for a partial
decider.
/Flibble
Yes, but not as the thing that defines that an input is non-halting.
You need to use the partial simulation to actually prove that the full correct simulation of that input would not halt. And that input doesn't change to use that correct simulator, it still calls the partial
simulator as that is what is in the input.
Note, the problem comes when you try to say that the "correct
simulation" must be done by the decider, as then it can't be a partial decider, and just stuck in a contradiction, thus making such a criteria invalid.
On 7/15/2025 8:51 PM, Richard Damon wrote:
On 7/15/25 7:48 AM, Mr Flibble wrote:
On Tue, 15 Jul 2025 07:42:56 -0400, Richard Damon wrote:
On 7/14/25 11:20 PM, olcott wrote:
On 7/14/2025 9:57 PM, Richard Damon wrote:
Been doing that for three years and you keep dishonestly pretending thatWhy do YOU think you can?Right, but the OBJECT that measures that it the exectution of theWhen one or more instructions of DDD are emulated according to the
Program, or a complete simulation.
semantics of the x86 language by some HHH, no DDD ever reaches its
"ret" instruction.
Do you really think that you can get away with disagreeing with the
x86 language?
Your above "Input" can be simulated past the instruction at 0000219A
because we lack the data of what is next.
Your problem is you started with the lie to yourself that you could
change the rules, and thus made yourself into a pathological liar
that has just lost the rules of the game.
In this case, your problem is you tried to redefine what non-halting
means, becuase your mind just can't handle the actual definition, and
some of its consequences. Partial emulations, by themselves, NEVER
define a program to be non-halting, only complete execution or
complete simulation. PERIOD.
No. Partial simulation is a perfectly valid approach for a partial
decider.
Yes, but not as the thing that defines that an input is non-halting.
You need to use the partial simulation to actually prove that the full
correct simulation of that input would not halt. And that input doesn't
change to use that correct simulator, it still calls the partial
simulator as that is what is in the input.
you don't see this.
On 7/16/2025 10:42 AM, joes wrote:Then it isn't DDD. DDD calls HHH, which is not a pure simulator.
Am Wed, 16 Jul 2025 10:18:52 -0500 schrieb olcott:
On 7/15/2025 8:51 PM, Richard Damon wrote:
On 7/15/25 7:48 AM, Mr Flibble wrote:
On Tue, 15 Jul 2025 07:42:56 -0400, Richard Damon wrote:
Not when DDD calls this pure simulator.Been doing that for three years and you keep dishonestly pretendingWhy do YOU think you can?
Your above "Input" can be simulated past the instruction at
0000219A because we lack the data of what is next.
Your problem is you started with the lie to yourself that you could >>>>>> change the rules, and thus made yourself into a pathological liar
that has just lost the rules of the game.
In this case, your problem is you tried to redefine what
non-halting means, becuase your mind just can't handle the actual
definition, and some of its consequences. Partial emulations, by
themselves, NEVER define a program to be non-halting, only complete >>>>>> execution or complete simulation. PERIOD.
No. Partial simulation is a perfectly valid approach for a partial
decider.
Yes, but not as the thing that defines that an input is non-halting.
You need to use the partial simulation to actually prove that the
full correct simulation of that input would not halt. And that input
doesn't change to use that correct simulator, it still calls the
partial simulator as that is what is in the input.
that you don't see this.
No, the full, i.e. unaborted simulation of DDD by any pure simulator
would halt.
On 7/16/2025 10:42 AM, joes wrote:
Am Wed, 16 Jul 2025 10:18:52 -0500 schrieb olcott:
On 7/15/2025 8:51 PM, Richard Damon wrote:
On 7/15/25 7:48 AM, Mr Flibble wrote:
On Tue, 15 Jul 2025 07:42:56 -0400, Richard Damon wrote:
On 7/14/25 11:20 PM, olcott wrote:
On 7/14/2025 9:57 PM, Richard Damon wrote:
Been doing that for three years and you keep dishonestly pretending that >>> you don't see this.Why do YOU think you can?Right, but the OBJECT that measures that it the exectution of the >>>>>>>> Program, or a complete simulation.When one or more instructions of DDD are emulated according to the >>>>>>> semantics of the x86 language by some HHH, no DDD ever reaches its >>>>>>> "ret" instruction.
Do you really think that you can get away with disagreeing with the >>>>>>> x86 language?
Your above "Input" can be simulated past the instruction at 0000219A >>>>>> because we lack the data of what is next.
Your problem is you started with the lie to yourself that you could >>>>>> change the rules, and thus made yourself into a pathological liar
that has just lost the rules of the game.
In this case, your problem is you tried to redefine what non-halting >>>>>> means, becuase your mind just can't handle the actual definition, and >>>>>> some of its consequences. Partial emulations, by themselves, NEVER >>>>>> define a program to be non-halting, only complete execution or
complete simulation. PERIOD.
No. Partial simulation is a perfectly valid approach for a partial
decider.
Yes, but not as the thing that defines that an input is non-halting.
You need to use the partial simulation to actually prove that the full >>>> correct simulation of that input would not halt. And that input doesn't >>>> change to use that correct simulator, it still calls the partial
simulator as that is what is in the input.
No, the full, i.e. unaborted simulation of DDD by any pure simulator
would halt.
Not when DDD calls this pure simulator.
On Tue, 15 Jul 2025 21:51:19 -0400, Richard Damon wrote:
On 7/15/25 7:48 AM, Mr Flibble wrote:
On Tue, 15 Jul 2025 07:42:56 -0400, Richard Damon wrote:
On 7/14/25 11:20 PM, olcott wrote:
On 7/14/2025 9:57 PM, Richard Damon wrote:Why do YOU think you can?
On 7/14/25 11:53 AM, olcott wrote:_DDD()
On 7/14/2025 6:37 AM, Richard Damon wrote:Right, but the OBJECT that measures that it the exectution of the
On 7/13/25 10:46 PM, olcott wrote:Reaching a final halt state <is> the definition of halting.
On 7/13/2025 8:33 PM, Richard Damon wrote:Which isn't the definition of Non-Halting,
On 7/13/25 4:43 PM, olcott wrote:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:But since your DD by your own admission is a category error for >>>>>>>>>> a halt decider, as you have specifically stated it isn't a >>>>>>>>>> program as the input doesn't include the code of the specific >>>>>>>>>> HHH that it calls, you proof is just invalid.
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH according >>>>>>>>>>>>>>>>> to the semantics of the C programming language cannot >>>>>>>>>>>>>>>>> possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of >>>>>>>>>>>>>>>> abstraction as to be near valuless.
It is really weird that you are calling a 100% complete >>>>>>>>>>>>>>> concrete specification "a low level of abstraction". That >>>>>>>>>>>>>>> HHH(DD) correctly determines that DD simulated by HHH >>>>>>>>>>>>>>> cannot possibly halt is a proven fact.
A complete concrete specification would necessarily include >>>>>>>>>>>>>> a description of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to >>>>>>>>>>>> say what you mean by an "x86 emulator". The name you give it >>>>>>>>>>>> is irrelevant
But my point was that rather than
sticking to the abstract nature of the proof, you're >>>>>>>>>>>>>> chipping tiny pieces out of it and dealing with those. The >>>>>>>>>>>>>> proof you claim to refute has no notion of simulation, for >>>>>>>>>>>>>> example; it doesn't need it.
*Not at all there are two pieces*The word "correctly" is fully redundant there.
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this. >>>>>>>>>>>>
The proof does not state whether the constructed function >>>>>>>>>>>> returns true or false, i.e. whether it specifies non halting >>>>>>>>>>>> behaviour.
The proof is purported to prove THAT DD is an undecidable input >>>>>>>>>>> for HHH. This is its counter example refuting the claim that a >>>>>>>>>>> universal halt decider can exist.
Sorry, all you proved is that you don't know what you are
talking about.
That you keep trying to get away with refuting this easily
verified fact says a about about you
_DDD()
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 // push DDD >>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH [0000219f] >>>>>>>>> 83c404 add esp,+04 [000021a2] 5d pop ebp
[000021a3] c3 ret Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated according to >>>>>>>>> the semantics of the x86 language by some HHH, no DDD ever
reaches its "ret" instruction.
Program, or a complete simulation.
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH [0000219f] >>>>> 83c404 add esp,+04 [000021a2] 5d pop ebp
[000021a3] c3 ret Size in bytes:(0018) [000021a3] >>>>>
When one or more instructions of DDD are emulated according to the
semantics of the x86 language by some HHH, no DDD ever reaches its
"ret" instruction.
Do you really think that you can get away with disagreeing with the
x86 language?
Your above "Input" can be simulated past the instruction at 0000219A
because we lack the data of what is next.
Your problem is you started with the lie to yourself that you could
change the rules, and thus made yourself into a pathological liar that >>>> has just lost the rules of the game.
In this case, your problem is you tried to redefine what non-halting
means, becuase your mind just can't handle the actual definition, and
some of its consequences. Partial emulations, by themselves, NEVER
define a program to be non-halting, only complete execution or
complete simulation. PERIOD.
Sorry, you just proved you are an idiot that has brainwashed himself
and apparently lost the key to get out.
No. Partial simulation is a perfectly valid approach for a partial
decider.
/Flibble
Yes, but not as the thing that defines that an input is non-halting.
You need to use the partial simulation to actually prove that the full
correct simulation of that input would not halt. And that input doesn't
change to use that correct simulator, it still calls the partial
simulator as that is what is in the input.
Note, the problem comes when you try to say that the "correct
simulation" must be done by the decider, as then it can't be a partial
decider, and just stuck in a contradiction, thus making such a criteria
invalid.
At best a word salad, at worst, gibberish. You are simply wrong and fractally so.
/Flibble
On 7/15/2025 8:51 PM, Richard Damon wrote:
On 7/15/25 7:48 AM, Mr Flibble wrote:
On Tue, 15 Jul 2025 07:42:56 -0400, Richard Damon wrote:
On 7/14/25 11:20 PM, olcott wrote:
On 7/14/2025 9:57 PM, Richard Damon wrote:Why do YOU think you can?
On 7/14/25 11:53 AM, olcott wrote:_DDD()
On 7/14/2025 6:37 AM, Richard Damon wrote:Right, but the OBJECT that measures that it the exectution of the
On 7/13/25 10:46 PM, olcott wrote:Reaching a final halt state <is> the definition of halting.
On 7/13/2025 8:33 PM, Richard Damon wrote:Which isn't the definition of Non-Halting,
On 7/13/25 4:43 PM, olcott wrote:
On 7/7/2025 9:07 AM, Alan Mackenzie wrote:But since your DD by your own admission is a category error for a >>>>>>>>>> halt decider, as you have specifically stated it isn't a program >>>>>>>>>> as the input doesn't include the code of the specific HHH that it >>>>>>>>>> calls, you proof is just invalid.
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 4:23 PM, Alan Mackenzie wrote:[ .... ]
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ .... ]
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH according to >>>>>>>>>>>>>>>>> the semantics of the C programming language cannot >>>>>>>>>>>>>>>>> possibly
reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction >>>>>>>>>>>>>>>> as to be near valuless.
It is really weird that you are calling a 100% complete >>>>>>>>>>>>>>> concrete specification "a low level of abstraction". That >>>>>>>>>>>>>>> HHH(DD) correctly determines that DD simulated by HHH cannot >>>>>>>>>>>>>>> possibly halt is a proven fact.
A complete concrete specification would necessarily include a >>>>>>>>>>>>>> description of what you mean by "simulation".
I specifically mean that this x86 machine code
Is emulated by an x86 emulator named HHH.
That's no adequate description. To make it so, you'd have to >>>>>>>>>>>> say what you mean by an "x86 emulator". The name you give >>>>>>>>>>>> it is
irrelevant
But my point was that rather than
sticking to the abstract nature of the proof, you're chipping >>>>>>>>>>>>>> tiny pieces out of it and dealing with those. The proof you >>>>>>>>>>>>>> claim to refute has no notion of simulation, for example; it >>>>>>>>>>>>>> doesn't need it.
*Not at all there are two pieces*The word "correctly" is fully redundant there.
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this. >>>>>>>>>>>>
The proof does not state whether the constructed function >>>>>>>>>>>> returns true or false, i.e. whether it specifies non halting >>>>>>>>>>>> behaviour.
The proof is purported to prove THAT DD is an undecidable input >>>>>>>>>>> for HHH. This is its counter example refuting the claim that a >>>>>>>>>>> universal halt decider can exist.
Sorry, all you proved is that you don't know what you are talking >>>>>>>>>> about.
That you keep trying to get away with refuting this easily
verified
fact says a about about you
_DDD()
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 // push DDD >>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH [0000219f] >>>>>>>>> 83c404 add esp,+04 [000021a2] 5d pop ebp
[000021a3] c3 ret Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated according to the >>>>>>>>> semantics of the x86 language by some HHH, no DDD ever reaches its >>>>>>>>> "ret" instruction.
Program, or a complete simulation.
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 // push DDD
[0000219a]
e833f4ffff call 000015d2 // call HHH [0000219f] 83c404
add
esp,+04 [000021a2] 5d pop ebp [000021a3] c3
ret
Size in bytes:(0018) [000021a3]
When one or more instructions of DDD are emulated according to the
semantics of the x86 language by some HHH, no DDD ever reaches its
"ret" instruction.
Do you really think that you can get away with disagreeing with the
x86
language?
Your above "Input" can be simulated past the instruction at 0000219A
because we lack the data of what is next.
Your problem is you started with the lie to yourself that you could
change the rules, and thus made yourself into a pathological liar that >>>> has just lost the rules of the game.
In this case, your problem is you tried to redefine what non-halting
means, becuase your mind just can't handle the actual definition, and
some of its consequences. Partial emulations, by themselves, NEVER
define a program to be non-halting, only complete execution or complete >>>> simulation. PERIOD.
Sorry, you just proved you are an idiot that has brainwashed himself
and
apparently lost the key to get out.
No. Partial simulation is a perfectly valid approach for a partial
decider.
/Flibble
Yes, but not as the thing that defines that an input is non-halting.
You need to use the partial simulation to actually prove that the full
correct simulation of that input would not halt. And that input
doesn't change to use that correct simulator, it still calls the
partial simulator as that is what is in the input.
Been doing that for three years and you keep
dishonestly pretending that you don't see this.
On 7/16/2025 12:29 PM, joes wrote:And because HHH would simulate DDD in recursive simulation.
Am Wed, 16 Jul 2025 10:47:09 -0500 schrieb olcott:
On 7/16/2025 10:42 AM, joes wrote:Then it isn't DDD. DDD calls HHH, which is not a pure simulator.
Am Wed, 16 Jul 2025 10:18:52 -0500 schrieb olcott:
On 7/15/2025 8:51 PM, Richard Damon wrote:
On 7/15/25 7:48 AM, Mr Flibble wrote:
On Tue, 15 Jul 2025 07:42:56 -0400, Richard Damon wrote:
Not when DDD calls this pure simulator.Been doing that for three years and you keep dishonestly pretendingWhy do YOU think you can?
Your above "Input" can be simulated past the instruction at
0000219A because we lack the data of what is next.
Your problem is you started with the lie to yourself that you could >>>>>>>> change the rules, and thus made yourself into a pathological liar >>>>>>>> that has just lost the rules of the game.
In this case, your problem is you tried to redefine what
non-halting means, becuase your mind just can't handle the actual >>>>>>>> definition, and some of its consequences. Partial emulations, by >>>>>>>> themselves, NEVER define a program to be non-halting, only complete >>>>>>>> execution or complete simulation. PERIOD.
No. Partial simulation is a perfectly valid approach for a partial >>>>>>> decider.
Yes, but not as the thing that defines that an input is non-halting. >>>>>> You need to use the partial simulation to actually prove that the
full correct simulation of that input would not halt. And that input >>>>>> doesn't change to use that correct simulator, it still calls the
partial simulator as that is what is in the input.
that you don't see this.
No, the full, i.e. unaborted simulation of DDD by any pure simulator
would halt.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Each element of the infinite set of functions
at machine address 000015d2 that emulates 0 to ∞
instructions of the above machine code never
reaches its emulated "ret" instruction final
halt state BECAUSE DDD CALLS EACH EMULATOR IN
RECURSIVE EMULATION.
On 7/17/2025 3:29 AM, Fred. Zwarts wrote:HHH is not a UTM.
Op 16.jul.2025 om 19:49 schreef olcott:
This is already evidence that simulation is not the right tool toIn other words you disagree that a simulation by a UTM is a correct
analyse the input.
measure of behavior. (A simulation by a UTM is defined to be a correct measure of behavior).
On 7/17/2025 3:29 AM, Fred. Zwarts wrote:
Op 16.jul.2025 om 19:49 schreef olcott:
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Each element of the infinite set of functions
at machine address 000015d2 that emulates 0 to ∞
instructions of the above machine code never
reaches its emulated "ret" instruction final
halt state BECAUSE DDD CALLS EACH EMULATOR IN
RECURSIVE EMULATION.
And because HHH would simulate DDD in recursive simulation.The input to HHH(DDD) specifies recursive emulation.
HHH cooperates with DDD to create a recursion. Without HHH starting a
new simulation, there would not be a recursion.
This is already evidence that simulation is not the right tool to
analyse the input.
In other words you disagree that a simulation by a UTM
is a correct measure of behavior. (A simulation by a UTM
is defined to be a correct measure of behavior).
But HHH does abort. So, there is no infinite recursion. So, there is a
final halt state. But the abort does not help to reach that final halt
state. HHH still fails to reach it.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Each element of the infinite set of functions
at machine address 000015d2 that emulates 0 to ∞
instructions of the above machine code never
reaches its emulated "ret" instruction final
halt state BECAUSE DDD CALLS EACH EMULATOR IN
RECURSIVE EMULATION.
*ChatGPT agrees and provides the reasoning why it agrees* https://chatgpt.com/share/6877f09c-7b18-8011-b075-ea3671e57886
This illustrates that simulation is not the right tool for this input.
Disagreeing with the definition of a UTM is incorrect.
Each element in the infinite set fails to reach the final halt state.
Because it remains stuck in recursive emulation.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
Infinite_Recursion() correctly simulated bu HHH also
cannot possibly reach its own simulated "return"
statement final halt state. Not possibly reaching
final halt state is the correct measure on non-halting
for both HHH(Infinite_Recursion) and HHH(DDD).
There is a final halt state for each of them, but the all fail to
reach it. (Of course the very different HHH that does not abort at
all, has no final halt state, so it fails as well.)
On 7/17/2025 8:57 AM, joes wrote:
Am Thu, 17 Jul 2025 08:47:16 -0500 schrieb olcott:
On 7/17/2025 3:29 AM, Fred. Zwarts wrote:HHH is not a UTM.
Op 16.jul.2025 om 19:49 schreef olcott:
This is already evidence that simulation is not the right tool toIn other words you disagree that a simulation by a UTM is a correct
analyse the input.
measure of behavior. (A simulation by a UTM is defined to be a correct
measure of behavior).
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Each element of the infinite set of functions
at machine address 000015d2 that emulates 0 to ∞
instructions of the above machine code never
reaches its emulated "ret" instruction final
halt state BECAUSE DDD CALLS EACH EMULATOR IN
RECURSIVE EMULATION.
*ChatGPT agrees and provides the reasoning why it agrees* https://chatgpt.com/share/6877f09c-7b18-8011-b075-ea3671e57886
On 7/17/2025 3:29 AM, Fred. Zwarts wrote:
Op 16.jul.2025 om 19:49 schreef olcott:
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Each element of the infinite set of functions
at machine address 000015d2 that emulates 0 to ∞
instructions of the above machine code never
reaches its emulated "ret" instruction final
halt state BECAUSE DDD CALLS EACH EMULATOR IN
RECURSIVE EMULATION.
And because HHH would simulate DDD in recursive simulation.The input to HHH(DDD) specifies recursive emulation.
HHH cooperates with DDD to create a recursion. Without HHH starting a
new simulation, there would not be a recursion.
This is already evidence that simulation is not the right tool to
analyse the input.
In other words you disagree that a simulation by a UTM
is a correct measure of behavior. (A simulation by a UTM
is defined to be a correct measure of behavior).
But HHH does abort. So, there is no infinite recursion. So, there is a
final halt state. But the abort does not help to reach that final halt
state. HHH still fails to reach it.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Each element of the infinite set of functions
at machine address 000015d2 that emulates 0 to ∞
instructions of the above machine code never
reaches its emulated "ret" instruction final
halt state BECAUSE DDD CALLS EACH EMULATOR IN
RECURSIVE EMULATION.
*ChatGPT agrees and provides the reasoning why it agrees* https://chatgpt.com/share/6877f09c-7b18-8011-b075-ea3671e57886
This illustrates that simulation is not the right tool for this input.
Disagreeing with the definition of a UTM is incorrect.
Each element in the infinite set fails to reach the final halt state.
Because it remains stuck in recursive emulation.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
Infinite_Recursion() correctly simulated bu HHH also
cannot possibly reach its own simulated "return"
statement final halt state. Not possibly reaching
final halt state is the correct measure on non-halting
for both HHH(Infinite_Recursion) and HHH(DDD).
There is a final halt state for each of them, but the all fail to
reach it. (Of course the very different HHH that does not abort at
all, has no final halt state, so it fails as well.)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 00:08:16 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,566 |