They all say that HHH must report on the behavior of
direct execution of DDD()
yet never bother to notice
that the directly executed DDD() is the caller of HHH(DDD).
void DDD()
{
 HHH(DDD); // When DDD calls HHH(DDD) this HHH is not
 return;  // accountable for the behavior of its caller
}
On the other hand HHH(DDD) is accountable for the
behavior that its actual input actually specifies.
HHH(DDD) simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
<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
They all say that HHH must report on the behavior of
direct execution of DDD()
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
On 6/3/2025 8:54 PM, dbush wrote:
On 6/3/2025 5:39 PM, olcott wrote:
They all say that HHH must report on the behavior of
direct execution of DDD()
Because that's what we want to know about:
Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
yet never bother to notice
that the directly executed DDD() is the caller of HHH(DDD).
That doesn't change the fact that we want to know if any arbitrary
algorithm X with input Y will halt when executed directly, and we want
an H that tell us that in *all* possible cases.
void DDD()
{
  HHH(DDD); // When DDD calls HHH(DDD) this HHH is not
  return;  // accountable for the behavior of its caller
}
It is accountable when that's what we're asking for.
That is just not the way that computation actually works.
On the other hand HHH(DDD) is accountable for the
behavior that its actual input actually specifies.
Which is the behavior of the algorithm DDD consisting of the fixed
code of the function DDD, the fixed code of the function HHH, and the
fixed code of everything function HHH calls down to the OS level, and
behavior is halting.
HHH(DDD) simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
<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
And again you lie by implying that Sipser agrees with your meaning of
the above when the fact is that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:
I exchanged emails with him about this. He does not agree withanything
substantive that PO has written. I won't quote him, as I don't have
permission, but he was, let's say... forthright, in his reply to me.
The words only have one single correct meaning.
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation
happens to be DDD() it must report about another behaviour instead
of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not
mentioned what is irrelevant to whatever they said. In particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement that
a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
int main()
{
 DDD(); // calls HHH(DDD)
}
void DDD()
{
 HHH(DDD);
 return;
}
*The input to HHH(DDD) specifies*
 HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
Never reaching the "return" instruction final halt state.
On 6/4/2025 10:41 PM, dbush wrote:
On 6/4/2025 11:32 PM, olcott wrote:
On 6/4/2025 9:56 PM, dbush wrote:
On 6/4/2025 10:44 PM, olcott wrote:
On 6/4/2025 9:13 PM, dbush wrote:
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting >>>>>>>>>> decider when it reports) must report whether the direct execution >>>>>>>>>> of the computation asked about terminates. Unless that
computation
happens to be DDD() it must report about another behaviour >>>>>>>>>> instead
of DDD().
yet never bother to notice that the directly executed DDD() is >>>>>>>>>>> the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they >>>>>>>>>> have not
mentioned what is irrelevant to whatever they said. In
particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement >>>>>>>>>> that
a halting decider must report about a direct exection of the >>>>>>>>>> computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the >>>>>>>> direct executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
But unlike Russel's Paradox, which showed a contradiction in the
axioms of naive set theory, there is no contradiction in the
axioms of computation theory. It follows from those axioms that
no H exists that performs the below mapping, as you have
*explicitly* agreed.
int main()
{
  DDD(); // comp theory does not allow HHH to
}Â Â Â Â Â Â Â // report on the behavior of its caller.
int main()
{
   DDD();    // this
   HHH(DDD); // is not the caller of this: this
is }Â Â Â Â Â Â Â Â Â Â Â Â Â // asking what the above will do
That is just not the way that computation actually works.
Sure it is. We don't care how the mapping is generated, only that it
is generated.
There is not enough information in the input to
know how the caller works.
Also there is not enough information in any integer
to predict who the president will be.
char* WhatIsTheNameOfThePresidentIn2030(int x);
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation
happens to be DDD() it must report about another behaviour instead
of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not
mentioned what is irrelevant to whatever they said. In particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement that
a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation
happens to be DDD() it must report about another behaviour instead
of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not
mentioned what is irrelevant to whatever they said. In particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement that
a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the direct
executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation
happens to be DDD() it must report about another behaviour instead
of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not
mentioned what is irrelevant to whatever they said. In particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement that
a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the direct
executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
But unlike Russel's Paradox, which showed a contradiction in the axioms
of naive set theory, there is no contradiction in the axioms of
computation theory.
On 6/4/2025 10:41 PM, dbush wrote:
On 6/4/2025 11:32 PM, olcott wrote:
On 6/4/2025 9:56 PM, dbush wrote:
On 6/4/2025 10:44 PM, olcott wrote:
On 6/4/2025 9:13 PM, dbush wrote:
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting >>>>>>>>>> decider when it reports) must report whether the direct execution >>>>>>>>>> of the computation asked about terminates. Unless that
computation
happens to be DDD() it must report about another behaviour >>>>>>>>>> instead
of DDD().
yet never bother to notice that the directly executed DDD() is >>>>>>>>>>> the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they >>>>>>>>>> have not
mentioned what is irrelevant to whatever they said. In
particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement >>>>>>>>>> that
a halting decider must report about a direct exection of the >>>>>>>>>> computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the >>>>>>>> direct executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
But unlike Russel's Paradox, which showed a contradiction in the
axioms of naive set theory, there is no contradiction in the
axioms of computation theory. It follows from those axioms that
no H exists that performs the below mapping, as you have
*explicitly* agreed.
int main()
{
  DDD(); // comp theory does not allow HHH to
}Â Â Â Â Â Â Â // report on the behavior of its caller.
int main()
{
   DDD();    // this
   HHH(DDD); // is not the caller of this: this
is }Â Â Â Â Â Â Â Â Â Â Â Â Â // asking what the above will do
That is just not the way that computation actually works.
Sure it is. We don't care how the mapping is generated, only that it
is generated.
There is not enough information in the input to
know how the caller works.
Also there is not enough information in any integer
to predict who the president will be.
char* WhatIsTheNameOfThePresidentIn2030(int x);
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation
happens to be DDD() it must report about another behaviour instead
of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not
mentioned what is irrelevant to whatever they said. In particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement that
a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the direct
executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
On 6/4/2025 9:13 PM, dbush wrote:
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation >>>>>> happens to be DDD() it must report about another behaviour instead >>>>>> of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not >>>>>> mentioned what is irrelevant to whatever they said. In particular, >>>>>> whether DDD() calls HHH(DDD) is irrelevant to the requirement that >>>>>> a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the
direct executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
But unlike Russel's Paradox, which showed a contradiction in the
axioms of naive set theory, there is no contradiction in the axioms of
computation theory. It follows from those axioms that no H exists
that performs the below mapping, as you have *explicitly* agreed.
int main()
{
 DDD(); // comp theory does not allow HHH to
}Â Â Â Â Â Â Â // report on the behavior of its caller.
On 6/4/2025 9:56 PM, dbush wrote:
On 6/4/2025 10:44 PM, olcott wrote:
On 6/4/2025 9:13 PM, dbush wrote:
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting >>>>>>>> decider when it reports) must report whether the direct execution >>>>>>>> of the computation asked about terminates. Unless that computation >>>>>>>> happens to be DDD() it must report about another behaviour instead >>>>>>>> of DDD().
yet never bother to notice that the directly executed DDD() is >>>>>>>>> the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not >>>>>>>> mentioned what is irrelevant to whatever they said. In particular, >>>>>>>> whether DDD() calls HHH(DDD) is irrelevant to the requirement that >>>>>>>> a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the
direct executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
But unlike Russel's Paradox, which showed a contradiction in the
axioms of naive set theory, there is no contradiction in the axioms
of computation theory. It follows from those axioms that no H
exists that performs the below mapping, as you have *explicitly*
agreed.
int main()
{
  DDD(); // comp theory does not allow HHH to
}Â Â Â Â Â Â Â // report on the behavior of its caller.
int main()
{
   DDD();    // this
   HHH(DDD); // is not the caller of this: this is }             //
asking what the above will do
That is just not the way that computation actually works.
char* WhatIsTheNameOfThePresidentIn2030(int x);
Cannot be derived on the basis of the input.
On 6/5/2025 6:10 AM, Richard Damon wrote:
On 6/4/25 11:32 PM, olcott wrote:
On 6/4/2025 9:56 PM, dbush wrote:
On 6/4/2025 10:44 PM, olcott wrote:
On 6/4/2025 9:13 PM, dbush wrote:
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting >>>>>>>>>> decider when it reports) must report whether the direct execution >>>>>>>>>> of the computation asked about terminates. Unless that
computation
happens to be DDD() it must report about another behaviour >>>>>>>>>> instead
of DDD().
yet never bother to notice that the directly executed DDD() is >>>>>>>>>>> the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they >>>>>>>>>> have not
mentioned what is irrelevant to whatever they said. In
particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement >>>>>>>>>> that
a halting decider must report about a direct exection of the >>>>>>>>>> computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the >>>>>>>> direct executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
But unlike Russel's Paradox, which showed a contradiction in the
axioms of naive set theory, there is no contradiction in the
axioms of computation theory. It follows from those axioms that
no H exists that performs the below mapping, as you have
*explicitly* agreed.
int main()
{
  DDD(); // comp theory does not allow HHH to
}Â Â Â Â Â Â Â // report on the behavior of its caller.
int main()
{
   DDD();    // this
   HHH(DDD); // is not the caller of this: this
is }Â Â Â Â Â Â Â Â Â Â Â Â Â // asking what the above will do
That is just not the way that computation actually works.
char* WhatIsTheNameOfThePresidentIn2030(int x);
Cannot be derived on the basis of the input.
Which just shows you don't understand how Computations, or even
"truth" actually works.
Facts about the future under the control of volitional beings doesn't
have a firm correct answer. (Social Scientist CAN come up with a
distribution of likely answers).
So you agree that a single integer value is also less
than enough information to correctly make this prediction.
Computations are about deterministic systems, and since programs are
deterministic, questions about programs are valid, even if not all are
actually computable, and THAT question (IS it computable) is one of
the big focuses of Computability Theory.
HHH cannot report on the behavior of its caller
because it cannot see its caller in its caller's
own process context.
Even if it could see its caller it is not allowed
to report on it. It is only allowed to report on
the behavior that its input actually specifies.
On 6/5/2025 3:02 AM, Mikko wrote:
On 2025-06-05 02:13:32 +0000, dbush said:
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting >>>>>>> decider when it reports) must report whether the direct execution >>>>>>> of the computation asked about terminates. Unless that computation >>>>>>> happens to be DDD() it must report about another behaviour instead >>>>>>> of DDD().
yet never bother to notice that the directly executed DDD() is >>>>>>>> the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not >>>>>>> mentioned what is irrelevant to whatever they said. In particular, >>>>>>> whether DDD() calls HHH(DDD) is irrelevant to the requirement that >>>>>>> a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the
direct executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
But unlike Russel's Paradox, which showed a contradiction in the
axioms of naive set theory, there is no contradiction in the axioms
of computation theory.
That is easy to fix. Just add the axiom that HHH correctly computes
whether DDD halts.
Incoherent axioms cannot be added.
int main()
{
 DDD(); // The HHH(DDD) that this DDD calls cannot see its caller }        // Making an axiom that tells is must look at its caller
         // and it still cannot see its caller.
On 6/5/2025 2:01 AM, Fred. Zwarts wrote:
Op 05.jun.2025 om 06:33 schreef olcott:
On 6/4/2025 10:41 PM, dbush wrote:
On 6/4/2025 11:32 PM, olcott wrote:
On 6/4/2025 9:56 PM, dbush wrote:
On 6/4/2025 10:44 PM, olcott wrote:
On 6/4/2025 9:13 PM, dbush wrote:
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of >>>>>>>>>>>>> direct execution of DDD()
No, they don't say that. A halting decider (and a partial >>>>>>>>>>>> halting
decider when it reports) must report whether the direct >>>>>>>>>>>> execution
of the computation asked about terminates. Unless that >>>>>>>>>>>> computation
happens to be DDD() it must report about another behaviour >>>>>>>>>>>> instead
of DDD().
yet never bother to notice that the directly executed DDD() is >>>>>>>>>>>>> the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they >>>>>>>>>>>> have not
mentioned what is irrelevant to whatever they said. In >>>>>>>>>>>> particular,
whether DDD() calls HHH(DDD) is irrelevant to the
requirement that
a halting decider must report about a direct exection of the >>>>>>>>>>>> computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about >>>>>>>>>> the direct executiom of the program that input represents. >>>>>>>>>>
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
But unlike Russel's Paradox, which showed a contradiction in the >>>>>>>> axioms of naive set theory, there is no contradiction in the
axioms of computation theory. It follows from those axioms that >>>>>>>> no H exists that performs the below mapping, as you have
*explicitly* agreed.
int main()
{
  DDD(); // comp theory does not allow HHH to
}Â Â Â Â Â Â Â // report on the behavior of its caller.
int main()
{
   DDD();    // this
   HHH(DDD); // is not the caller of this: this
is }Â Â Â Â Â Â Â Â Â Â Â Â Â // asking what the above will do
That is just not the way that computation actually works.
Sure it is. We don't care how the mapping is generated, only that
it is generated.
There is not enough information in the input to
know how the caller works.
Counterfactual. The input is a pointer to the start of a function.
Prove it.
The code of that function has addresses to other functions used in the
program, including the code that aborts and halts.
All information is there. But the programmer of HHH decided to make
HHH such that it does not see all the information. It is a choice to
analyse only the code of DDD itself. A wrong choice. It should also
analyse the code of the functions called by DDD. Including the
conditional branch instructions within the functions called by DDD.
Also there is not enough information in any integer
to predict who the president will be.
char* WhatIsTheNameOfThePresidentIn2030(int x);
Irrelevant, because the pointer given to HHH is enough to find all
information, which is proven by the fact that world-class simulator
give the correct result when given exactly the same pointer as input.
On 6/5/2025 6:06 AM, Richard Damon wrote:
On 6/4/25 10:44 PM, olcott wrote:
On 6/4/2025 9:13 PM, dbush wrote:
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting >>>>>>>> decider when it reports) must report whether the direct execution >>>>>>>> of the computation asked about terminates. Unless that computation >>>>>>>> happens to be DDD() it must report about another behaviour instead >>>>>>>> of DDD().
yet never bother to notice that the directly executed DDD() is >>>>>>>>> the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not >>>>>>>> mentioned what is irrelevant to whatever they said. In particular, >>>>>>>> whether DDD() calls HHH(DDD) is irrelevant to the requirement that >>>>>>>> a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the
direct executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
But unlike Russel's Paradox, which showed a contradiction in the
axioms of naive set theory, there is no contradiction in the axioms
of computation theory. It follows from those axioms that no H
exists that performs the below mapping, as you have *explicitly*
agreed.
int main()
{
  DDD(); // comp theory does not allow HHH to
}Â Â Â Â Â Â Â // report on the behavior of its caller.
WHere do you get that from?
Your problem seems to be you don't know the meaning of the terms of
the Theory.
You can't ask the question: "Does your caller Halt?"
That is what I just said.
You can ask the question: "Does the program your input represents halt?"
Too vague. Does the sequence of configurations that your input specifies reach their own final halt state?
even when that input represents its caller, because who the caller is
doesn't affect that answer.
Completely different process contexts cannot be equated.
All you are doing is showing that you have a fundamental error in your
view of the theory, not understanding the basic concepts.
If everyone else is wrong their wrong headed agreement may
make it seem that I am wrong.
On 6/5/2025 6:03 AM, Richard Damon wrote:
On 6/4/25 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation >>>>>> happens to be DDD() it must report about another behaviour instead >>>>>> of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not >>>>>> mentioned what is irrelevant to whatever they said. In particular, >>>>>> whether DDD() calls HHH(DDD) is irrelevant to the requirement that >>>>>> a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the
direct executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
No, Russell's Paradox showed a fundamental error in "Naive" Set
Theory. ZFC did nothing with Russell's Paradox, except to define a
system that can't support it, but still was able to handle a large
portion of the problems that the original theory was trying to be used
on.
ZFC ruled that those aspects of naive set theory that
allowed Russell's Paradox to exist were incoherent.
int main()
{
 DDD(); // The HHH(DDD) that this DDD calls cannot see its caller
}
Likewise PO has ruled that the counter-example input
to the halting problem cannot actually do the opposite
of whatever value that its decider returns.
The above DDD *IS NOT AN INPUT* to the HHH(DDD) that it calls.
Until you can show a similar problem with the definitions from
computation theory, you don't have something to stand on.
The fact that some things turn out to be not-computable is not such a
problem, in fact after it was discovered that this problem was non-
computable, mathematics figured out that there had to be uncomputable
problems by a simple counting argument.
If you think non-computable functions ARE a problem, and you want to
define some alternate theory of computations, go ahead. You then have
teh second half of what ZFC did, show that your system solves the
problems that the original theory was being used on.
Since, it is clear you don't understand the purpose that Computation
Theory was developed for (Hint, it isn't about programs on modern
digital computers, as it predates their existance), this will be hard
for you.
On 6/5/2025 2:48 AM, Mikko wrote:
On 2025-06-04 15:50:25 +0000, olcott said:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation
happens to be DDD() it must report about another behaviour instead
of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not
mentioned what is irrelevant to whatever they said. In particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement that
a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
You have not identified anythhing relevant that has been ignored for
90 years. Seems that you ignore much of the discussions during those
90 years.
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
The relevant question is not what HHH can report but what it does
and what it is required. DDD() is known to halt so HHH(DDD) is
required to report that it halts. But HHH(DDD) does not report so.
The only DDD that is known to halt is the DDD
that calls HHH(DDD). HHH(DDD) IS NOT ACCOUNTABLE
FOR THE BEHAVIOR OF ITS CALLER.
On 6/5/2025 6:19 AM, Richard Damon wrote:
On 6/5/25 12:33 AM, olcott wrote:
On 6/4/2025 10:41 PM, dbush wrote:
On 6/4/2025 11:32 PM, olcott wrote:
On 6/4/2025 9:56 PM, dbush wrote:
On 6/4/2025 10:44 PM, olcott wrote:
On 6/4/2025 9:13 PM, dbush wrote:
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of >>>>>>>>>>>>> direct execution of DDD()
No, they don't say that. A halting decider (and a partial >>>>>>>>>>>> halting
decider when it reports) must report whether the direct >>>>>>>>>>>> execution
of the computation asked about terminates. Unless that >>>>>>>>>>>> computation
happens to be DDD() it must report about another behaviour >>>>>>>>>>>> instead
of DDD().
yet never bother to notice that the directly executed DDD() is >>>>>>>>>>>>> the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they >>>>>>>>>>>> have not
mentioned what is irrelevant to whatever they said. In >>>>>>>>>>>> particular,
whether DDD() calls HHH(DDD) is irrelevant to the
requirement that
a halting decider must report about a direct exection of the >>>>>>>>>>>> computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about >>>>>>>>>> the direct executiom of the program that input represents. >>>>>>>>>>
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
But unlike Russel's Paradox, which showed a contradiction in the >>>>>>>> axioms of naive set theory, there is no contradiction in the
axioms of computation theory. It follows from those axioms that >>>>>>>> no H exists that performs the below mapping, as you have
*explicitly* agreed.
int main()
{
  DDD(); // comp theory does not allow HHH to
}Â Â Â Â Â Â Â // report on the behavior of its caller.
int main()
{
   DDD();    // this
   HHH(DDD); // is not the caller of this: this
is }Â Â Â Â Â Â Â Â Â Â Â Â Â // asking what the above will do
That is just not the way that computation actually works.
Sure it is. We don't care how the mapping is generated, only that
it is generated.
There is not enough information in the input to
know how the caller works.
The the input isn't complete, and you did your problem wrong.
The actual input specifies a sequence of configurations
that cannot possibly reach their own final halt state.
The caller is *not* the input.
To say that its caller is its input is the same
as saying that you are your mother's father.
On 6/5/2025 3:02 AM, Mikko wrote:
On 2025-06-05 02:13:32 +0000, dbush said:
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting >>>>>>> decider when it reports) must report whether the direct execution >>>>>>> of the computation asked about terminates. Unless that computation >>>>>>> happens to be DDD() it must report about another behaviour instead >>>>>>> of DDD().
yet never bother to notice that the directly executed DDD() is >>>>>>>> the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not >>>>>>> mentioned what is irrelevant to whatever they said. In particular, >>>>>>> whether DDD() calls HHH(DDD) is irrelevant to the requirement that >>>>>>> a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the direct >>>>> executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
But unlike Russel's Paradox, which showed a contradiction in the axioms
of naive set theory, there is no contradiction in the axioms of
computation theory.
That is easy to fix. Just add the axiom that HHH correctly computes
whether DDD halts.
Incoherent axioms cannot be added.
On 6/5/2025 2:58 AM, Mikko wrote:
On 2025-06-05 02:09:19 +0000, olcott said:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation >>>>>> happens to be DDD() it must report about another behaviour instead >>>>>> of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not >>>>>> mentioned what is irrelevant to whatever they said. In particular, >>>>>> whether DDD() calls HHH(DDD) is irrelevant to the requirement that >>>>>> a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the direct >>>> executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
Russell's paradox is not complete nonsense. It has a very clear
meaning: a theory where the paradox or some variant of it can
be shown is inconsistent. If a theory is inconsistent then it
Inconsistent, incoherent, nonsense, all the same thing.
is good to know that it is inconsistent. Conversely, if one
wants to present a new set theory or a new type theory or a new
theory of semantics one should check that the Russell's paradox
is not there nor any simple variant (like Barber's paradox or
the word "heterologous").
On 6/5/2025 2:48 AM, Mikko wrote:
On 2025-06-04 15:50:25 +0000, olcott said:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation
happens to be DDD() it must report about another behaviour instead
of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not
mentioned what is irrelevant to whatever they said. In particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement that
a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
You have not identified anythhing relevant that has been ignored for
90 years. Seems that you ignore much of the discussions during those
90 years.
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
The relevant question is not what HHH can report but what it does
and what it is required. DDD() is known to halt so HHH(DDD) is
required to report that it halts. But HHH(DDD) does not report so.
The only DDD that is known to halt is the DDD
that calls HHH(DDD). HHH(DDD) IS NOT ACCOUNTABLE
FOR THE BEHAVIOR OF ITS CALLER.
On 6/5/2025 2:58 AM, Mikko wrote:
On 2025-06-05 02:09:19 +0000, olcott said:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation >>>>>> happens to be DDD() it must report about another behaviour instead >>>>>> of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not >>>>>> mentioned what is irrelevant to whatever they said. In particular, >>>>>> whether DDD() calls HHH(DDD) is irrelevant to the requirement that >>>>>> a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the
direct executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
Russell's paradox is not complete nonsense. It has a very clear
meaning: a theory where the paradox or some variant of it can
be shown is inconsistent. If a theory is inconsistent then it
Inconsistent, incoherent, nonsense, all the same thing.
is good to know that it is inconsistent. Conversely, if one
wants to present a new set theory or a new type theory or a new
theory of semantics one should check that the Russell's paradox
is not there nor any simple variant (like Barber's paradox or
the word "heterologous").
int main()
{
 DDD(); // The HHH(DDD) that this DDD calls is only accountable }       // for the actual behavior that its input actually specifies.
        // It is not accountable for the behavior of its caller.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
HHH is correct to reject DDD.
On 6/5/2025 2:01 AM, Fred. Zwarts wrote:
Op 05.jun.2025 om 06:33 schreef olcott:
On 6/4/2025 10:41 PM, dbush wrote:
On 6/4/2025 11:32 PM, olcott wrote:
On 6/4/2025 9:56 PM, dbush wrote:
On 6/4/2025 10:44 PM, olcott wrote:
On 6/4/2025 9:13 PM, dbush wrote:
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of >>>>>>>>>>>>> direct execution of DDD()
No, they don't say that. A halting decider (and a partial >>>>>>>>>>>> halting
decider when it reports) must report whether the direct >>>>>>>>>>>> execution
of the computation asked about terminates. Unless that >>>>>>>>>>>> computation
happens to be DDD() it must report about another behaviour >>>>>>>>>>>> instead
of DDD().
yet never bother to notice that the directly executed DDD() is >>>>>>>>>>>>> the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they >>>>>>>>>>>> have not
mentioned what is irrelevant to whatever they said. In >>>>>>>>>>>> particular,
whether DDD() calls HHH(DDD) is irrelevant to the
requirement that
a halting decider must report about a direct exection of the >>>>>>>>>>>> computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about >>>>>>>>>> the direct executiom of the program that input represents. >>>>>>>>>>
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
But unlike Russel's Paradox, which showed a contradiction in the >>>>>>>> axioms of naive set theory, there is no contradiction in the
axioms of computation theory. It follows from those axioms that >>>>>>>> no H exists that performs the below mapping, as you have
*explicitly* agreed.
int main()
{
  DDD(); // comp theory does not allow HHH to
}Â Â Â Â Â Â Â // report on the behavior of its caller.
int main()
{
   DDD();    // this
   HHH(DDD); // is not the caller of this: this
is }Â Â Â Â Â Â Â Â Â Â Â Â Â // asking what the above will do
That is just not the way that computation actually works.
Sure it is. We don't care how the mapping is generated, only that
it is generated.
There is not enough information in the input to
know how the caller works.
Counterfactual. The input is a pointer to the start of a function.
Prove it.
On 6/5/2025 2:48 AM, Mikko wrote:
On 2025-06-04 15:50:25 +0000, olcott said:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation
happens to be DDD() it must report about another behaviour instead
of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not
mentioned what is irrelevant to whatever they said. In particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement that
a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
You have not identified anythhing relevant that has been ignored for
90 years. Seems that you ignore much of the discussions during those
90 years.
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
The relevant question is not what HHH can report but what it does
and what it is required. DDD() is known to halt so HHH(DDD) is
required to report that it halts. But HHH(DDD) does not report so.
The only DDD that is known to halt is the DDD
that calls HHH(DDD). HHH(DDD) IS NOT ACCOUNTABLE
FOR THE BEHAVIOR OF ITS CALLER.
On 6/6/2025 3:19 AM, Fred. Zwarts wrote:The thing is, DDD is both, by construction. Data can be code. The
Op 05.jun.2025 om 18:03 schreef olcott:
On 6/5/2025 2:48 AM, Mikko wrote:
On 2025-06-04 15:50:25 +0000, olcott said:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
yet never bother to notice that the directly executed DDD() is the >>>>>>> caller of HHH(DDD).
Counterfactual. It has nothing to do with the caller. World-classThe only DDD that is known to halt is the DDD that calls HHH(DDD).The only possible way that HHH can report on the direct execution of >>>>> DDD() is for HHH to report on the behavior of its caller:
The relevant question is not what HHH can report but what it does and
what it is required. DDD() is known to halt so HHH(DDD) is required
to report that it halts. But HHH(DDD) does not report so.
HHH(DDD) IS NOT ACCOUNTABLE FOR THE BEHAVIOR OF ITS CALLER.
simulators show that the exact same input halts.
You are incorrectly calling it an *INPUT* when it never was an actual
*INPUT* it was always a *NON-INPUT CALLER*
People have made this same stupid mistake for 90 years.
On 6/6/2025 2:18 PM, joes wrote:
Am Fri, 06 Jun 2025 12:32:56 -0500 schrieb olcott:
On 6/6/2025 3:19 AM, Fred. Zwarts wrote:
Op 05.jun.2025 om 18:03 schreef olcott:
On 6/5/2025 2:48 AM, Mikko wrote:
On 2025-06-04 15:50:25 +0000, olcott said:
The thing is, DDD is both,Counterfactual. It has nothing to do with the caller. World-classThe only DDD that is known to halt is the DDD that calls HHH(DDD).The only possible way that HHH can report on the direct execution >>>>>>> of DDD() is for HHH to report on the behavior of its caller:
The relevant question is not what HHH can report but what it does
and what it is required. DDD() is known to halt so HHH(DDD) is
required to report that it halts. But HHH(DDD) does not report so. >>>>>>
HHH(DDD) IS NOT ACCOUNTABLE FOR THE BEHAVIOR OF ITS CALLER.
simulators show that the exact same input halts.
You are incorrectly calling it an *INPUT* when it never was an actual
*INPUT* it was always a *NON-INPUT CALLER*
People have made this same stupid mistake for 90 years.
int main()
{
DDD; // calls HHH(DDD)
}
*The input to HHH IS NOT ITS CALLER*
--by construction. Data can be code. The contradiction is exactly that
HHH's return value makes the simulation
of DDD wrong. You can't sidestep that by saying they are different
DDD's.
On 6/6/2025 3:13 AM, Fred. Zwarts wrote:It doesn't need to. It has all the code of DDD to analyse.
Op 05.jun.2025 om 17:46 schreef olcott:
On 6/5/2025 2:01 AM, Fred. Zwarts wrote:
Op 05.jun.2025 om 06:33 schreef olcott:
On 6/4/2025 10:41 PM, dbush wrote:
On 6/4/2025 11:32 PM, olcott wrote:
On 6/4/2025 9:56 PM, dbush wrote:
On 6/4/2025 10:44 PM, olcott wrote:
On 6/4/2025 9:13 PM, dbush wrote:
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
The only possible way that HHH can report on the direct >>>>>>>>>>>>> execution of DDD() is for HHH to report on the behavior of >>>>>>>>>>>>> its caller:
int main()That is just not the way that computation actually works.
{
   DDD();    // this HHH(DDD); // is not the caller of >>>>>>>>    this: this
is }Â Â Â Â Â Â Â Â Â Â Â Â Â // asking what the above will do >>>>>>>
Sure it is. We don't care how the mapping is generated, only that >>>>>> it is generated.There is not enough information in the input to know how the caller
works.
No, DDD specifies that it calls HHH to simulate itself, whereupon thatIt seems you have no idea of the C language.Counterfactual. The input is a pointer to the start of a function.
Prove it.
In HHH(DDD), DDD is a parameter. This parameter is the input for HHH.
DDD is also a function. In C a function, when used as a parameter, is a
pointer.
I assume this is another clever way to distract the attention from the
fact that your claims are counterfactual.
DDD emulated by HHH specifies executed HHH emulates DDD that calls
emulated HHH(DDD)
that emulates DDD that calls emulated HHH(DDD)
that emulates DDD that calls emulated HHH(DDD)...
On 6/6/2025 2:29 PM, joes wrote:No, they are wrong.
Am Fri, 06 Jun 2025 12:28:50 -0500 schrieb olcott:
On 6/6/2025 3:13 AM, Fred. Zwarts wrote:
Op 05.jun.2025 om 17:46 schreef olcott:
On 6/5/2025 2:01 AM, Fred. Zwarts wrote:
Op 05.jun.2025 om 06:33 schreef olcott:
On 6/4/2025 10:41 PM, dbush wrote:
On 6/4/2025 11:32 PM, olcott wrote:
On 6/4/2025 9:56 PM, dbush wrote:
On 6/4/2025 10:44 PM, olcott wrote:
On 6/4/2025 9:13 PM, dbush wrote:
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
The only possible way that HHH can report on the direct >>>>>>>>>>>>>>> execution of DDD() is for HHH to report on the behavior of >>>>>>>>>>>>>>> its caller:
It doesn't need to. It has all the code of DDD to analyse.
int main()That is just not the way that computation actually works.
{
   DDD();    // this HHH(DDD); // is not the caller of >>>>>>>>>>    this: this
is }Â Â Â Â Â Â Â Â Â Â Â Â Â // asking what the above will do >>>>>>>>>
Yes it is. Your comments are correct: running HHH(DDD) is asking what
running DDD() will do. You can do so by simulating it *uninterrupted*.
You won't of course always get an answer, not because DDD wouldn't
halt, but because HHH doesn't. In preventing itself non-halting, HHH
gets the answer wrong. All would be well if it just returned that DDD
halts.
Sure it is. We don't care how the mapping is generated, only >>>>>>>> that it is generated.There is not enough information in the input to know how the
caller works.
There definitely is. The code of DDD (including HHH) completely
determines its path.
It seems you have no idea of the C language.Counterfactual. The input is a pointer to the start of a function.
Prove it.
In HHH(DDD), DDD is a parameter. This parameter is the input for HHH.
DDD is also a function. In C a function, when used as a parameter, is
a pointer.
I assume this is another clever way to distract the attention from
the fact that your claims are counterfactual.
DDD emulated by HHH specifies executed HHH emulates DDD that calls
emulated HHH(DDD)
that emulates DDD that calls emulated HHH(DDD)
that emulates DDD that calls emulated HHH(DDD)...
No, DDD specifies that it calls HHH to simulate itself, whereupon that
HHH will stop simulating and return to DDD,
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its *simulated
"return" instruction final halt state*
*Every rebuttal to this changes the words*
*YOU JUST CHANGED THESE WORDS*
--which would then halt and the outer HHH would report so - if the outer
HHH wouldn't abort before.
On 6/6/2025 2:47 AM, Mikko wrote:
On 2025-06-05 16:12:41 +0000, olcott said:
On 6/5/2025 2:58 AM, Mikko wrote:
On 2025-06-05 02:09:19 +0000, olcott said:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting >>>>>>>> decider when it reports) must report whether the direct execution >>>>>>>> of the computation asked about terminates. Unless that computation >>>>>>>> happens to be DDD() it must report about another behaviour instead >>>>>>>> of DDD().
yet never bother to notice that the directly executed DDD() is >>>>>>>>> the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not >>>>>>>> mentioned what is irrelevant to whatever they said. In particular, >>>>>>>> whether DDD() calls HHH(DDD) is irrelevant to the requirement that >>>>>>>> a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the
direct executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
Russell's paradox is not complete nonsense. It has a very clear
meaning: a theory where the paradox or some variant of it can
be shown is inconsistent. If a theory is inconsistent then it
Inconsistent, incoherent, nonsense, all the same thing.
For practical purposes, yes. In a formal context "inconsistent" is
preferred as a defined formal term. The others are informal.
is good to know that it is inconsistent. Conversely, if one
wants to present a new set theory or a new type theory or a new
theory of semantics one should check that the Russell's paradox
is not there nor any simple variant (like Barber's paradox or
the word "heterologous").
int main()
{
  DDD(); // requiring the HHH(DDD) that DDD calls to
}Â Â Â Â Â Â Â Â // report on the behavior of its caller is incorrect.
On 6/6/2025 3:13 AM, Fred. Zwarts wrote:
Op 05.jun.2025 om 17:46 schreef olcott:
On 6/5/2025 2:01 AM, Fred. Zwarts wrote:It seems you have no idea of the C language.
Op 05.jun.2025 om 06:33 schreef olcott:
On 6/4/2025 10:41 PM, dbush wrote:
On 6/4/2025 11:32 PM, olcott wrote:
On 6/4/2025 9:56 PM, dbush wrote:
On 6/4/2025 10:44 PM, olcott wrote:That is just not the way that computation actually works.
On 6/4/2025 9:13 PM, dbush wrote:
On 6/4/2025 10:09 PM, olcott wrote:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of >>>>>>>>>>>>>>> direct execution of DDD()
No, they don't say that. A halting decider (and a partial >>>>>>>>>>>>>> halting
decider when it reports) must report whether the direct >>>>>>>>>>>>>> execution
of the computation asked about terminates. Unless that >>>>>>>>>>>>>> computation
happens to be DDD() it must report about another behaviour >>>>>>>>>>>>>> instead
of DDD().
yet never bother to notice that the directly executed >>>>>>>>>>>>>>> DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they >>>>>>>>>>>>>> have not
mentioned what is irrelevant to whatever they said. In >>>>>>>>>>>>>> particular,
whether DDD() calls HHH(DDD) is irrelevant to the
requirement that
a halting decider must report about a direct exection of the >>>>>>>>>>>>>> computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about >>>>>>>>>>>> the direct executiom of the program that input represents. >>>>>>>>>>>>
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
But unlike Russel's Paradox, which showed a contradiction in >>>>>>>>>> the axioms of naive set theory, there is no contradiction in >>>>>>>>>> the axioms of computation theory. It follows from those
axioms that no H exists that performs the below mapping, as >>>>>>>>>> you have *explicitly* agreed.
int main()
{
  DDD(); // comp theory does not allow HHH to
}Â Â Â Â Â Â Â // report on the behavior of its caller.
int main()
{
   DDD();    // this
   HHH(DDD); // is not the caller of this: this
is }Â Â Â Â Â Â Â Â Â Â Â Â Â // asking what the above will do >>>>>>>
Sure it is. We don't care how the mapping is generated, only that >>>>>> it is generated.
There is not enough information in the input to
know how the caller works.
Counterfactual. The input is a pointer to the start of a function.
Prove it.
In HHH(DDD), DDD is a parameter. This parameter is the input for HHH.
DDD is also a function. In C a function, when used as a parameter, is
a pointer.
I assume this is another clever way to distract the attention from the
fact that your claims are counterfactual.
void DDD()
{
 HHH(DDD);
 return;
}
DDD emulated by HHH specifies
executed HHH emulates DDD that calls emulated HHH(DDD)
that emulates DDD that calls emulated HHH(DDD)
that emulates DDD that calls emulated HHH(DDD)
that emulates DDD that calls emulated HHH(DDD)
that emulates DDD that calls emulated HHH(DDD)...
Where do we get to reaching the emulated "return"
instruction final halt state?
On 6/6/2025 2:53 AM, Mikko wrote:
On 2025-06-05 16:03:13 +0000, olcott said:
On 6/5/2025 2:48 AM, Mikko wrote:
On 2025-06-04 15:50:25 +0000, olcott said:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation >>>>>> happens to be DDD() it must report about another behaviour instead >>>>>> of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not >>>>>> mentioned what is irrelevant to whatever they said. In particular, >>>>>> whether DDD() calls HHH(DDD) is irrelevant to the requirement that >>>>>> a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
You have not identified anythhing relevant that has been ignored for
90 years. Seems that you ignore much of the discussions during those
90 years.
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
The relevant question is not what HHH can report but what it does
and what it is required. DDD() is known to halt so HHH(DDD) is
required to report that it halts. But HHH(DDD) does not report so.
The only DDD that is known to halt is the DDD
that calls HHH(DDD). HHH(DDD) IS NOT ACCOUNTABLE
FOR THE BEHAVIOR OF ITS CALLER.
Accountabiity is meaningless in the context of the halting problem.
Not at all. int sum(int x, int y) {return x + y;}
sum(3,4) is accountable to provide the sum of 3 + 4.
It is not accountable to provide the sum of 5 + 6.
Likewise HHH(DDD) is accountable for
<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
In that context it sufficient to note that the HHH does not correctly
predict whether DDD halts.
However, one should understand that the behaviour of HHH(DDD) is an
essential part of the behaviour of DDD. In particular, if HHH is a
decider then DDD halts, though DDD may halt even if HHH is not a
decider. But we know what HHH is so no if's about it are needed.
On 6/6/2025 3:19 AM, Fred. Zwarts wrote:
Op 05.jun.2025 om 18:03 schreef olcott:
On 6/5/2025 2:48 AM, Mikko wrote:
On 2025-06-04 15:50:25 +0000, olcott said:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation >>>>>> happens to be DDD() it must report about another behaviour instead >>>>>> of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not >>>>>> mentioned what is irrelevant to whatever they said. In particular, >>>>>> whether DDD() calls HHH(DDD) is irrelevant to the requirement that >>>>>> a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
You have not identified anythhing relevant that has been ignored for
90 years. Seems that you ignore much of the discussions during those
90 years.
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
The relevant question is not what HHH can report but what it does
and what it is required. DDD() is known to halt so HHH(DDD) is
required to report that it halts. But HHH(DDD) does not report so.
The only DDD that is known to halt is the DDD
that calls HHH(DDD). HHH(DDD) IS NOT ACCOUNTABLE
FOR THE BEHAVIOR OF ITS CALLER.
Counterfactual. It has nothing to do with the caller. World-class
simulators show that the exact same input halts.
You are incorrectly calling it an *INPUT* when
it never was an actual *INPUT* it was always a *NON-INPUT CALLER*
People have made this same stupid mistake for 90 years.
On 6/6/2025 2:18 PM, joes wrote:
Am Fri, 06 Jun 2025 12:32:56 -0500 schrieb olcott:
On 6/6/2025 3:19 AM, Fred. Zwarts wrote:The thing is, DDD is both,
Op 05.jun.2025 om 18:03 schreef olcott:
On 6/5/2025 2:48 AM, Mikko wrote:
On 2025-06-04 15:50:25 +0000, olcott said:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
yet never bother to notice that the directly executed DDD() is the >>>>>>>>> caller of HHH(DDD).
Counterfactual. It has nothing to do with the caller. World-classThe only DDD that is known to halt is the DDD that calls HHH(DDD).The only possible way that HHH can report on the direct execution of >>>>>>> DDD() is for HHH to report on the behavior of its caller:
The relevant question is not what HHH can report but what it does and >>>>>> what it is required. DDD() is known to halt so HHH(DDD) is required >>>>>> to report that it halts. But HHH(DDD) does not report so.
HHH(DDD) IS NOT ACCOUNTABLE FOR THE BEHAVIOR OF ITS CALLER.
simulators show that the exact same input halts.
You are incorrectly calling it an *INPUT* when it never was an actual
*INPUT* it was always a *NON-INPUT CALLER*
People have made this same stupid mistake for 90 years.
int main()
{
 DDD; // calls HHH(DDD)
}
*The input to HHH IS NOT ITS CALLER*
by construction. Data can be code. The> contradiction is exactly thatHHH's return value makes the simulation
of DDD wrong. You can't sidestep that by saying they are different DDD's.
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation
happens to be DDD() it must report about another behaviour instead
of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not
mentioned what is irrelevant to whatever they said. In particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement that
a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
On 6/7/2025 3:33 AM, Mikko wrote:
On 2025-06-04 15:50:25 +0000, olcott said:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation
happens to be DDD() it must report about another behaviour instead
of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not
mentioned what is irrelevant to whatever they said. In particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement that
a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
So you say bot don't show.
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
Now you are changing the topic. Your false claim was that "They all
say that HHH must report on the behavior of direct execution of DDD()
Verified fact.
yet never bother to notice that the directly executed DDD() is the
caller of HHH(DDD)".
And your counter-example is ???
int main()
{
 DDD(); // The HHH(DDD) that DDD calls cannot report on
}Â Â Â Â Â Â Â // the behavior of its caller.
Your rebuttals fail to provide enough details
to be more than lame. If you did provide more
details then your rebuttals would be incoherent.
By providing lame rebuttals closure is postponed.
On 6/6/2025 2:47 AM, Mikko wrote:
On 2025-06-05 16:12:41 +0000, olcott said:
On 6/5/2025 2:58 AM, Mikko wrote:
On 2025-06-05 02:09:19 +0000, olcott said:
On 6/4/2025 8:43 PM, Richard Damon wrote:
On 6/4/25 11:50 AM, olcott wrote:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting >>>>>>>> decider when it reports) must report whether the direct execution >>>>>>>> of the computation asked about terminates. Unless that computation >>>>>>>> happens to be DDD() it must report about another behaviour instead >>>>>>>> of DDD().
yet never bother to notice that the directly executed DDD() is >>>>>>>>> the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not >>>>>>>> mentioned what is irrelevant to whatever they said. In particular, >>>>>>>> whether DDD() calls HHH(DDD) is irrelevant to the requirement that >>>>>>>> a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
So?
It *IS* a fact that to be correct, it needs to answer about the direct >>>>>> executiom of the program that input represents.
That is DEFINITION.
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
Russell's paradox is not complete nonsense. It has a very clear
meaning: a theory where the paradox or some variant of it can
be shown is inconsistent. If a theory is inconsistent then it
Inconsistent, incoherent, nonsense, all the same thing.
For practical purposes, yes. In a formal context "inconsistent" is
preferred as a defined formal term. The others are informal.
is good to know that it is inconsistent. Conversely, if one
wants to present a new set theory or a new type theory or a new
theory of semantics one should check that the Russell's paradox
is not there nor any simple variant (like Barber's paradox or
the word "heterologous").
int main()
{
DDD(); // requiring the HHH(DDD) that DDD calls to
} // report on the behavior of its caller is incorrect.
On 6/6/2025 2:18 PM, joes wrote:
Am Fri, 06 Jun 2025 12:32:56 -0500 schrieb olcott:
On 6/6/2025 3:19 AM, Fred. Zwarts wrote:The thing is, DDD is both,
Op 05.jun.2025 om 18:03 schreef olcott:
On 6/5/2025 2:48 AM, Mikko wrote:
On 2025-06-04 15:50:25 +0000, olcott said:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
yet never bother to notice that the directly executed DDD() is the >>>>>>>>> caller of HHH(DDD).
Counterfactual. It has nothing to do with the caller. World-classThe only DDD that is known to halt is the DDD that calls HHH(DDD).The only possible way that HHH can report on the direct execution of >>>>>>> DDD() is for HHH to report on the behavior of its caller:
The relevant question is not what HHH can report but what it does and >>>>>> what it is required. DDD() is known to halt so HHH(DDD) is required >>>>>> to report that it halts. But HHH(DDD) does not report so.
HHH(DDD) IS NOT ACCOUNTABLE FOR THE BEHAVIOR OF ITS CALLER.
simulators show that the exact same input halts.
You are incorrectly calling it an *INPUT* when it never was an actual
*INPUT* it was always a *NON-INPUT CALLER*
People have made this same stupid mistake for 90 years.
int main()
{
DDD; // calls HHH(DDD)
}
*The input to HHH IS NOT ITS CALLER*
by construction. Data can be code. The> contradiction is exactly thatHHH's return value makes the simulation
of DDD wrong. You can't sidestep that by saying they are different DDD's.
On 6/6/2025 2:53 AM, Mikko wrote:
On 2025-06-05 16:03:13 +0000, olcott said:
On 6/5/2025 2:48 AM, Mikko wrote:
On 2025-06-04 15:50:25 +0000, olcott said:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation >>>>>> happens to be DDD() it must report about another behaviour instead >>>>>> of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not >>>>>> mentioned what is irrelevant to whatever they said. In particular, >>>>>> whether DDD() calls HHH(DDD) is irrelevant to the requirement that >>>>>> a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
You have not identified anythhing relevant that has been ignored for
90 years. Seems that you ignore much of the discussions during those
90 years.
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
The relevant question is not what HHH can report but what it does
and what it is required. DDD() is known to halt so HHH(DDD) is
required to report that it halts. But HHH(DDD) does not report so.
The only DDD that is known to halt is the DDD
that calls HHH(DDD). HHH(DDD) IS NOT ACCOUNTABLE
FOR THE BEHAVIOR OF ITS CALLER.
Accountabiity is meaningless in the context of the halting problem.
Not at all.
On 6/7/2025 3:33 AM, Mikko wrote:
On 2025-06-04 15:50:25 +0000, olcott said:
On 6/4/2025 2:04 AM, Mikko wrote:
On 2025-06-03 21:39:46 +0000, olcott said:
They all say that HHH must report on the behavior of
direct execution of DDD()
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation
happens to be DDD() it must report about another behaviour instead
of DDD().
yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).
To say that nobody has noticed that is a lie. Perhaps they have not
mentioned what is irrelevant to whatever they said. In particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement that
a halting decider must report about a direct exection of the
computation the input specifies.
*People have ignored this for 90 years*
So you say bot don't show.
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:
Now you are changing the topic. Your false claim was that "They all
say that HHH must report on the behavior of direct execution of DDD()
Verified fact.
On 6/3/2025 10:02 PM, dbush wrote:
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes
the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above requirements, which
is precisely the theorem that the halting problem proofs prove.
In the exact same way that there is no set of all set
that contain themselves. ZFC did not solve Russell's
Paradox as much as it showed that Russell's Paradox
was anchored in an incoherent foundation, now called
naive set theory.
Which arose because the axioms of naive set theory created a
contradiction.
Likewise with halt deciders that are required to report
on the behavior of directly executed Turing machines.
Directly executed Turing machines are outside of the
domain of every Turing machine decider.
In contrast, the axioms of computation theory do *not* create a
contradiction. It simply follows from those axioms that no H exists
the meets the above requirements, which is a completely valid conclusion.
*Claude.ai seems to be the smartest bot about computation* https://claude.ai/share/48aab578-aec3-44a5-8bb3-6851e0f8b02e
On 7/4/2025 3:53 PM, Richard Damon wrote:
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:In the exact same way that there is no set of all set
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when
executed directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above requirements,
which is precisely the theorem that the halting problem proofs prove. >>>>>
that contain themselves. ZFC did not solve Russell's
Paradox as much as it showed that Russell's Paradox
was anchored in an incoherent foundation, now called
naive set theory.
Which arose because the axioms of naive set theory created a
contradiction.
Likewise with halt deciders that are required to report
on the behavior of directly executed Turing machines.
And what is the CONTRADICTION?
The result is just some things are not computable.
Directly executed Turing machines are outside of the
domain of every Turing machine decider.
Then so is mathematics, as "numbers" can't be given to Turing
Machines, only representations of them.
Numbers always work the same way so it makes no difference.
*HHH(DDD)==0 and HHH1(DDD)==1 are both correct* https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).
*The difference is when*
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.
On 7/4/2025 3:53 PM, Richard Damon wrote:
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:In the exact same way that there is no set of all set
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when
executed directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above requirements,
which is precisely the theorem that the halting problem proofs prove. >>>>>
that contain themselves. ZFC did not solve Russell's
Paradox as much as it showed that Russell's Paradox
was anchored in an incoherent foundation, now called
naive set theory.
Which arose because the axioms of naive set theory created a
contradiction.
Likewise with halt deciders that are required to report
on the behavior of directly executed Turing machines.
And what is the CONTRADICTION?
The result is just some things are not computable.
The result is that there cannot possibly be
an *ACTUAL INPUT* that does the opposite of
whatever its partial halt decider decides
thus the HP proof fails before it begins.
On 7/4/2025 3:53 PM, Richard Damon wrote:
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:In the exact same way that there is no set of all set
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when
executed directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above requirements,
which is precisely the theorem that the halting problem proofs prove. >>>>>
that contain themselves. ZFC did not solve Russell's
Paradox as much as it showed that Russell's Paradox
was anchored in an incoherent foundation, now called
naive set theory.
Which arose because the axioms of naive set theory created a
contradiction.
Likewise with halt deciders that are required to report
on the behavior of directly executed Turing machines.
And what is the CONTRADICTION?
The result is just some things are not computable.
Directly executed Turing machines are outside of the
domain of every Turing machine decider.
Then so is mathematics, as "numbers" can't be given to Turing
Machines, only representations of them.
Numbers always work the same way so it makes no difference.
*HHH(DDD)==0 and HHH1(DDD)==1 are both correct* https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).
*The difference is when*
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.
HHH doesn't actually abort its simulation of DDD until
after has simulated many hundreds of simulated instructions
later. HHH simulates itself simulating DDD until DDD calls
HHH(DDD) again.
By the exact same idea that we can represent a number by a finite
string, we can express the algorithm, and input, of a Turing Machine
as a finite string, and thus can talk about what it will do.
In contrast, the axioms of computation theory do *not* create a
contradiction. It simply follows from those axioms that no H exists
the meets the above requirements, which is a completely valid
conclusion.
*Claude.ai seems to be the smartest bot about computation*
https://claude.ai/share/48aab578-aec3-44a5-8bb3-6851e0f8b02e
Which you just continue to lie to, so proving that you are just a
pathological liar.
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:
On 6/3/2025 10:58 PM, olcott wrote:Likewise with halt deciders that are required to report on the behavior
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:
On 6/3/2025 9:12 PM, dbush wrote:
Yes there is no algorithm that does that
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes >>>>>>> the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>>>>> directly
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above requirements, which
is precisely the theorem that the halting problem proofs prove.
In the exact same way that there is no set of all set that contain
themselves. ZFC did not solve Russell's Paradox as much as it showed
that Russell's Paradox was anchored in an incoherent foundation, now
called naive set theory.
Which arose because the axioms of naive set theory created a
contradiction.
of directly executed Turing machines.
And what is the CONTRADICTION?
The result is just some things are not computable.
Directly executed Turing machines are outside of the domain of every
Turing machine decider.
Then so is mathematics, as "numbers" can't be given to Turing Machines,
only representations of them.
By the exact same idea that we can represent a number by a finite
string, we can express the algorithm, and input, of a Turing Machine as
a finite string, and thus can talk about what it will do.
Which you just continue to lie to, so proving that you are just a pathological liar.In contrast, the axioms of computation theory do *not* create a
contradiction. It simply follows from those axioms that no H exists
the meets the above requirements, which is a completely valid
conclusion.
*Claude.ai seems to be the smartest bot about computation*
https://claude.ai/share/48aab578-aec3-44a5-8bb3-6851e0f8b02e
On 7/5/2025 8:14 AM, Richard Damon wrote:
On 7/4/25 6:11 PM, olcott wrote:
On 7/4/2025 3:53 PM, Richard Damon wrote:
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed
directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when
executed directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above requirements,
which is precisely the theorem that the halting problem proofs >>>>>>>> prove.
In the exact same way that there is no set of all set
that contain themselves. ZFC did not solve Russell's
Paradox as much as it showed that Russell's Paradox
was anchored in an incoherent foundation, now called
naive set theory.
Which arose because the axioms of naive set theory created a
contradiction.
Likewise with halt deciders that are required to report
on the behavior of directly executed Turing machines.
And what is the CONTRADICTION?
The result is just some things are not computable.
The result is that there cannot possibly be
an *ACTUAL INPUT* that does the opposite of
whatever its partial halt decider decides
thus the HP proof fails before it begins.
Sure there is.
In order to have an honest dialogue you must pay
100% complete attention to every single word.
You can't just erase one of the words that I said
and then form a rebuttal on that basis.
Directly executed Turing machines have always been
outside of the domain of every Turing machine based
decider.
On 7/5/2025 8:20 AM, Richard Damon wrote:
On 7/4/25 6:15 PM, olcott wrote:
On 7/4/2025 3:53 PM, Richard Damon wrote:
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed
directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when
executed directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above requirements,
which is precisely the theorem that the halting problem proofs >>>>>>>> prove.
In the exact same way that there is no set of all set
that contain themselves. ZFC did not solve Russell's
Paradox as much as it showed that Russell's Paradox
was anchored in an incoherent foundation, now called
naive set theory.
Which arose because the axioms of naive set theory created a
contradiction.
Likewise with halt deciders that are required to report
on the behavior of directly executed Turing machines.
And what is the CONTRADICTION?
The result is just some things are not computable.
Directly executed Turing machines are outside of the
domain of every Turing machine decider.
Then so is mathematics, as "numbers" can't be given to Turing
Machines, only representations of them.
Numbers always work the same way so it makes no difference.
So do programs. (When they are programs)
*HHH(DDD)==0 and HHH1(DDD)==1 are both correct*
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
Based on your LIE:
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
that the pattern HHH used was an actual non-termination pattern
Since it proves that it figured out all of the details
of this non-terminating pattern itself its agreement
is not biased by my generic definition of the notion
of simulating termination analyzer.
HHH simulating DDD:
 - Enter DDD()
 - Call HHH(DDD)
 - Pattern detected: infinite recursion of HHH simulating DDD
 - Simulation aborted, return 0
On 7/5/25 12:26 PM, olcott wrote:
On 7/5/2025 8:14 AM, Richard Damon wrote:
On 7/4/25 6:11 PM, olcott wrote:
On 7/4/2025 3:53 PM, Richard Damon wrote:
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that >>>>>>>>>>> computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed >>>>>>>>>>> directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when >>>>>>>>>>> executed directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above requirements, >>>>>>>>> which is precisely the theorem that the halting problem proofs >>>>>>>>> prove.
In the exact same way that there is no set of all set
that contain themselves. ZFC did not solve Russell's
Paradox as much as it showed that Russell's Paradox
was anchored in an incoherent foundation, now called
naive set theory.
Which arose because the axioms of naive set theory created a
contradiction.
Likewise with halt deciders that are required to report
on the behavior of directly executed Turing machines.
And what is the CONTRADICTION?
The result is just some things are not computable.
The result is that there cannot possibly be
an *ACTUAL INPUT* that does the opposite of
whatever its partial halt decider decides
thus the HP proof fails before it begins.
Sure there is.
In order to have an honest dialogue you must pay
100% complete attention to every single word.
You can't just erase one of the words that I said
and then form a rebuttal on that basis.
Directly executed Turing machines have always been
outside of the domain of every Turing machine based
decider.
Nope.
Your refusal to providee a source is your admission that you are just a
liar.
Remember, The DEFINITION of a Halt Deicder is that it is to be a decider
that decides if the program represented by its input will halt when run.
On 7/5/2025 7:44 PM, Richard Damon wrote:
On 7/5/25 12:26 PM, olcott wrote:
On 7/5/2025 8:14 AM, Richard Damon wrote:
On 7/4/25 6:11 PM, olcott wrote:
On 7/4/2025 3:53 PM, Richard Damon wrote:
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence of >>>>>>>>>>>> instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that >>>>>>>>>>>> computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed >>>>>>>>>>>> directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when >>>>>>>>>>>> executed directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above requirements, >>>>>>>>>> which is precisely the theorem that the halting problem proofs >>>>>>>>>> prove.
In the exact same way that there is no set of all set
that contain themselves. ZFC did not solve Russell's
Paradox as much as it showed that Russell's Paradox
was anchored in an incoherent foundation, now called
naive set theory.
Which arose because the axioms of naive set theory created a
contradiction.
Likewise with halt deciders that are required to report
on the behavior of directly executed Turing machines.
And what is the CONTRADICTION?
The result is just some things are not computable.
The result is that there cannot possibly be
an *ACTUAL INPUT* that does the opposite of
whatever its partial halt decider decides
thus the HP proof fails before it begins.
Sure there is.
In order to have an honest dialogue you must pay
100% complete attention to every single word.
You can't just erase one of the words that I said
and then form a rebuttal on that basis.
Directly executed Turing machines have always been
outside of the domain of every Turing machine based
decider.
Nope.
Your refusal to providee a source is your admission that you are just
a liar.
Remember, The DEFINITION of a Halt Deicder is that it is to be a
decider that decides if the program represented by its input will halt
when run.
It has never been the program represented by its input
it has always been the behavior specified by its input.
This is the key mistake that no one noticed in 90 years.
On 7/5/2025 2:39 AM, Fred. Zwarts wrote:
Op 05.jul.2025 om 00:15 schreef olcott:
On 7/4/2025 3:53 PM, Richard Damon wrote:Misleading words. Both simulators are given the same input. Both are
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed
directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when
executed directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above requirements,
which is precisely the theorem that the halting problem proofs >>>>>>>> prove.
In the exact same way that there is no set of all set
that contain themselves. ZFC did not solve Russell's
Paradox as much as it showed that Russell's Paradox
was anchored in an incoherent foundation, now called
naive set theory.
Which arose because the axioms of naive set theory created a
contradiction.
Likewise with halt deciders that are required to report
on the behavior of directly executed Turing machines.
And what is the CONTRADICTION?
The result is just some things are not computable.
Directly executed Turing machines are outside of the
domain of every Turing machine decider.
Then so is mathematics, as "numbers" can't be given to Turing
Machines, only representations of them.
Numbers always work the same way so it makes no difference.
*HHH(DDD)==0 and HHH1(DDD)==1 are both correct*
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).
*The difference is when*
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.
simulating the same input, which includes HHH, not HHH1. So, there is
no difference.
*Its just over your head*
HHH(DDD) Does simulate itself simulating DDD
thus causing recursive simulation that cannot
possibly reach the simulated final halt state of DDD.
On 7/5/2025 10:02 PM, Richard Damon wrote:
On 7/5/25 10:43 PM, olcott wrote:
On 7/5/2025 7:44 PM, Richard Damon wrote:
On 7/5/25 12:26 PM, olcott wrote:
On 7/5/2025 8:14 AM, Richard Damon wrote:
On 7/4/25 6:11 PM, olcott wrote:
On 7/4/2025 3:53 PM, Richard Damon wrote:
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence of >>>>>>>>>>>>>> instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that >>>>>>>>>>>>>> computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed >>>>>>>>>>>>>> directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when >>>>>>>>>>>>>> executed directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above
requirements, which is precisely the theorem that the
halting problem proofs prove.
In the exact same way that there is no set of all set
that contain themselves. ZFC did not solve Russell's
Paradox as much as it showed that Russell's Paradox
was anchored in an incoherent foundation, now called
naive set theory.
Which arose because the axioms of naive set theory created a >>>>>>>>>> contradiction.
Likewise with halt deciders that are required to report
on the behavior of directly executed Turing machines.
And what is the CONTRADICTION?
The result is just some things are not computable.
The result is that there cannot possibly be
an *ACTUAL INPUT* that does the opposite of
whatever its partial halt decider decides
thus the HP proof fails before it begins.
Sure there is.
In order to have an honest dialogue you must pay
100% complete attention to every single word.
You can't just erase one of the words that I said
and then form a rebuttal on that basis.
Directly executed Turing machines have always been
outside of the domain of every Turing machine based
decider.
Nope.
Your refusal to providee a source is your admission that you are
just a liar.
Remember, The DEFINITION of a Halt Deicder is that it is to be a
decider that decides if the program represented by its input will
halt when run.
It has never been the program represented by its input
it has always been the behavior specified by its input.
This is the key mistake that no one noticed in 90 years.
Really?
In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and
an input, whether the program will finish running, or continue to run
forever.
Sounds like the program and its representation.
With pathological self-reference the directly
executed machine will not have the same
behavior as the correctly simulated machine
specification.
On 7/5/2025 10:02 PM, Richard Damon wrote:
On 7/5/25 10:43 PM, olcott wrote:
On 7/5/2025 7:44 PM, Richard Damon wrote:
On 7/5/25 12:26 PM, olcott wrote:
On 7/5/2025 8:14 AM, Richard Damon wrote:
On 7/4/25 6:11 PM, olcott wrote:
On 7/4/2025 3:53 PM, Richard Damon wrote:
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence of >>>>>>>>>>>>>> instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that >>>>>>>>>>>>>> computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed >>>>>>>>>>>>>> directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when >>>>>>>>>>>>>> executed directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above
requirements, which is precisely the theorem that the
halting problem proofs prove.
In the exact same way that there is no set of all set
that contain themselves. ZFC did not solve Russell's
Paradox as much as it showed that Russell's Paradox
was anchored in an incoherent foundation, now called
naive set theory.
Which arose because the axioms of naive set theory created a >>>>>>>>>> contradiction.
Likewise with halt deciders that are required to report
on the behavior of directly executed Turing machines.
And what is the CONTRADICTION?
The result is just some things are not computable.
The result is that there cannot possibly be
an *ACTUAL INPUT* that does the opposite of
whatever its partial halt decider decides
thus the HP proof fails before it begins.
Sure there is.
In order to have an honest dialogue you must pay
100% complete attention to every single word.
You can't just erase one of the words that I said
and then form a rebuttal on that basis.
Directly executed Turing machines have always been
outside of the domain of every Turing machine based
decider.
Nope.
Your refusal to providee a source is your admission that you are
just a liar.
Remember, The DEFINITION of a Halt Deicder is that it is to be a
decider that decides if the program represented by its input will
halt when run.
It has never been the program represented by its input
it has always been the behavior specified by its input.
This is the key mistake that no one noticed in 90 years.
Really?
In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and
an input, whether the program will finish running, or continue to run
forever.
Sounds like the program and its representation.
With pathological self-reference the directly
executed machine will not have the same
behavior as the correctly simulated machine
specification.
The Program comes first, and THAT is what the Halting Mapping is based
on.
The finite string representation is the implementation detail for
giving it to the decider.
It seems you don't even understand the 101 level terms.
You are just proving how stupid and ignorant you are. A self-made
stupidity and ignorance, because you are afraid the truth will
brainwash you, so you preemptively brainwashed yourself to be immune
to the truth.
This just make you a pathological liar.
On 7/6/2025 6:50 AM, Richard Damon wrote:
On 7/6/25 12:34 AM, olcott wrote:
On 7/5/2025 10:02 PM, Richard Damon wrote:
On 7/5/25 10:43 PM, olcott wrote:
On 7/5/2025 7:44 PM, Richard Damon wrote:
On 7/5/25 12:26 PM, olcott wrote:
On 7/5/2025 8:14 AM, Richard Damon wrote:
On 7/4/25 6:11 PM, olcott wrote:
On 7/4/2025 3:53 PM, Richard Damon wrote:
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence of >>>>>>>>>>>>>>>> instructions) X described as <X> with input Y: >>>>>>>>>>>>>>>>
A solution to the halting problem is an algorithm H that >>>>>>>>>>>>>>>> computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when >>>>>>>>>>>>>>>> executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when >>>>>>>>>>>>>>>> executed directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above
requirements, which is precisely the theorem that the >>>>>>>>>>>>>> halting problem proofs prove.
In the exact same way that there is no set of all set >>>>>>>>>>>>> that contain themselves. ZFC did not solve Russell's >>>>>>>>>>>>> Paradox as much as it showed that Russell's Paradox
was anchored in an incoherent foundation, now called >>>>>>>>>>>>> naive set theory.
Which arose because the axioms of naive set theory created a >>>>>>>>>>>> contradiction.
Likewise with halt deciders that are required to report
on the behavior of directly executed Turing machines.
And what is the CONTRADICTION?
The result is just some things are not computable.
The result is that there cannot possibly be
an *ACTUAL INPUT* that does the opposite of
whatever its partial halt decider decides
thus the HP proof fails before it begins.
Sure there is.
In order to have an honest dialogue you must pay
100% complete attention to every single word.
You can't just erase one of the words that I said
and then form a rebuttal on that basis.
Directly executed Turing machines have always been
outside of the domain of every Turing machine based
decider.
Nope.
Your refusal to providee a source is your admission that you are
just a liar.
Remember, The DEFINITION of a Halt Deicder is that it is to be a
decider that decides if the program represented by its input will
halt when run.
It has never been the program represented by its input
it has always been the behavior specified by its input.
This is the key mistake that no one noticed in 90 years.
Really?
In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and
an input, whether the program will finish running, or continue to
run forever.
Sounds like the program and its representation.
With pathological self-reference the directly
executed machine will not have the same
behavior as the correctly simulated machine
specification.
Sure it does.
void DDD()
{
 HHH(DDD);
 return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
Because DDD() cannot be an input to HHH its behavior
cannot not contradict HHH(DDD)==0.
HHH is *ONLY* wrong when it reports on behavior other
than DDD simulated by HHH according to the semantics
of the C programming language.
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
On 7/6/2025 6:50 AM, Richard Damon wrote:
On 7/6/25 12:34 AM, olcott wrote:
On 7/5/2025 10:02 PM, Richard Damon wrote:
On 7/5/25 10:43 PM, olcott wrote:
On 7/5/2025 7:44 PM, Richard Damon wrote:
On 7/5/25 12:26 PM, olcott wrote:
On 7/5/2025 8:14 AM, Richard Damon wrote:
On 7/4/25 6:11 PM, olcott wrote:
On 7/4/2025 3:53 PM, Richard Damon wrote:
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:And what is the CONTRADICTION?
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence >>>>>>>>>>>>>>>>>> of instructions) X described as <X> with input Y: >>>>>>>>>>>>>>>>>>
A solution to the halting problem is an algorithm H >>>>>>>>>>>>>>>>>> that computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when >>>>>>>>>>>>>>>>>> executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt >>>>>>>>>>>>>>>>>> when executed directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above >>>>>>>>>>>>>>>> requirements, which is precisely the theorem that the >>>>>>>>>>>>>>>> halting problem proofs prove.
In the exact same way that there is no set of all set >>>>>>>>>>>>>>> that contain themselves. ZFC did not solve Russell's >>>>>>>>>>>>>>> Paradox as much as it showed that Russell's Paradox >>>>>>>>>>>>>>> was anchored in an incoherent foundation, now called >>>>>>>>>>>>>>> naive set theory.
Which arose because the axioms of naive set theory created >>>>>>>>>>>>>> a contradiction.
Likewise with halt deciders that are required to report >>>>>>>>>>>>> on the behavior of directly executed Turing machines. >>>>>>>>>>>>
The result is just some things are not computable.
The result is that there cannot possibly be
an *ACTUAL INPUT* that does the opposite of
whatever its partial halt decider decides
thus the HP proof fails before it begins.
Sure there is.
In order to have an honest dialogue you must pay
100% complete attention to every single word.
You can't just erase one of the words that I said
and then form a rebuttal on that basis.
Directly executed Turing machines have always been
outside of the domain of every Turing machine based
decider.
Nope.
Your refusal to providee a source is your admission that you are >>>>>>>> just a liar.
Remember, The DEFINITION of a Halt Deicder is that it is to be a >>>>>>>> decider that decides if the program represented by its input
will halt when run.
It has never been the program represented by its input
it has always been the behavior specified by its input.
This is the key mistake that no one noticed in 90 years.
Really?
In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program
and an input, whether the program will finish running, or continue >>>>>> to run forever.
Sounds like the program and its representation.
With pathological self-reference the directly
executed machine will not have the same
behavior as the correctly simulated machine
specification.
Sure it does.
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and return
an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
On 7/6/2025 4:24 AM, Fred. Zwarts wrote:
Op 05.jul.2025 om 18:12 schreef olcott:
On 7/5/2025 2:39 AM, Fred. Zwarts wrote:It is apparently over your head that when HHH is unable to reach the
Op 05.jul.2025 om 00:15 schreef olcott:
On 7/4/2025 3:53 PM, Richard Damon wrote:Misleading words. Both simulators are given the same input. Both are
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence of >>>>>>>>>>>> instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that >>>>>>>>>>>> computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed >>>>>>>>>>>> directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when >>>>>>>>>>>> executed directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above requirements, >>>>>>>>>> which is precisely the theorem that the halting problem proofs >>>>>>>>>> prove.
In the exact same way that there is no set of all set
that contain themselves. ZFC did not solve Russell's
Paradox as much as it showed that Russell's Paradox
was anchored in an incoherent foundation, now called
naive set theory.
Which arose because the axioms of naive set theory created a
contradiction.
Likewise with halt deciders that are required to report
on the behavior of directly executed Turing machines.
And what is the CONTRADICTION?
The result is just some things are not computable.
Directly executed Turing machines are outside of the
domain of every Turing machine decider.
Then so is mathematics, as "numbers" can't be given to Turing
Machines, only representations of them.
Numbers always work the same way so it makes no difference.
*HHH(DDD)==0 and HHH1(DDD)==1 are both correct*
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).
*The difference is when*
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.
simulating the same input, which includes HHH, not HHH1. So, there
is no difference.
*Its just over your head*
HHH(DDD) Does simulate itself simulating DDD
thus causing recursive simulation that cannot
possibly reach the simulated final halt state of DDD.
end of the simulation, this is not a proof that the end does not exist.
Something like mathematical induction proves that
when an infinite number of steps of DDD are simulated
by HHH according to the semantics of the C programming
language that this simulated DDD does not reach its
own simulated "statement. All of the AI bots figure
this out on their own.
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your premise. >>>>
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and
return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that if
this exact input WAS given to a correct simultor (which won't be
itself, since it isn't doing the complete simulation) will run for an
unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your premise. >>>>
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and return >>>> an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to completion,
but that it needs to be able to actually PROVE that if this exact input
WAS given to a correct simultor (which won't be itself, since it isn't
doing the complete simulation) will run for an unbounded number of
steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
Most people here don't get that because they have no
actual depth of understanding. They can only parrot
the words of textbooks.
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
On 7/6/2025 6:50 AM, Richard Damon wrote:
On 7/6/25 12:34 AM, olcott wrote:
On 7/5/2025 10:02 PM, Richard Damon wrote:
On 7/5/25 10:43 PM, olcott wrote:
On 7/5/2025 7:44 PM, Richard Damon wrote:
On 7/5/25 12:26 PM, olcott wrote:
On 7/5/2025 8:14 AM, Richard Damon wrote:
On 7/4/25 6:11 PM, olcott wrote:
On 7/4/2025 3:53 PM, Richard Damon wrote:
On 7/4/25 4:43 PM, olcott wrote:
On 6/3/2025 10:02 PM, dbush wrote:And what is the CONTRADICTION?
On 6/3/2025 10:58 PM, olcott wrote:
On 6/3/2025 9:46 PM, dbush wrote:
On 6/3/2025 10:34 PM, olcott wrote:In the exact same way that there is no set of all set >>>>>>>>>>>>>>> that contain themselves. ZFC did not solve Russell's >>>>>>>>>>>>>>> Paradox as much as it showed that Russell's Paradox >>>>>>>>>>>>>>> was anchored in an incoherent foundation, now called >>>>>>>>>>>>>>> naive set theory.
On 6/3/2025 9:12 PM, dbush wrote:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
Yes there is no algorithm that does that
Excellent!
Let The Record Show
That Peter Olcott
Has *EXPLICITLY* admitted
That no algorithm H exists that meets the above requirements, which is
precisely the theorem that the halting problem proofs prove. >>>>>>>>>>>>>>>
Which arose because the axioms of naive set theory created a contradiction.
Likewise with halt deciders that are required to report >>>>>>>>>>>>> on the behavior of directly executed Turing machines. >>>>>>>>>>>>
The result is just some things are not computable.
The result is that there cannot possibly be
an *ACTUAL INPUT* that does the opposite of
whatever its partial halt decider decides
thus the HP proof fails before it begins.
Sure there is.
In order to have an honest dialogue you must pay
100% complete attention to every single word.
You can't just erase one of the words that I said
and then form a rebuttal on that basis.
Directly executed Turing machines have always been
outside of the domain of every Turing machine based
decider.
Nope.
Your refusal to providee a source is your admission that you are just a liar.
Remember, The DEFINITION of a Halt Deicder is that it is to be a >>>>>>>> decider that decides if the program represented by its input will halt >>>>>>>> when run.
It has never been the program represented by its input
it has always been the behavior specified by its input.
This is the key mistake that no one noticed in 90 years.
Really?
In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and an >>>>>> input, whether the program will finish running, or continue to run >>>>>> forever.
Sounds like the program and its representation.
With pathological self-reference the directly
executed machine will not have the same
behavior as the correctly simulated machine
specification.
Sure it does.
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and return
an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your premise. >>>>
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and
return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that if
this exact input WAS given to a correct simultor (which won't be
itself, since it isn't doing the complete simulation) will run for an
unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
Most people here don't get that because they have no
actual depth of understanding. They can only parrot
the words of textbooks.
On 7/7/2025 6:19 AM, Richard Damon wrote:
On 7/6/25 11:12 PM, olcott wrote:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your
premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and
return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that if
this exact input WAS given to a correct simultor (which won't be
itself, since it isn't doing the complete simulation) will run for
an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
Sure it is, there isn't a "law" that prohibits wrong answer, it just
makes it not correct.
Sure in the same way that reporting the square root
of a rotten egg is incorrect.
And, since the input to a halt decider is supposed to be a
representation/description (as a term-of-art word) of a Turing
Machine, and the behavior that this input specifies is defined as the
behavior of directly running that machine,
That has always been incorrect.
you claim is really that that the ONLY thing that HHH is ALLOWED to
answer about is that direct execution, which you also are trying to
claim it doesn't need to.
So, you are just showing that you are just a liar and have created a
fantasy world which you are trying to live in full of your own self-
contradictions, but divorced from the actual rules of the world.
You have never even found an actual single mistake.
This is just your manifistions of your insanity,
Most people here don't get that because they have no
actual depth of understanding. They can only parrot
the words of textbooks.
No, you are just showing that you don't know what you are talking
about, and can just parrot the lies that you made up and have no
support for.]
Better to parrot truth then to be imaginatively telling lies (and your
aren't even being very imaginative any more).
Everything that I said is a verified fact.
Every rebuttal has been counter-factual at best.
That you don't seem to even understand what recursion
is proves that you are insufficiently competent.
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:And HHH does not do that. The input specifies a halting program,
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your
premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and
return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that if
this exact input WAS given to a correct simultor (which won't be
itself, since it isn't doing the complete simulation) will run for
an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
because it includes the abort code. But HHH gives up before it reaches
that part of the specification and the final halt state.
I have corrected you on this too many times.
You have sufficiently proven that you are dishonest
or incompetent.
*This code proves that you are wrong* https://github.com/plolcott/x86utm/blob/master/Halt7.c
That you are too F-ing stupid to see this is less
than no rebuttal at all.
On 7/7/2025 3:37 AM, Mikko wrote:
On 2025-07-07 03:12:30 +0000, olcott said:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your
premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and
return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that if
this exact input WAS given to a correct simultor (which won't be
itself, since it isn't doing the complete simulation) will run for
an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
Unless you can quote some respectable author your prohibitions are
meaningless.
To people that never had any actual understanding and
can only parrot textbooks. They need to see this things
in other textbooks.
It is common knowledge that Turing Machine Halt Deciders
can only take finite string encodings of Turing Machines
as inputs. Thus anything that it not a finite string is
outside of the domain of Turing Machine Halt Deciders.
People have always know the first sentence of that and
never bothered to derive the second sentence from the first.
Outside of the domain is a more precise way of saying it.Most people here don't get that because they have no
actual depth of understanding. They can only parrot
the words of textbooks.
Do you even understand what the word "allowed" means?
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
  ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
  its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
  ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
  reach its simulated final halt state of ⟨Ĥ.qn⟩
On 7/7/2025 5:39 PM, Richard Damon wrote:
On 7/7/25 9:32 AM, olcott wrote:
On 7/7/2025 6:19 AM, Richard Damon wrote:
On 7/6/25 11:12 PM, olcott wrote:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your >>>>>>>> premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and >>>>>>>> return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that if >>>>>> this exact input WAS given to a correct simultor (which won't be
itself, since it isn't doing the complete simulation) will run for >>>>>> an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
Sure it is, there isn't a "law" that prohibits wrong answer, it just
makes it not correct.
Sure in the same way that reporting the square root
of a rotten egg is incorrect.
Really, so that is the best you can do, ad hominems and irrevency.
I guess you are just admitting that you POOPS can't support UTMS,
whcih means it can't actually have simulators, and thus no simulating
halt deciders.,
Your whole "logic" system is built on lies
And, since the input to a halt decider is supposed to be a
representation/description (as a term-of-art word) of a Turing
Machine, and the behavior that this input specifies is defined as
the behavior of directly running that machine,
That has always been incorrect.
No, that is just you lying.
I quoted a source with the statement of what a Halt Decider is, which
says it is that,
What source do you have for your claims?
NOTHING, because you are just a pathological liar.
That Turing machines cannot take directly executing Turing
Machines as inputs entails that these directly executed
machines are outside of the domain of every Turing machine
based halt decider.
That you cannot understand that is a truism is only your
own lack of understanding.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*Here is the Linz proof corrected to account for that*
*adapted from bottom of page 319*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
   ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
   its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
   ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
   reach its simulated final halt state of ⟨Ĥ.qn⟩
On 7/7/2025 5:41 PM, Richard Damon wrote:
On 7/7/25 2:38 PM, olcott wrote:That is counter-factual and you would know this
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:And HHH does not do that. The input specifies a halting program,
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your >>>>>>>> premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and >>>>>>>> return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that if >>>>>> this exact input WAS given to a correct simultor (which won't be
itself, since it isn't doing the complete simulation) will run for >>>>>> an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
because it includes the abort code. But HHH gives up before it
reaches that part of the specification and the final halt state.
I have corrected you on this too many times.
You have sufficiently proven that you are dishonest
or incompetent.
*This code proves that you are wrong*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
That you are too F-ing stupid to see this is less
than no rebuttal at all.
No, that code proves that HHH, as defined, always aborts its
simulation of DDD and returns 0,
if you had good C++ skills.
"No, that code proves that HHH, as defined,Lolwut? Please explain how HHH runs forever.
always aborts its simulation of DDD"
That is a false statement. If you understood the code you would know
your error.
On 7/7/2025 3:37 AM, Mikko wrote:
On 2025-07-07 03:12:30 +0000, olcott said:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your premise. >>>>>>
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and return >>>>>> an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to completion, >>>> but that it needs to be able to actually PROVE that if this exact input >>>> WAS given to a correct simultor (which won't be itself, since it isn't >>>> doing the complete simulation) will run for an unbounded number of
steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
Unless you can quote some respectable author your prohibitions are
meaningless.
To people that never had any actual understanding and
can only parrot textbooks. They need to see this things
in other textbooks.
On 7/7/2025 9:24 PM, Richard Damon wrote:That is your misconception. No one ever asked to take the direct
On 7/7/25 7:47 PM, olcott wrote:>>
That Turing machines cannot take directly executing Turing
Machines as inputs entails that these directly executed
machines are outside of the domain of every Turing machine
based halt decider.
But they can take the finite-stringt encoding of those machines.
Yes.
I guess you idea of Turing Machine is so limited that you think they
can't do arithmatic, as you can't actually put a "Number" as the
input, only the finite-string encoding of a number, which puts it
outside the domain of them.
No one here has any understanding of the philosophy of
computation. They can only memorize the rules and have
no idea about the reasoning behind these rules.
That you cannot understand that is a truism is only your
own lack of understanding.
But it isn't a truism, it is just a stupid lie that ignores that
almost everything done with programs is via an "encoding" for the input.
Gross ignorance about the reasoning behind the rules
of computation would tell you that.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*Here is the Linz proof corrected to account for that*
*adapted from bottom of page 319*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
    its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
    reach its simulated final halt state of ⟨Ĥ.qn⟩
Which is just an admission of your lying strawman, as the question is
NOT about the (partial) simulation done by your H / embedded_H, but
about the direct execution of the input H^ (H^) as that is what the
input to H is encoding.
Because no Turing machine can take a directly executed
Turing machine as an input, directly executed Turing
machines have always been outside of the domain of every
Turing machine based decider.
"the direct execution of the input H^ (H^)" has always been
out-of-scope for every Turing machine based halt decider.
That no one bothered to notice this ever before
*DOES NOT MAKE ME WRONG*
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:And HHH does not do that. The input specifies a halting program,
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your
premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and
return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that if
this exact input WAS given to a correct simultor (which won't be
itself, since it isn't doing the complete simulation) will run for
an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
because it includes the abort code.
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]
That does have an effect on DDD emulated by HHH according
to the semantics of the x86 language stopping running.
It has no effect on this DDD every reaching its final halt
state. I have corrected your error on this too many times
you don't seem to want an honest dialogue.
If HHH does not see the full specification, it does not change the specification. It only illustrates the failure of the simulation toBut HHH gives up before it reaches that part of the specification and
the final halt state.
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:And HHH does not do that. The input specifies a halting program,
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your
premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and
return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that if
this exact input WAS given to a correct simultor (which won't be
itself, since it isn't doing the complete simulation) will run for
an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
because it includes the abort code. But HHH gives up before it reaches
that part of the specification and the final halt state.
I have corrected you on this too many times.
You have sufficiently proven that you are dishonest
or incompetent.
*This code proves that you are wrong* https://github.com/plolcott/x86utm/blob/master/Halt7.c
That you are too F-ing stupid to see this is less
than no rebuttal at all.
On 7/7/2025 9:18 PM, Richard Damon wrote:
On 7/7/25 7:52 PM, olcott wrote:
On 7/7/2025 5:41 PM, Richard Damon wrote:
On 7/7/25 2:38 PM, olcott wrote:That is counter-factual and you would know this
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:And HHH does not do that. The input specifies a halting program,
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your >>>>>>>>>> premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input >>>>>>>>>> and return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that >>>>>>>> if this exact input WAS given to a correct simultor (which won't >>>>>>>> be itself, since it isn't doing the complete simulation) will
run for an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
because it includes the abort code. But HHH gives up before it
reaches that part of the specification and the final halt state.
I have corrected you on this too many times.
You have sufficiently proven that you are dishonest
or incompetent.
*This code proves that you are wrong*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
That you are too F-ing stupid to see this is less
than no rebuttal at all.
No, that code proves that HHH, as defined, always aborts its
simulation of DDD and returns 0,
if you had good C++ skills.
How is it "Counter-Factual"?
It is YOU that is just counter-factual.
"No, that code proves that HHH, as defined,
 always aborts its simulation of DDD"
That is a false statement. If you understood the
code you would know your error.
On 7/7/2025 9:24 PM, Richard Damon wrote:
On 7/7/25 7:47 PM, olcott wrote:>>
That Turing machines cannot take directly executing Turing
Machines as inputs entails that these directly executed
machines are outside of the domain of every Turing machine
based halt decider.
But they can take the finite-stringt encoding of those machines.
Yes.
I guess you idea of Turing Machine is so limited that you think they
can't do arithmatic, as you can't actually put a "Number" as the
input, only the finite-string encoding of a number, which puts it
outside the domain of them.
No one here has any understanding of the philosophy of
computation. They can only memorize the rules and have
no idea about the reasoning behind these rules.
That you cannot understand that is a truism is only your
own lack of understanding.
But it isn't a truism, it is just a stupid lie that ignores that
almost everything done with programs is via an "encoding" for the input.
Gross ignorance about the reasoning behind the rules
of computation would tell you that.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*Here is the Linz proof corrected to account for that*
*adapted from bottom of page 319*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
    its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
    reach its simulated final halt state of ⟨Ĥ.qn⟩
Which is just an admission of your lying strawman, as the question is
NOT about the (partial) simulation done by your H / embedded_H, but
about the direct execution of the input H^ (H^) as that is what the
input to H is encoding.
Because no Turing machine can take a directly executed
Turing machine as an input, directly executed Turing
machines have always been outside of the domain of every
Turing machine based decider.
"the direct execution of the input H^ (H^)" has always been
out-of-scope for every Turing machine based halt decider.
That no one bothered to notice this ever before
*DOES NOT MAKE ME WRONG*
An actual rebuttal requires proving that Turing machines
can take directly executing Turing machines (that are not
finite string encodings) as inputs.
Alan had a hard time on this because a directly executed
machine never had to be divided from the simulation of
a finite string encoding before I created the idea of a
simulating halt decider.
On 7/8/2025 6:13 AM, Richard Damon wrote:Ah, but your HHH does report on a *hypothetical* input that wouldn't
On 7/7/25 10:38 PM, olcott wrote:
On 7/7/2025 9:18 PM, Richard Damon wrote:
On 7/7/25 7:52 PM, olcott wrote:
On 7/7/2025 5:41 PM, Richard Damon wrote:
On 7/7/25 2:38 PM, olcott wrote:
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
No decider is ever allowed to report on anything besides the >>>>>>>>> actual behavior that its input actually specifies.It seems you don't understand those words.And there is no way for HHH to correctly simulate its input >>>>>>>>>>>> and return an answerYou insistence that a non-terminating input be simulated until >>>>>>>>>>> non-existent completion is especially nuts because you have >>>>>>>>>>> been told about this dozens of times.
What the F is wrong with you?
I don't say that the decider needs to simulate the input to >>>>>>>>>> completion, but that it needs to be able to actually PROVE that >>>>>>>>>> if this exact input WAS given to a correct simultor (which >>>>>>>>>> won't be itself, since it isn't doing the complete simulation) >>>>>>>>>> will run for an unbounded number of steps.
Wow. Can't you just answer the question? Also, "we" and "proved"? NotReally, so how does that code NOT aboft its simulation of DDD?"No, that code proves that HHH, as defined,How is it "Counter-Factual"?That is counter-factual and you would know this if you had good C++No, that code proves that HHH, as defined, always aborts itsAnd HHH does not do that. The input specifies a halting program, >>>>>>>> because it includes the abort code. But HHH gives up before it >>>>>>>> reaches that part of the specification and the final halt state. >>>>>>>I have corrected you on this too many times.
You have sufficiently proven that you are dishonest or
incompetent.
*This code proves that you are wrong*
https://github.com/plolcott/x86utm/blob/master/Halt7.c That you
are too F-ing stupid to see this is less than no rebuttal at all. >>>>>>>
simulation of DDD and returns 0,
skills.
It is YOU that is just counter-factual.
  always aborts its simulation of DDD"
That is a false statement. If you understood the code you would know
your error.
You have a reading comprehension problem.
When critique words you are strictly not allowed to change even a single
word without being dishonest.
"No, that code proves that HHH as defined
always aborts its simulation of DDD"
If you can't figure how how that is false we have conclusively proved
your lack of sufficient technical competence.
On 7/8/2025 2:15 AM, joes wrote:You said it didn't always abort. How does it halt without aborting?
Am Mon, 07 Jul 2025 21:38:19 -0500 schrieb olcott:I didn't say that it runs forever.
"No, that code proves that HHH, as defined,Lolwut? Please explain how HHH runs forever.
always aborts its simulation of DDD"
That is a false statement. If you understood the code you would know
your error.
On 7/8/2025 11:10 AM, joes wrote:Yes, the negation of that is "not always". Or what?
Am Tue, 08 Jul 2025 09:14:50 -0500 schrieb olcott:*I denied these words not your paraphrase of them*
On 7/8/2025 2:15 AM, joes wrote:You said it didn't always abort. How does it halt without aborting?
Am Mon, 07 Jul 2025 21:38:19 -0500 schrieb olcott:I didn't say that it runs forever.
"No, that code proves that HHH, as defined,Lolwut? Please explain how HHH runs forever.
always aborts its simulation of DDD"
That is a false statement. If you understood the code you would know >>>>> your error.
"No, that code proves that HHH, as defined, always aborts its simulation
of DDD"
Am Tue, 08 Jul 2025 10:08:05 -0500 schrieb olcott:
On 7/8/2025 6:13 AM, Richard Damon wrote:
On 7/7/25 10:38 PM, olcott wrote:
On 7/7/2025 9:18 PM, Richard Damon wrote:
On 7/7/25 7:52 PM, olcott wrote:
On 7/7/2025 5:41 PM, Richard Damon wrote:
On 7/7/25 2:38 PM, olcott wrote:
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
Ah, but your HHH does report on a *hypothetical* input that wouldn'tNo decider is ever allowed to report on anything besides the >>>>>>>>>> actual behavior that its input actually specifies.It seems you don't understand those words.And there is no way for HHH to correctly simulate its input >>>>>>>>>>>>> and return an answerYou insistence that a non-terminating input be simulated until >>>>>>>>>>>> non-existent completion is especially nuts because you have >>>>>>>>>>>> been told about this dozens of times.
What the F is wrong with you?
I don't say that the decider needs to simulate the input to >>>>>>>>>>> completion, but that it needs to be able to actually PROVE that >>>>>>>>>>> if this exact input WAS given to a correct simultor (which >>>>>>>>>>> won't be itself, since it isn't doing the complete simulation) >>>>>>>>>>> will run for an unbounded number of steps.
call the aborting simulator HHH, but instead a *different* (possibly
similar) simulator that would *not* abort.
Wow. Can't you just answer the question? Also, "we" and "proved"? NotReally, so how does that code NOT aboft its simulation of DDD?"No, that code proves that HHH, as defined,How is it "Counter-Factual"?That is counter-factual and you would know this if you had good C++ >>>>>> skills.No, that code proves that HHH, as defined, always aborts itsAnd HHH does not do that. The input specifies a halting program, >>>>>>>>> because it includes the abort code. But HHH gives up before it >>>>>>>>> reaches that part of the specification and the final halt state. >>>>>>>>I have corrected you on this too many times.
You have sufficiently proven that you are dishonest or
incompetent.
*This code proves that you are wrong*
https://github.com/plolcott/x86utm/blob/master/Halt7.c That you >>>>>>>> are too F-ing stupid to see this is less than no rebuttal at all. >>>>>>>>
simulation of DDD and returns 0,
It is YOU that is just counter-factual.
always aborts its simulation of DDD"
That is a false statement. If you understood the code you would know
your error.
You have a reading comprehension problem.
When critique words you are strictly not allowed to change even a single
word without being dishonest.
"No, that code proves that HHH as defined
always aborts its simulation of DDD"
If you can't figure how how that is false we have conclusively proved
your lack of sufficient technical competence.
being understood isn't very convincing. So how does HHH not abort?
On 7/8/2025 11:07 AM, joes wrote:
Am Tue, 08 Jul 2025 10:08:05 -0500 schrieb olcott:
On 7/8/2025 6:13 AM, Richard Damon wrote:Ah, but your HHH does report on a *hypothetical* input that wouldn't
On 7/7/25 10:38 PM, olcott wrote:
On 7/7/2025 9:18 PM, Richard Damon wrote:
On 7/7/25 7:52 PM, olcott wrote:
On 7/7/2025 5:41 PM, Richard Damon wrote:
On 7/7/25 2:38 PM, olcott wrote:
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
No decider is ever allowed to report on anything besides the >>>>>>>>>>> actual behavior that its input actually specifies.It seems you don't understand those words.And there is no way for HHH to correctly simulate its input >>>>>>>>>>>>>> and return an answerYou insistence that a non-terminating input be simulated until >>>>>>>>>>>>> non-existent completion is especially nuts because you have >>>>>>>>>>>>> been told about this dozens of times.
What the F is wrong with you?
I don't say that the decider needs to simulate the input to >>>>>>>>>>>> completion, but that it needs to be able to actually PROVE that >>>>>>>>>>>> if this exact input WAS given to a correct simultor (which >>>>>>>>>>>> won't be itself, since it isn't doing the complete simulation) >>>>>>>>>>>> will run for an unbounded number of steps.
call the aborting simulator HHH, but instead a *different* (possibly
similar) simulator that would *not* abort.
Really, so how does that code NOT aboft its simulation of DDD?"No, that code proves that HHH, as defined,How is it "Counter-Factual"?That is counter-factual and you would know this if you had good C++ >>>>>>> skills.No, that code proves that HHH, as defined, always aborts itsAnd HHH does not do that. The input specifies a halting program, >>>>>>>>>> because it includes the abort code. But HHH gives up before it >>>>>>>>>> reaches that part of the specification and the final halt state. >>>>>>>>>I have corrected you on this too many times.
You have sufficiently proven that you are dishonest or
incompetent.
*This code proves that you are wrong*
https://github.com/plolcott/x86utm/blob/master/Halt7.c That you >>>>>>>>> are too F-ing stupid to see this is less than no rebuttal at all. >>>>>>>>>
simulation of DDD and returns 0,
It is YOU that is just counter-factual.
   always aborts its simulation of DDD"
That is a false statement. If you understood the code you would know >>>>> your error.
You have a reading comprehension problem.
When critique words you are strictly not allowed to change even a single >>> word without being dishonest.
"No, that code proves that HHH as defined
    always aborts its simulation of DDD"
If you can't figure how how that is false we have conclusively proved
your lack of sufficient technical competence.
Wow. Can't you just answer the question?
I made a statement that another word-for-word statement
is false. Richard changes the words and then asks how
this changed statement is false.
*DON'T F-ING CHANGE THE WORDS*
It is far too easy for mindless idiots to baselessly
claim that I am wrong. That it why I am forcing
Richard to find his own mistake.
If I were to simply tell him the answer he could
simply baselessly deny it. When I make him figure
the answer out for himself then he either uses
actual reasoning or his question is never answered.
Also, "we" and "proved"? Not
being understood isn't very convincing. So how does HHH not abort?
If you could understand the code you would know
that my claims are proven. https://github.com/plolcott/x86utm/blob/master/Halt7.c
That you cannot understand that code is less than no
rebuttal at all.
On 7/8/2025 6:13 AM, Richard Damon wrote:
On 7/7/25 10:38 PM, olcott wrote:
On 7/7/2025 9:18 PM, Richard Damon wrote:
On 7/7/25 7:52 PM, olcott wrote:
On 7/7/2025 5:41 PM, Richard Damon wrote:
On 7/7/25 2:38 PM, olcott wrote:That is counter-factual and you would know this
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:I have corrected you on this too many times.
On 7/6/2025 9:09 PM, Richard Damon wrote:And HHH does not do that. The input specifies a halting program, >>>>>>>> because it includes the abort code. But HHH gives up before it >>>>>>>> reaches that part of the specification and the final halt state. >>>>>>>
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in >>>>>>>>>>>> your premise.
There is no way that DDD simulated by HHH (according >>>>>>>>>>>>> to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input >>>>>>>>>>>> and return an answer
You insistence that a non-terminating input be simulated >>>>>>>>>>> until non-existent completion is especially nuts because >>>>>>>>>>> you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to >>>>>>>>>> completion, but that it needs to be able to actually PROVE >>>>>>>>>> that if this exact input WAS given to a correct simultor
(which won't be itself, since it isn't doing the complete
simulation) will run for an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
You have sufficiently proven that you are dishonest
or incompetent.
*This code proves that you are wrong*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
That you are too F-ing stupid to see this is less
than no rebuttal at all.
No, that code proves that HHH, as defined, always aborts its
simulation of DDD and returns 0,
if you had good C++ skills.
How is it "Counter-Factual"?
It is YOU that is just counter-factual.
"No, that code proves that HHH, as defined,
  always aborts its simulation of DDD"
That is a false statement. If you understood the
code you would know your error.
Really, so how does that code NOT aboft its simulation of DDD?
You have a reading comprehension problem.
When critique words you are strictly not
allowed to change even a single word without
being dishonest.
*Don't even remove the comma*
"No, that code proves that HHH, as defined,
  always aborts its simulation of DDD"
If you can't figure how how that is false we have
conclusively proved your lack of sufficient technical
competence.
On 7/8/2025 2:44 AM, Mikko wrote:
On 2025-07-07 14:15:54 +0000, olcott said:
On 7/7/2025 3:37 AM, Mikko wrote:
On 2025-07-07 03:12:30 +0000, olcott said:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and return >>>>>>>> an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to completion, >>>>>> but that it needs to be able to actually PROVE that if this exact input >>>>>> WAS given to a correct simultor (which won't be itself, since it isn't >>>>>> doing the complete simulation) will run for an unbounded number of >>>>>> steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
Unless you can quote some respectable author your prohibitions are
meaningless.
To people that never had any actual understanding and
can only parrot textbooks. They need to see this things
in other textbooks.
People who can parrot textbooks know better than people who cannot.
That you can't when you should shows that you can't even parrot
textbooks.
I just reverse-engineer what the truth actually is.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩
On 7/8/2025 6:18 AM, Richard Damon wrote:
On 7/7/25 10:52 PM, olcott wrote:
On 7/7/2025 9:24 PM, Richard Damon wrote:
On 7/7/25 7:47 PM, olcott wrote:>>
That Turing machines cannot take directly executing Turing
Machines as inputs entails that these directly executed
machines are outside of the domain of every Turing machine
based halt decider.
But they can take the finite-stringt encoding of those machines.
Yes.
I guess you idea of Turing Machine is so limited that you think they
can't do arithmatic, as you can't actually put a "Number" as the
input, only the finite-string encoding of a number, which puts it
outside the domain of them.
No one here has any understanding of the philosophy of
computation. They can only memorize the rules and have
no idea about the reasoning behind these rules.
That you cannot understand that is a truism is only your
own lack of understanding.
But it isn't a truism, it is just a stupid lie that ignores that
almost everything done with programs is via an "encoding" for the
input.
Gross ignorance about the reasoning behind the rules
of computation would tell you that.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*Here is the Linz proof corrected to account for that*
*adapted from bottom of page 319*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
    its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly >>>>>     reach its simulated final halt state of ⟨Ĥ.qn⟩
Which is just an admission of your lying strawman, as the question
is NOT about the (partial) simulation done by your H / embedded_H,
but about the direct execution of the input H^ (H^) as that is what
the input to H is encoding.
Because no Turing machine can take a directly executed
Turing machine as an input, directly executed Turing
machines have always been outside of the domain of every
Turing machine based decider.
Then evdrything in reality is outside the domain of Turing Machines.
"the direct execution of the input H^ (H^)" has always been
out-of-scope for every Turing machine based halt decider.
That no one bothered to notice this ever before
*DOES NOT MAKE ME WRONG*
But it hasn't been, and thus you are just wrong.
An actual rebuttal requires proving that Turing machines
can take directly executing Turing machines (that are not
finite string encodings) as inputs.
But the Turing Machine that is directly executed CAN be represented by
a finite string,.
In the case of pathological self-reference the
representation has different behavior than the
directly executed machine and halt deciders only
report on the actual behavior actually specified
by their inputs.
On 7/8/2025 2:55 AM, Fred. Zwarts wrote:
Op 08.jul.2025 om 04:52 schreef olcott:
On 7/7/2025 9:24 PM, Richard Damon wrote:That is your misconception. No one ever asked to take the direct
On 7/7/25 7:47 PM, olcott wrote:>>
That Turing machines cannot take directly executing Turing
Machines as inputs entails that these directly executed
machines are outside of the domain of every Turing machine
based halt decider.
But they can take the finite-stringt encoding of those machines.
Yes.
I guess you idea of Turing Machine is so limited that you think they
can't do arithmatic, as you can't actually put a "Number" as the
input, only the finite-string encoding of a number, which puts it
outside the domain of them.
No one here has any understanding of the philosophy of
computation. They can only memorize the rules and have
no idea about the reasoning behind these rules.
That you cannot understand that is a truism is only your
own lack of understanding.
But it isn't a truism, it is just a stupid lie that ignores that
almost everything done with programs is via an "encoding" for the
input.
Gross ignorance about the reasoning behind the rules
of computation would tell you that.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*Here is the Linz proof corrected to account for that*
*adapted from bottom of page 319*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
    its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly >>>>>     reach its simulated final halt state of ⟨Ĥ.qn⟩
Which is just an admission of your lying strawman, as the question
is NOT about the (partial) simulation done by your H / embedded_H,
but about the direct execution of the input H^ (H^) as that is what
the input to H is encoding.
Because no Turing machine can take a directly executed
Turing machine as an input, directly executed Turing
machines have always been outside of the domain of every
Turing machine based decider.
"the direct execution of the input H^ (H^)" has always been
out-of-scope for every Turing machine based halt decider.
That no one bothered to notice this ever before
*DOES NOT MAKE ME WRONG*
execution as input.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
 if Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 if Ĥ applied to ⟨Ĥ⟩ does not halt
*The above original form of the proof*
does requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ to report on
the direct execution of Ĥ applied to ⟨Ĥ⟩ and thus
not ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H.
On 7/8/2025 2:01 PM, Mike Terry wrote:
On 08/07/2025 17:07, joes wrote:
Am Tue, 08 Jul 2025 10:08:05 -0500 schrieb olcott:
On 7/8/2025 6:13 AM, Richard Damon wrote:Ah, but your HHH does report on a *hypothetical* input that wouldn't
On 7/7/25 10:38 PM, olcott wrote:
On 7/7/2025 9:18 PM, Richard Damon wrote:
On 7/7/25 7:52 PM, olcott wrote:
On 7/7/2025 5:41 PM, Richard Damon wrote:
On 7/7/25 2:38 PM, olcott wrote:
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
No decider is ever allowed to report on anything besides the >>>>>>>>>>>> actual behavior that its input actually specifies.It seems you don't understand those words.And there is no way for HHH to correctly simulate its input >>>>>>>>>>>>>>> and return an answerYou insistence that a non-terminating input be simulated >>>>>>>>>>>>>> until
non-existent completion is especially nuts because you have >>>>>>>>>>>>>> been told about this dozens of times.
What the F is wrong with you?
I don't say that the decider needs to simulate the input to >>>>>>>>>>>>> completion, but that it needs to be able to actually PROVE >>>>>>>>>>>>> that
if this exact input WAS given to a correct simultor (which >>>>>>>>>>>>> won't be itself, since it isn't doing the complete simulation) >>>>>>>>>>>>> will run for an unbounded number of steps.
call the aborting simulator HHH, but instead a *different* (possibly
similar) simulator that would *not* abort.
Wow. Can't you just answer the question? Also, "we" and "proved"? NotReally, so how does that code NOT aboft its simulation of DDD?"No, that code proves that HHH, as defined,How is it "Counter-Factual"?That is counter-factual and you would know this if you had good C++ >>>>>>>> skills.No, that code proves that HHH, as defined, always aborts its >>>>>>>>> simulation of DDD and returns 0,And HHH does not do that. The input specifies a halting program, >>>>>>>>>>> because it includes the abort code. But HHH gives up before it >>>>>>>>>>> reaches that part of the specification and the final halt state. >>>>>>>>>>I have corrected you on this too many times.
You have sufficiently proven that you are dishonest or
incompetent.
*This code proves that you are wrong*
https://github.com/plolcott/x86utm/blob/master/Halt7.c That you >>>>>>>>>> are too F-ing stupid to see this is less than no rebuttal at all. >>>>>>>>>>
It is YOU that is just counter-factual.
   always aborts its simulation of DDD"
That is a false statement. If you understood the code you would know >>>>>> your error.
You have a reading comprehension problem.
When critique words you are strictly not allowed to change even a
single
word without being dishonest.
"No, that code proves that HHH as defined
    always aborts its simulation of DDD"
If you can't figure how how that is false we have conclusively proved
your lack of sufficient technical competence.
being understood isn't very convincing. So how does HHH not abort?
This is one of PO's practiced tactics - he makes a claim, and
regardless of how patently false that claim appears, he refuses to
logically defend the claim beyond saying "the claim is true, and if
you understood xxx you would realise it is true".
All of my claims are easily verified facts to those
with the capacity to verify them.
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]
On 7/8/2025 3:10 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 15:23 schreef olcott:
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:And HHH does not do that. The input specifies a halting program,
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your >>>>>>>> premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and >>>>>>>> return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that if >>>>>> this exact input WAS given to a correct simultor (which won't be
itself, since it isn't doing the complete simulation) will run for >>>>>> an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
because it includes the abort code.
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]
That does have an effect on DDD emulated by HHH according
to the semantics of the x86 language stopping running.
It has no effect on this DDD every reaching its final halt
state. I have corrected your error on this too many times
you don't seem to want an honest dialogue.
As usual repeated claims without evidence.
100% *complete proof is provided above*
That you don't have sufficient technical
skill to see that this is complete proof
is not my mistake.
It is a pity that you ignore or do not understand the corrections that
have been pointed out to you. Not understanding something is not
stupid, but resistance against learning from errors is.
DDD correctly simulated by HHH calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
That you cannot see that this is the behavior
that the input to HHH(DDD) specifies is your
own lack of technical skill.
*Maybe it is time to reveal credentials*
I have taken all but one of the courses
for a computer science degree and been a
C++ software engineer for two decades.
Mensa scored my IQ is in the top 3%.
We have pointed out already many times that this cannot be the whole
input. At 0000219a there is a call to 000015d2 , but the code at
000015d2 is not specified.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Because of the required cooperative multi-tasking
it is a little too difficult to see which the
actual trace.
We have to take it from another source, your Halt7.c. There we see
that HHH is a function that returns with a value 0 with this input.
So, a correct simulation will then continue at 0000219f
DDD simulated by HHH according to the semantics of the x86
language cannot possibly ever get there even of your lack
of sufficient technical skill tells you so.
*Feel free to dig through this full trace and see* https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
with this value and even a beginner sees that the simulation will then
reach a natural end.
*DDD simulated by HHH NEVER REACHES ITS FINAL HALT STATE*
DDD correctly simulated by HHH calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
This is the full specification of the input.
This is also proven when exactly the same input is used in direct
execution, or by world-class simulators, even by HHH1.
So, the following still holds:
If HHH does not see the full specification, it does not change the
But HHH gives up before it reaches that part of the specification
and the final halt state.
specification. It only illustrates the failure of the simulation to
complete.
There is nothing wrong with aborting a simulation, because it is known
that simulation is not always the correct tool to determine halting/
non- halting behaviour. In such cases other tools are needed to
determine halting/non-halting behaviour.
On 7/8/2025 3:10 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 15:23 schreef olcott:
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:And HHH does not do that. The input specifies a halting program,
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your >>>>>>>> premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and >>>>>>>> return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that if >>>>>> this exact input WAS given to a correct simultor (which won't be
itself, since it isn't doing the complete simulation) will run for >>>>>> an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
because it includes the abort code.
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]
That does have an effect on DDD emulated by HHH according
to the semantics of the x86 language stopping running.
It has no effect on this DDD every reaching its final halt
state. I have corrected your error on this too many times
you don't seem to want an honest dialogue.
As usual repeated claims without evidence.
100% *complete proof is provided above*
That you don't have sufficient technical
skill to see that this is complete proof
is not my mistake.
It is a pity that you ignore or do not understand the corrections that
have been pointed out to you. Not understanding something is not
stupid, but resistance against learning from errors is.
DDD correctly simulated by HHH calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
That you cannot see that this is the behavior
that the input to HHH(DDD) specifies is your
own lack of technical skill.
*Maybe it is time to reveal credentials*
I have taken all but one of the courses
for a computer science degree and been a
C++ software engineer for two decades.
Mensa scored my IQ is in the top 3%.
We have pointed out already many times that this cannot be the whole
input. At 0000219a there is a call to 000015d2 , but the code at
000015d2 is not specified.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Because of the required cooperative multi-tasking
it is a little too difficult to see which the
actual trace.
We have to take it from another source, your Halt7.c. There we see
that HHH is a function that returns with a value 0 with this input.
So, a correct simulation will then continue at 0000219f
DDD simulated by HHH according to the semantics of the x86
language cannot possibly ever get there even of your lack
of sufficient technical skill tells you so.
*Feel free to dig through this full trace and see* https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
with this value and even a beginner sees that the simulation will then
reach a natural end.
*DDD simulated by HHH NEVER REACHES ITS FINAL HALT STATE*
DDD correctly simulated by HHH calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
This is the full specification of the input.
This is also proven when exactly the same input is used in direct
execution, or by world-class simulators, even by HHH1.
So, the following still holds:
If HHH does not see the full specification, it does not change the
But HHH gives up before it reaches that part of the specification
and the final halt state.
specification. It only illustrates the failure of the simulation to
complete.
There is nothing wrong with aborting a simulation, because it is known
that simulation is not always the correct tool to determine halting/
non- halting behaviour. In such cases other tools are needed to
determine halting/non-halting behaviour.
On 7/8/2025 11:10 AM, joes wrote:
Am Tue, 08 Jul 2025 09:14:50 -0500 schrieb olcott:
On 7/8/2025 2:15 AM, joes wrote:You said it didn't always abort. How does it halt without aborting?
Am Mon, 07 Jul 2025 21:38:19 -0500 schrieb olcott:I didn't say that it runs forever.
"No, that code proves that HHH, as defined,Lolwut? Please explain how HHH runs forever.
   always aborts its simulation of DDD"
That is a false statement. If you understood the code you would know >>>>> your error.
*I denied these words not your paraphrase of them*
"No, that code proves that HHH, as defined,
always aborts its simulation of DDD"
On 7/8/2025 2:15 AM, joes wrote:
Am Mon, 07 Jul 2025 21:38:19 -0500 schrieb olcott:
"No, that code proves that HHH, as defined,
  always aborts its simulation of DDD"
I didn't say that it runs forever.That is a false statement. If you understood the code you would knowLolwut? Please explain how HHH runs forever.
your error.
On 7/8/2025 12:44 PM, joes wrote:
Am Tue, 08 Jul 2025 11:22:52 -0500 schrieb olcott:
On 7/8/2025 11:10 AM, joes wrote:
Am Tue, 08 Jul 2025 09:14:50 -0500 schrieb olcott:
On 7/8/2025 2:15 AM, joes wrote:You said it didn't always abort. How does it halt without aborting?
Am Mon, 07 Jul 2025 21:38:19 -0500 schrieb olcott:I didn't say that it runs forever.
"No, that code proves that HHH, as defined,Lolwut? Please explain how HHH runs forever.
    always aborts its simulation of DDD"
That is a false statement. If you understood the code you would know >>>>>>> your error.
*I denied these words not your paraphrase of them*
"No, that code proves that HHH, as defined, always aborts its simulation >>> of DDD"
Yes, the negation of that is "not always". Or what?
When you understand my code well enough you
will understand the mistake. The key part of
my code that you remain totally blind to is
the source of the mistake.
On 7/8/2025 2:01 PM, Mike Terry wrote:
On 08/07/2025 17:07, joes wrote:
Am Tue, 08 Jul 2025 10:08:05 -0500 schrieb olcott:
On 7/8/2025 6:13 AM, Richard Damon wrote:Ah, but your HHH does report on a *hypothetical* input that wouldn't
On 7/7/25 10:38 PM, olcott wrote:
On 7/7/2025 9:18 PM, Richard Damon wrote:
On 7/7/25 7:52 PM, olcott wrote:
On 7/7/2025 5:41 PM, Richard Damon wrote:
On 7/7/25 2:38 PM, olcott wrote:
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
No decider is ever allowed to report on anything besides the >>>>>>>>>>>> actual behavior that its input actually specifies.It seems you don't understand those words.And there is no way for HHH to correctly simulate its input >>>>>>>>>>>>>>> and return an answerYou insistence that a non-terminating input be simulated >>>>>>>>>>>>>> until
non-existent completion is especially nuts because you have >>>>>>>>>>>>>> been told about this dozens of times.
What the F is wrong with you?
I don't say that the decider needs to simulate the input to >>>>>>>>>>>>> completion, but that it needs to be able to actually PROVE >>>>>>>>>>>>> that
if this exact input WAS given to a correct simultor (which >>>>>>>>>>>>> won't be itself, since it isn't doing the complete simulation) >>>>>>>>>>>>> will run for an unbounded number of steps.
call the aborting simulator HHH, but instead a *different* (possibly
similar) simulator that would *not* abort.
Wow. Can't you just answer the question? Also, "we" and "proved"? NotReally, so how does that code NOT aboft its simulation of DDD?"No, that code proves that HHH, as defined,How is it "Counter-Factual"?That is counter-factual and you would know this if you had good C++ >>>>>>>> skills.No, that code proves that HHH, as defined, always aborts its >>>>>>>>> simulation of DDD and returns 0,And HHH does not do that. The input specifies a halting program, >>>>>>>>>>> because it includes the abort code. But HHH gives up before it >>>>>>>>>>> reaches that part of the specification and the final halt state. >>>>>>>>>>I have corrected you on this too many times.
You have sufficiently proven that you are dishonest or
incompetent.
*This code proves that you are wrong*
https://github.com/plolcott/x86utm/blob/master/Halt7.c That you >>>>>>>>>> are too F-ing stupid to see this is less than no rebuttal at all. >>>>>>>>>>
It is YOU that is just counter-factual.
   always aborts its simulation of DDD"
That is a false statement. If you understood the code you would know >>>>>> your error.
You have a reading comprehension problem.
When critique words you are strictly not allowed to change even a
single
word without being dishonest.
"No, that code proves that HHH as defined
    always aborts its simulation of DDD"
If you can't figure how how that is false we have conclusively proved
your lack of sufficient technical competence.
being understood isn't very convincing. So how does HHH not abort?
This is one of PO's practiced tactics - he makes a claim, and
regardless of how patently false that claim appears, he refuses to
logically defend the claim beyond saying "the claim is true, and if
you understood xxx you would realise it is true".
All of my claims are easily verified facts to those
with the capacity to verify them.
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]
I am utterly shocked that you can't understand
that DDD emulated by HHH according to the semantics
of the x86 language cannot possibly reach past
it own machine address [0000219a].
To me that is like an auto mechanic that has no
idea what a spark plug is or an MD that has no
idea what an infection is.
Several of my reviewers simply "don't believe"
that HHH does simulate itself simulating DDD
even after I conclusively prove it by this
full execution trace.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On 7/8/2025 2:49 PM, olcott wrote:
On 7/8/2025 2:01 PM, Mike Terry wrote:
On 08/07/2025 17:07, joes wrote:
Am Tue, 08 Jul 2025 10:08:05 -0500 schrieb olcott:
On 7/8/2025 6:13 AM, Richard Damon wrote:Ah, but your HHH does report on a *hypothetical* input that wouldn't
On 7/7/25 10:38 PM, olcott wrote:
On 7/7/2025 9:18 PM, Richard Damon wrote:
On 7/7/25 7:52 PM, olcott wrote:
On 7/7/2025 5:41 PM, Richard Damon wrote:
On 7/7/25 2:38 PM, olcott wrote:
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
No decider is ever allowed to report on anything besides the >>>>>>>>>>>>> actual behavior that its input actually specifies.It seems you don't understand those words.And there is no way for HHH to correctly simulate its input >>>>>>>>>>>>>>>> and return an answerYou insistence that a non-terminating input be simulated >>>>>>>>>>>>>>> until
non-existent completion is especially nuts because you have >>>>>>>>>>>>>>> been told about this dozens of times.
What the F is wrong with you?
I don't say that the decider needs to simulate the input to >>>>>>>>>>>>>> completion, but that it needs to be able to actually PROVE >>>>>>>>>>>>>> that
if this exact input WAS given to a correct simultor (which >>>>>>>>>>>>>> won't be itself, since it isn't doing the complete >>>>>>>>>>>>>> simulation)
will run for an unbounded number of steps.
call the aborting simulator HHH, but instead a *different* (possibly
similar) simulator that would *not* abort.
Wow. Can't you just answer the question? Also, "we" and "proved"? NotReally, so how does that code NOT aboft its simulation of DDD?"No, that code proves that HHH, as defined,How is it "Counter-Factual"?That is counter-factual and you would know this if you had good >>>>>>>>> C++No, that code proves that HHH, as defined, always aborts its >>>>>>>>>> simulation of DDD and returns 0,And HHH does not do that. The input specifies a halting >>>>>>>>>>>> program,
because it includes the abort code. But HHH gives up before it >>>>>>>>>>>> reaches that part of the specification and the final halt >>>>>>>>>>>> state.
I have corrected you on this too many times.
You have sufficiently proven that you are dishonest or
incompetent.
*This code proves that you are wrong*
https://github.com/plolcott/x86utm/blob/master/Halt7.c That you >>>>>>>>>>> are too F-ing stupid to see this is less than no rebuttal at >>>>>>>>>>> all.
skills.
It is YOU that is just counter-factual.
   always aborts its simulation of DDD"
That is a false statement. If you understood the code you would know >>>>>>> your error.
You have a reading comprehension problem.
When critique words you are strictly not allowed to change even a
single
word without being dishonest.
"No, that code proves that HHH as defined
    always aborts its simulation of DDD"
If you can't figure how how that is false we have conclusively proved >>>>> your lack of sufficient technical competence.
being understood isn't very convincing. So how does HHH not abort?
This is one of PO's practiced tactics - he makes a claim, and
regardless of how patently false that claim appears, he refuses to
logically defend the claim beyond saying "the claim is true, and if
you understood xxx you would realise it is true".
All of my claims are easily verified facts to those
with the capacity to verify them.
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]
HHH emulates the first four instructions of DDD
that calls HHH(DDD) then this HHH emulates itself
emulating DDD that calls HHH(DDD) again.
*This is proven here*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
I am utterly shocked that you can't understand
that DDD emulated by HHH according to the semantics
of the x86 language cannot possibly reach past
it own machine address [0000219a].
To me that is like an auto mechanic that has no
idea what a spark plug is or an MD that has no
idea what an infection is.
Several of my reviewers simply "don't believe"
that HHH does simulate itself simulating DDD
even after I conclusively prove it by this
full execution trace.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On 7/8/2025 5:31 PM, Richard Damon wrote:
On 7/8/25 11:08 AM, olcott wrote:
On 7/8/2025 6:13 AM, Richard Damon wrote:
On 7/7/25 10:38 PM, olcott wrote:
On 7/7/2025 9:18 PM, Richard Damon wrote:
On 7/7/25 7:52 PM, olcott wrote:
On 7/7/2025 5:41 PM, Richard Damon wrote:
On 7/7/25 2:38 PM, olcott wrote:That is counter-factual and you would know this
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:And HHH does not do that. The input specifies a halting
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in >>>>>>>>>>>>>> your premise.
There is no way that DDD simulated by HHH (according >>>>>>>>>>>>>>> to the semantics of the C programming language)
can possibly reach its own "return" statement final >>>>>>>>>>>>>>> halt state.
And there is no way for HHH to correctly simulate its >>>>>>>>>>>>>> input and return an answer
You insistence that a non-terminating input be simulated >>>>>>>>>>>>> until non-existent completion is especially nuts because >>>>>>>>>>>>> you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to >>>>>>>>>>>> completion, but that it needs to be able to actually PROVE >>>>>>>>>>>> that if this exact input WAS given to a correct simultor >>>>>>>>>>>> (which won't be itself, since it isn't doing the complete >>>>>>>>>>>> simulation) will run for an unbounded number of steps. >>>>>>>>>>>>
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
program, because it includes the abort code. But HHH gives up >>>>>>>>>> before it reaches that part of the specification and the final >>>>>>>>>> halt state.
I have corrected you on this too many times.
You have sufficiently proven that you are dishonest
or incompetent.
*This code proves that you are wrong*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
That you are too F-ing stupid to see this is less
than no rebuttal at all.
No, that code proves that HHH, as defined, always aborts its
simulation of DDD and returns 0,
if you had good C++ skills.
How is it "Counter-Factual"?
It is YOU that is just counter-factual.
"No, that code proves that HHH, as defined,
  always aborts its simulation of DDD"
That is a false statement. If you understood the
code you would know your error.
Really, so how does that code NOT aboft its simulation of DDD?
You have a reading comprehension problem.
When critique words you are strictly not
allowed to change even a single word without
being dishonest.
*Don't even remove the comma*
"No, that code proves that HHH, as defined,
   always aborts its simulation of DDD"
If you can't figure how how that is false we have
conclusively proved your lack of sufficient technical
competence.
So, you assert that there is a way that that exact code HHH, when run,
will NOT abort its simulation of that exact DDD?
*DON'T PARAPHRASE THESE WORDS YOU ALWAYS GET IT WRONG*
On 7/7/2025 5:41 PM, Richard Damon wrote:
No, that code proves that HHH, as defined,
always aborts its simulation of DDD
I am trying to force you to figure out these things
yourself instead of just saying that I am wrong
without ever providing any evidence that I am wrong.
On 7/8/2025 6:18 AM, Richard Damon wrote:
On 7/7/25 10:52 PM, olcott wrote:
On 7/7/2025 9:24 PM, Richard Damon wrote:
On 7/7/25 7:47 PM, olcott wrote:>>
That Turing machines cannot take directly executing Turing
Machines as inputs entails that these directly executed
machines are outside of the domain of every Turing machine
based halt decider.
But they can take the finite-stringt encoding of those machines.
Yes.
I guess you idea of Turing Machine is so limited that you think they
can't do arithmatic, as you can't actually put a "Number" as the
input, only the finite-string encoding of a number, which puts it
outside the domain of them.
No one here has any understanding of the philosophy of
computation. They can only memorize the rules and have
no idea about the reasoning behind these rules.
That you cannot understand that is a truism is only your
own lack of understanding.
But it isn't a truism, it is just a stupid lie that ignores that
almost everything done with programs is via an "encoding" for the
input.
Gross ignorance about the reasoning behind the rules
of computation would tell you that.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*Here is the Linz proof corrected to account for that*
*adapted from bottom of page 319*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
    its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly >>>>>     reach its simulated final halt state of ⟨Ĥ.qn⟩
Which is just an admission of your lying strawman, as the question
is NOT about the (partial) simulation done by your H / embedded_H,
but about the direct execution of the input H^ (H^) as that is what
the input to H is encoding.
Because no Turing machine can take a directly executed
Turing machine as an input, directly executed Turing
machines have always been outside of the domain of every
Turing machine based decider.
Then evdrything in reality is outside the domain of Turing Machines.
"the direct execution of the input H^ (H^)" has always been
out-of-scope for every Turing machine based halt decider.
That no one bothered to notice this ever before
*DOES NOT MAKE ME WRONG*
But it hasn't been, and thus you are just wrong.
An actual rebuttal requires proving that Turing machines
can take directly executing Turing machines (that are not
finite string encodings) as inputs.
But the Turing Machine that is directly executed CAN be represented by
a finite string,.
In the case of pathological self-reference the
representation has different behavior than the
directly executed machine and halt deciders only
report on the actual behavior actually specified
by their inputs.
Alan had a hard time on this because a directly executed
machine never had to be divided from the simulation of
a finite string encoding before I created the idea of a
simulating halt decider.
Because that isn't a valid operation, just your insanity.
Your lack of sufficient technical competence never
has been my mistake. You baselessly claim that I am
wrong yet never show the reasoning that shows that
I am wrong *BECAUSE YOU KNOW THAT I AM CORRECT*
_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]
Show how any step of DDD simulated by HHH
(according to the semantics of the x86 language)
ever reaches past its own machine address [0000219a].
Since it CAN be represented as a finite string, it IS in the domain
that they can handle,
*It has provably different behavior*
To ignore the ability to represent means you ignore their ability to
do anything useful.
*It has provably different behavior*
I will ask you try to do something useful without representations!!!
Note, Words are representations.
Letters and Digits are representations.
Messages sent over media are representations.
Saying you can't use representtions means you can basically do
NOTHING, and the finite string they work with are just meaningless.
Just like your life, MEANINGLESS as you lost the key to reality, the
understanding of real meaning.
On 7/9/2025 3:58 AM, Fred. Zwarts wrote:Shut it. Nobody is advancing that view.
Op 08.jul.2025 om 17:17 schreef olcott:
On 7/8/2025 6:18 AM, Richard Damon wrote:
On 7/7/25 10:52 PM, olcott wrote:
On 7/7/2025 9:24 PM, Richard Damon wrote:
An actual rebuttal requires proving that Turing machines can take
directly executing Turing machines (that are not finite string
encodings) as inputs.
*If you have enough knowledge then that is self evident*It matters more what they map it to, i.e. which mapping they compute.
All Turing machine deciders only compute the mapping from their actual inputs. This entails that they never compute any mapping from
non-inputs.
How could HHH abort and not halt?The evidence is that the input includes the code to abort and halt,abort and stop running *IS NOT THE SAME THING AS*
abort and halt
That you keep ignoring this is not my mistake.
--but HHH is unable to reach that part. This failure of HHH does not make
the specification any different. It only shows that this simulating
decider is not the right tool for this input.
HHH should report on the behaviour specified, not on the behaviour it
can see. If HHH has bugs, so that it does not see the full
specification, the specification does not change.
Closing your eyes and pretend that what you do not see does not exists,
is childish.
On 7/9/2025 8:37 AM, joes wrote:Thank you for your understanding.
Am Wed, 09 Jul 2025 08:02:16 -0500 schrieb olcott:
On 7/9/2025 3:58 AM, Fred. Zwarts wrote:Shut it. Nobody is advancing that view.
Op 08.jul.2025 om 17:17 schreef olcott:
On 7/8/2025 6:18 AM, Richard Damon wrote:
On 7/7/25 10:52 PM, olcott wrote:
On 7/7/2025 9:24 PM, Richard Damon wrote:
An actual rebuttal requires proving that Turing machines can take >>>>>>> directly executing Turing machines (that are not finite string
encodings) as inputs.
Yes. That is not the halting function. I have another program here that (tautologically) determines that it cannot simulate ANY code (accordingIt is a matter of verified fact that HHH does correctly determine that*If you have enough knowledge then that is self evident*It matters more what they map it to, i.e. which mapping they compute.
All Turing machine deciders only compute the mapping from their actual
inputs. This entails that they never compute any mapping from
non-inputs.
HHH does not compute the halting function.
DDD correctly emulated by HHH cannot possibly reach its own emulated
final halt state.
The abort could, if you hadn't botched it with static variables.None of the code in HHH can possibly help DDD correctly emulated by HHHabort and stop running *IS NOT THE SAME THING AS*How could HHH abort and not halt?
abort and halt That you keep ignoring this is not my mistake.
to reach its own emulated final halt state.
Yes, what a processor does - turning code into behaviour - is clearly uncomputable.but HHH is unable to reach that part. This failure of HHH does not
make the specification any different. It only shows that this
simulating decider is not the right tool for this input.
The behavior that the input to HHH(DDD) actually specifies is the only behavior that any decider can possibly report on.
That anyone believes that HHH is required to report on the behavior of a non-input merely proves a lack of sufficient understanding of how Turing machine deciders work.
On 7/9/2025 6:44 AM, Richard Damon wrote:
On 7/8/25 3:49 PM, olcott wrote:
On 7/8/2025 2:01 PM, Mike Terry wrote:
This is one of PO's practiced tactics - he makes a claim, and
regardless of how patently false that claim appears, he refuses to
logically defend the claim beyond saying "the claim is true, and if
you understood xxx you would realise it is true".
All of my claims are easily verified facts to those
with the capacity to verify them.
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]
Not a program, must include the code for HHH to be simulatable.
You must have dementia.
I have told you that HHH does emulate DDD
then it emulates itself emulating DDD 500 times now.
I am utterly shocked that you can't understand
that DDD emulated by HHH according to the semantics
of the x86 language cannot possibly reach past
it own machine address [0000219a].
But that DDD Can't be simulated by HHH without including the code that
you refuse to accept is part of the input.
HHH is the test program.
DDD is the program under test.
HHH is only determining whether or not DDD emulated
by HHH can reach its own emulated final halt state.
The historical (official received view) answer to
this same question is:
I have no idea. I give up. I will call it undecidable.
On 7/9/2025 3:22 AM, Mikko wrote:
On 2025-07-08 14:21:47 +0000, olcott said:
On 7/8/2025 2:44 AM, Mikko wrote:
On 2025-07-07 14:15:54 +0000, olcott said:
On 7/7/2025 3:37 AM, Mikko wrote:
On 2025-07-07 03:12:30 +0000, olcott said:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your >>>>>>>>>> premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input >>>>>>>>>> and return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that >>>>>>>> if this exact input WAS given to a correct simultor (which won't >>>>>>>> be itself, since it isn't doing the complete simulation) will
run for an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
Unless you can quote some respectable author your prohibitions are >>>>>> meaningless.
To people that never had any actual understanding and
can only parrot textbooks. They need to see this things
in other textbooks.
People who can parrot textbooks know better than people who cannot.
That you can't when you should shows that you can't even parrot
textbooks.
I just reverse-engineer what the truth actually is.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
    its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
    reach its simulated final halt state of ⟨Ĥ.qn⟩
The above does not make sense. There are one subordinate clause
and two nmain clauses but they are not linked to a sentence.
Whithout a sentence nothing is said.
The reason that I gave you a link to the whole
original proof is so that you could see how it
makes sense. Maybe the original proof doesn't
make sense to you either?
Linz tried to make two blocks of code into
English sentences. I kept them as blocks of code.
Linz embedded descriptions of these blocks within
the blocks. I moved them after each block.
On 7/9/2025 4:09 AM, Fred. Zwarts wrote:
Op 08.jul.2025 om 21:49 schreef olcott:
On 7/8/2025 2:01 PM, Mike Terry wrote:
On 08/07/2025 17:07, joes wrote:
Am Tue, 08 Jul 2025 10:08:05 -0500 schrieb olcott:
On 7/8/2025 6:13 AM, Richard Damon wrote:Ah, but your HHH does report on a *hypothetical* input that wouldn't >>>>> call the aborting simulator HHH, but instead a *different* (possibly >>>>> similar) simulator that would *not* abort.
On 7/7/25 10:38 PM, olcott wrote:
On 7/7/2025 9:18 PM, Richard Damon wrote:
On 7/7/25 7:52 PM, olcott wrote:
On 7/7/2025 5:41 PM, Richard Damon wrote:
On 7/7/25 2:38 PM, olcott wrote:
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
No decider is ever allowed to report on anything besides the >>>>>>>>>>>>>> actual behavior that its input actually specifies.It seems you don't understand those words.And there is no way for HHH to correctly simulate its >>>>>>>>>>>>>>>>> inputYou insistence that a non-terminating input be simulated >>>>>>>>>>>>>>>> until
and return an answer
non-existent completion is especially nuts because you have >>>>>>>>>>>>>>>> been told about this dozens of times.
What the F is wrong with you?
I don't say that the decider needs to simulate the input to >>>>>>>>>>>>>>> completion, but that it needs to be able to actually >>>>>>>>>>>>>>> PROVE that
if this exact input WAS given to a correct simultor (which >>>>>>>>>>>>>>> won't be itself, since it isn't doing the complete >>>>>>>>>>>>>>> simulation)
will run for an unbounded number of steps.
Wow. Can't you just answer the question? Also, "we" and "proved"? Not >>>>> being understood isn't very convincing. So how does HHH not abort?Really, so how does that code NOT aboft its simulation of DDD?"No, that code proves that HHH, as defined,How is it "Counter-Factual"?That is counter-factual and you would know this if you had >>>>>>>>>> good C++No, that code proves that HHH, as defined, always aborts its >>>>>>>>>>> simulation of DDD and returns 0,And HHH does not do that. The input specifies a halting >>>>>>>>>>>>> program,
because it includes the abort code. But HHH gives up before it >>>>>>>>>>>>> reaches that part of the specification and the final halt >>>>>>>>>>>>> state.
I have corrected you on this too many times.
You have sufficiently proven that you are dishonest or >>>>>>>>>>>> incompetent.
*This code proves that you are wrong*
https://github.com/plolcott/x86utm/blob/master/Halt7.c That you >>>>>>>>>>>> are too F-ing stupid to see this is less than no rebuttal at >>>>>>>>>>>> all.
skills.
It is YOU that is just counter-factual.
   always aborts its simulation of DDD"
That is a false statement. If you understood the code you would >>>>>>>> know
your error.
You have a reading comprehension problem.
When critique words you are strictly not allowed to change even a
single
word without being dishonest.
"No, that code proves that HHH as defined
    always aborts its simulation of DDD"
If you can't figure how how that is false we have conclusively proved >>>>>> your lack of sufficient technical competence.
This is one of PO's practiced tactics - he makes a claim, and
regardless of how patently false that claim appears, he refuses to
logically defend the claim beyond saying "the claim is true, and if
you understood xxx you would realise it is true".
All of my claims are easily verified facts to those
with the capacity to verify them.
Again changing the meaning of the words. Here 'capacity' seems to mean
the ability to ignore the facts.
This is not the full program.
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]
It need not be a full program.
All that needs to be known is that
DDD is emulated by HHH using an x86 emulator.
It refers in the call instruction to address 000015d2, which is not
shown here.
*It is shown here*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Because we have multiple levels of emulation the
instructions of each level are mixed together as
they actually occur in the execution trace.
None of these are relevant.
*The only thing that is relevant is this portion*
 machine  stack    stack    machine   assembly
 address  address  data     code      language
 ======== ======== ======== ========= ============= [00002192][00103820][00000000] 55        push ebp     ; Begin main()
[00002193][00103820][00000000] 8bec      mov ebp,esp  ; housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:1038c4
Begin Local Halt Decider Simulation  Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55        push ebp     ; housekeeping
[00002173][001138bc][001138c0] 8bec      mov ebp,esp  ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55        push ebp     ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec      mov ebp,esp  ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
 From other sources, such as Halt7.c, we know that this is the code
for a HHH that aborts and returns a value 0.
It is impossible for any HHH to return any value
to any simulated DDD. The code completely proves this.
When we use that fact, we see that a correct simulation would
The stupid mistake that everyone here makes is thinking
that their expectation of what the code should do overrides
the behavior that this code actually specifies.
DDD emulated by HHH according to the semantics of the
x86 language specifies that this DDD cannot possibly
reach its final halt state.
continue at 0000219f, using this value and reaching the final halt state.
Of course, HHH fails to do this correct simulation, as you have shown
many times.
On 7/9/2025 3:22 AM, Mikko wrote:
On 2025-07-08 14:21:47 +0000, olcott said:
On 7/8/2025 2:44 AM, Mikko wrote:
On 2025-07-07 14:15:54 +0000, olcott said:
On 7/7/2025 3:37 AM, Mikko wrote:
On 2025-07-07 03:12:30 +0000, olcott said:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and return
an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to completion,
but that it needs to be able to actually PROVE that if this exact input
WAS given to a correct simultor (which won't be itself, since it isn't >>>>>>>> doing the complete simulation) will run for an unbounded number of >>>>>>>> steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
Unless you can quote some respectable author your prohibitions are >>>>>> meaningless.
To people that never had any actual understanding and
can only parrot textbooks. They need to see this things
in other textbooks.
People who can parrot textbooks know better than people who cannot.
That you can't when you should shows that you can't even parrot
textbooks.
I just reverse-engineer what the truth actually is.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
    its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
    reach its simulated final halt state of ⟨Ĥ.qn⟩
The above does not make sense. There are one subordinate clause
and two nmain clauses but they are not linked to a sentence.
Whithout a sentence nothing is said.
The reason that I gave you a link to the whole
original proof is so that you could see how it
makes sense. Maybe the original proof doesn't
make sense to you either?
Linz tried to make two blocks of code into
English sentences.
On 7/9/2025 10:42 AM, joes wrote:Yes, that is not the mathematical function that pairs encodings of
Am Wed, 09 Jul 2025 09:06:42 -0500 schrieb olcott:
On 7/9/2025 8:37 AM, joes wrote:
Am Wed, 09 Jul 2025 08:02:16 -0500 schrieb olcott:
On 7/9/2025 3:58 AM, Fred. Zwarts wrote:
Yes it is the halting function.Yes. That is not the halting function.It is a matter of verified fact that HHH does correctly determine thatAll Turing machine deciders only compute the mapping from theirIt matters more what they map it to, i.e. which mapping they compute.
actual inputs. This entails that they never compute any mapping from >>>>> non-inputs.
HHH does not compute the halting function.
DDD correctly emulated by HHH cannot possibly reach its own emulated
final halt state.
The actual question posed to HHH is:
Does your input specify behavior that cannot reach its own final halt
state?
No, it answers the same question as HHH: does the simulation halt?I have another program here that (tautologically) determines that itThat changes the words of the question thus becomes the strawman error.
cannot simulate ANY code (according to x86 semantics) to a halting
state - by simulating zero steps :-) That tells me nothing about
whether the input halts when executed.
Since programs are not in its domain...How can your beloved Aprove even say anything about its inputs?
Or before they reach the abort.DDD emulated by HHH according to the semantics of the x86 languageThe abort could, if you hadn't botched it with static variables.How could HHH abort and not halt?None of the code in HHH can possibly help DDD correctly emulated by
HHH to reach its own emulated final halt state.
continues to emulate the first four instructions of DDD in recursive emulation until HHH aborts its emulation immediately killing every DDD
before any of them reach their own "ret" instruction.
I keep asking for your credentials because you seem to not have enough technical knowledge about ordinary programming.Doesn't sound like a degree would convince you.
I'll take that as agreement.The behavior that the input to HHH(DDD) actually specifies is the onlyYes, what a processor does - turning code into behaviour - is clearly
behavior that any decider can possibly report on.
That anyone believes that HHH is required to report on the behavior of
a non-input merely proves a lack of sufficient understanding of how
Turing machine deciders work.
uncomputable.
On 7/9/2025 3:58 AM, Fred. Zwarts wrote:
Op 08.jul.2025 om 17:17 schreef olcott:
On 7/8/2025 6:18 AM, Richard Damon wrote:As usual a false claim, without evidence.
On 7/7/25 10:52 PM, olcott wrote:
On 7/7/2025 9:24 PM, Richard Damon wrote:
On 7/7/25 7:47 PM, olcott wrote:>>
That Turing machines cannot take directly executing Turing
Machines as inputs entails that these directly executed
machines are outside of the domain of every Turing machine
based halt decider.
But they can take the finite-stringt encoding of those machines.
Yes.
I guess you idea of Turing Machine is so limited that you think
they can't do arithmatic, as you can't actually put a "Number" as
the input, only the finite-string encoding of a number, which puts >>>>>> it outside the domain of them.
No one here has any understanding of the philosophy of
computation. They can only memorize the rules and have
no idea about the reasoning behind these rules.
That you cannot understand that is a truism is only your
own lack of understanding.
But it isn't a truism, it is just a stupid lie that ignores that
almost everything done with programs is via an "encoding" for the
input.
Gross ignorance about the reasoning behind the rules
of computation would tell you that.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*Here is the Linz proof corrected to account for that*
*adapted from bottom of page 319*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
    its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly >>>>>>>     reach its simulated final halt state of ⟨Ĥ.qn⟩
Which is just an admission of your lying strawman, as the question >>>>>> is NOT about the (partial) simulation done by your H / embedded_H, >>>>>> but about the direct execution of the input H^ (H^) as that is
what the input to H is encoding.
Because no Turing machine can take a directly executed
Turing machine as an input, directly executed Turing
machines have always been outside of the domain of every
Turing machine based decider.
Then evdrything in reality is outside the domain of Turing Machines.
"the direct execution of the input H^ (H^)" has always been
out-of-scope for every Turing machine based halt decider.
That no one bothered to notice this ever before
*DOES NOT MAKE ME WRONG*
But it hasn't been, and thus you are just wrong.
An actual rebuttal requires proving that Turing machines
can take directly executing Turing machines (that are not
finite string encodings) as inputs.
But the Turing Machine that is directly executed CAN be represented
by a finite string,.
In the case of pathological self-reference the
representation has different behavior than the
directly executed machine and halt deciders only
report on the actual behavior actually specified
by their inputs.
*If you have enough knowledge then that is self evident*
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
The evidence is that the input includes the code to abort and halt,
abort and stop running
*IS NOT THE SAME THING AS*
abort and halt
On 7/9/2025 4:04 AM, Fred. Zwarts wrote:But being unreachable by Ĥ is a failure/property of Ĥ, not of the input.
Op 08.jul.2025 om 16:31 schreef olcott:
On 7/8/2025 2:55 AM, Fred. Zwarts wrote:Your are fighting windmills. Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is required to >> report on the specification of its input Ĥ.
Op 08.jul.2025 om 04:52 schreef olcott:
On 7/7/2025 9:24 PM, Richard Damon wrote:That is your misconception. No one ever asked to take the direct
On 7/7/25 7:47 PM, olcott wrote:>>
That Turing machines cannot take directly executing Turing
Machines as inputs entails that these directly executed
machines are outside of the domain of every Turing machine
based halt decider.
But they can take the finite-stringt encoding of those machines.
Yes.
I guess you idea of Turing Machine is so limited that you think
they can't do arithmatic, as you can't actually put a "Number" as
the input, only the finite-string encoding of a number, which puts >>>>>> it outside the domain of them.
No one here has any understanding of the philosophy of
computation. They can only memorize the rules and have
no idea about the reasoning behind these rules.
That you cannot understand that is a truism is only your
own lack of understanding.
But it isn't a truism, it is just a stupid lie that ignores that
almost everything done with programs is via an "encoding" for the
input.
Gross ignorance about the reasoning behind the rules
of computation would tell you that.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*Here is the Linz proof corrected to account for that*
*adapted from bottom of page 319*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
    its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly >>>>>>>     reach its simulated final halt state of ⟨Ĥ.qn⟩
Which is just an admission of your lying strawman, as the question >>>>>> is NOT about the (partial) simulation done by your H / embedded_H, >>>>>> but about the direct execution of the input H^ (H^) as that is
what the input to H is encoding.
Because no Turing machine can take a directly executed
Turing machine as an input, directly executed Turing
machines have always been outside of the domain of every
Turing machine based decider.
"the direct execution of the input H^ (H^)" has always been
out-of-scope for every Turing machine based halt decider.
That no one bothered to notice this ever before
*DOES NOT MAKE ME WRONG*
execution as input.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
  if Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
  if Ĥ applied to ⟨Ĥ⟩ does not halt
*The above original form of the proof*
does requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ to report on
the direct execution of Ĥ applied to ⟨Ĥ⟩ and thus
not ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H.
Very close.
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is required to report
on the behavior that its input specifies.
This Ĥ includes the code that make it halt,
More precisely This Ĥ includes one final halt state: Ĥ.qn
That is unreachable when ⟨Ĥ⟩ ⟨Ĥ⟩ is correctly simulated by Ĥ.embedded_H.
On 7/9/2025 4:09 AM, Fred. Zwarts wrote:
Op 08.jul.2025 om 21:49 schreef olcott:
On 7/8/2025 2:01 PM, Mike Terry wrote:
On 08/07/2025 17:07, joes wrote:
Am Tue, 08 Jul 2025 10:08:05 -0500 schrieb olcott:
On 7/8/2025 6:13 AM, Richard Damon wrote:Ah, but your HHH does report on a *hypothetical* input that wouldn't >>>>> call the aborting simulator HHH, but instead a *different* (possibly >>>>> similar) simulator that would *not* abort.
On 7/7/25 10:38 PM, olcott wrote:
On 7/7/2025 9:18 PM, Richard Damon wrote:
On 7/7/25 7:52 PM, olcott wrote:
On 7/7/2025 5:41 PM, Richard Damon wrote:
On 7/7/25 2:38 PM, olcott wrote:
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
No decider is ever allowed to report on anything besides the >>>>>>>>>>>>>> actual behavior that its input actually specifies.It seems you don't understand those words.And there is no way for HHH to correctly simulate its >>>>>>>>>>>>>>>>> inputYou insistence that a non-terminating input be simulated >>>>>>>>>>>>>>>> until
and return an answer
non-existent completion is especially nuts because you have >>>>>>>>>>>>>>>> been told about this dozens of times.
What the F is wrong with you?
I don't say that the decider needs to simulate the input to >>>>>>>>>>>>>>> completion, but that it needs to be able to actually >>>>>>>>>>>>>>> PROVE that
if this exact input WAS given to a correct simultor (which >>>>>>>>>>>>>>> won't be itself, since it isn't doing the complete >>>>>>>>>>>>>>> simulation)
will run for an unbounded number of steps.
Wow. Can't you just answer the question? Also, "we" and "proved"? Not >>>>> being understood isn't very convincing. So how does HHH not abort?Really, so how does that code NOT aboft its simulation of DDD?"No, that code proves that HHH, as defined,How is it "Counter-Factual"?That is counter-factual and you would know this if you had >>>>>>>>>> good C++No, that code proves that HHH, as defined, always aborts its >>>>>>>>>>> simulation of DDD and returns 0,And HHH does not do that. The input specifies a halting >>>>>>>>>>>>> program,
because it includes the abort code. But HHH gives up before it >>>>>>>>>>>>> reaches that part of the specification and the final halt >>>>>>>>>>>>> state.
I have corrected you on this too many times.
You have sufficiently proven that you are dishonest or >>>>>>>>>>>> incompetent.
*This code proves that you are wrong*
https://github.com/plolcott/x86utm/blob/master/Halt7.c That you >>>>>>>>>>>> are too F-ing stupid to see this is less than no rebuttal at >>>>>>>>>>>> all.
skills.
It is YOU that is just counter-factual.
   always aborts its simulation of DDD"
That is a false statement. If you understood the code you would >>>>>>>> know
your error.
You have a reading comprehension problem.
When critique words you are strictly not allowed to change even a
single
word without being dishonest.
"No, that code proves that HHH as defined
    always aborts its simulation of DDD"
If you can't figure how how that is false we have conclusively proved >>>>>> your lack of sufficient technical competence.
This is one of PO's practiced tactics - he makes a claim, and
regardless of how patently false that claim appears, he refuses to
logically defend the claim beyond saying "the claim is true, and if
you understood xxx you would realise it is true".
All of my claims are easily verified facts to those
with the capacity to verify them.
Again changing the meaning of the words. Here 'capacity' seems to mean
the ability to ignore the facts.
This is not the full program.
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]
It need not be a full program.
All that needs to be known is that
DDD is emulated by HHH using an x86 emulator.
It refers in the call instruction to address 000015d2, which is not
shown here.
*It is shown here*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Because we have multiple levels of emulation the
instructions of each level are mixed together as
they actually occur in the execution trace.
None of these are relevant.
*The only thing that is relevant is this portion*
 machine  stack    stack    machine   assembly
 address  address  data     code      language
 ======== ======== ======== ========= ============= [00002192][00103820][00000000] 55        push ebp     ; Begin main()
[00002193][00103820][00000000] 8bec      mov ebp,esp  ; housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:1038c4
Begin Local Halt Decider Simulation  Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55        push ebp     ; housekeeping
[00002173][001138bc][001138c0] 8bec      mov ebp,esp  ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55        push ebp     ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec      mov ebp,esp  ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
 From other sources, such as Halt7.c, we know that this is the code
for a HHH that aborts and returns a value 0.
It is impossible for any HHH to return any value
to any simulated DDD. The code completely proves this.
When we use that fact, we see that a correct simulation would
The stupid mistake that everyone here makes is thinking
that their expectation of what the code should do overrides
the behavior that this code actually specifies.
DDD emulated by HHH according to the semantics of the
x86 language specifies that this DDD cannot possibly
reach its final halt state.
continue at 0000219f, using this value and reaching the final halt state.
Of course, HHH fails to do this correct simulation, as you have shown
many times.
On 7/9/2025 4:58 AM, Fred. Zwarts wrote:
Op 08.jul.2025 om 16:59 schreef olcott:
On 7/8/2025 3:10 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 15:23 schreef olcott:
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:And HHH does not do that. The input specifies a halting program,
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your >>>>>>>>>> premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input >>>>>>>>>> and return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that >>>>>>>> if this exact input WAS given to a correct simultor (which won't >>>>>>>> be itself, since it isn't doing the complete simulation) will
run for an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
because it includes the abort code.
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]
That does have an effect on DDD emulated by HHH according
to the semantics of the x86 language stopping running.
It has no effect on this DDD every reaching its final halt
state. I have corrected your error on this too many times
you don't seem to want an honest dialogue.
As usual repeated claims without evidence.
100% *complete proof is provided above*
That you don't have sufficient technical
skill to see that this is complete proof
is not my mistake.
You fail to see that it is not a 100% proof. It is incomplete. The
code has a call to 000015d2 , but you do not show the code there. we know
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Shows all of the details. X86UTM is a multi-tasking
operating system, When the emulator instructions are
shown they are mixed in with the emulated instructions.
This makes unraveling the details too difficult.
All that need be known is that "call 000015d2"
calls HHH that emulates its input until it detects
a non halting behavior pattern. All of the chat bots
figured out exactly what this pattern is on their own.
that this code is the HHH that aborts and halts, so a correct
simulation will then reach 0000219f and then reach the final halt state.
when you define "correct" as violating the semantics
of the x86 language then you would be "correct".
This might also seem true when you define halting
as stopping running for any reason what-so-ever
and not requiring reaching a final halt state.
We also know that HHH fails to reach that final halt state, because of
a premature abort. A proof with so many errors, is far from 100%.
You can close your eyes for these errors and pretend that they do not
exists, but that would be childish.
It is a pity that you ignore or do not understand the corrections
that have been pointed out to you. Not understanding something is
not stupid, but resistance against learning from errors is.
DDD correctly simulated by HHH calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
Using falsehoods to prove your case is not convincing. We know that
HHH aborts before 6 cycles have been simulated.
That you cannot see that this is the behavior
that the input to HHH(DDD) specifies is your
own lack of technical skill.
That you do not even understand your own code, where HHH aborts after
a few cycles, does not change the fact that the real behaviour
specified is a halting program. But as usual, you and HHH close your
eyes and pretend that what you do not see does not exist.
*Maybe it is time to reveal credentials*
I have taken all but one of the courses
for a computer science degree and been a
C++ software engineer for two decades.
Mensa scored my IQ is in the top 3%.
We have pointed out already many times that this cannot be the whole
input. At 0000219a there is a call to 000015d2 , but the code at
000015d2 is not specified.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Because of the required cooperative multi-tasking
it is a little too difficult to see which the
actual trace.
Even that trace proves that HHH aborts before it can see the full
behaviour specified in the input. Then it closes it eyes and pretends
that what it does not see does not exist.
We have to take it from another source, your Halt7.c. There we see
that HHH is a function that returns with a value 0 with this input.
So, a correct simulation will then continue at 0000219f
DDD simulated by HHH according to the semantics of the x86
language cannot possibly ever get there even of your lack
of sufficient technical skill tells you so.
*Feel free to dig through this full trace and see*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
with this value and even a beginner sees that the simulation will
then reach a natural end.
*DDD simulated by HHH NEVER REACHES ITS FINAL HALT STATE*
DDD correctly simulated by HHH calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
Again the same falsehood. HHH aborts way before simulating 6 cycles.
Using falsehoods to prove your case does not make your case any stronger.
This is the full specification of the input.
This is also proven when exactly the same input is used in direct
execution, or by world-class simulators, even by HHH1.
So, the following still holds:
If HHH does not see the full specification, it does not change the
But HHH gives up before it reaches that part of the specification
and the final halt state.
specification. It only illustrates the failure of the simulation to
complete.
There is nothing wrong with aborting a simulation, because it is
known that simulation is not always the correct tool to determine
halting/ non- halting behaviour. In such cases other tools are
needed to determine halting/non-halting behaviour.
On 7/9/2025 8:49 PM, Richard Damon wrote:
On 7/9/25 9:55 AM, olcott wrote:
On 7/9/2025 6:44 AM, Richard Damon wrote:
On 7/8/25 3:49 PM, olcott wrote:
On 7/8/2025 2:01 PM, Mike Terry wrote:
This is one of PO's practiced tactics - he makes a claim, and
regardless of how patently false that claim appears, he refuses to >>>>>> logically defend the claim beyond saying "the claim is true, and
if you understood xxx you would realise it is true".
All of my claims are easily verified facts to those
with the capacity to verify them.
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]
Not a program, must include the code for HHH to be simulatable.
You must have dementia.
I have told you that HHH does emulate DDD
then it emulates itself emulating DDD 500 times now.
And thus you admit that you are lying.
*Here is the proof*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On 7/9/2025 4:04 AM, Fred. Zwarts wrote:
Op 08.jul.2025 om 16:31 schreef olcott:
On 7/8/2025 2:55 AM, Fred. Zwarts wrote:Your are fighting windmills. Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is required to >> report on the specification of its input Ĥ.
Op 08.jul.2025 om 04:52 schreef olcott:
On 7/7/2025 9:24 PM, Richard Damon wrote:That is your misconception. No one ever asked to take the direct
On 7/7/25 7:47 PM, olcott wrote:>>
That Turing machines cannot take directly executing Turing
Machines as inputs entails that these directly executed
machines are outside of the domain of every Turing machine
based halt decider.
But they can take the finite-stringt encoding of those machines.
Yes.
I guess you idea of Turing Machine is so limited that you think
they can't do arithmatic, as you can't actually put a "Number" as
the input, only the finite-string encoding of a number, which puts >>>>>> it outside the domain of them.
No one here has any understanding of the philosophy of
computation. They can only memorize the rules and have
no idea about the reasoning behind these rules.
That you cannot understand that is a truism is only your
own lack of understanding.
But it isn't a truism, it is just a stupid lie that ignores that
almost everything done with programs is via an "encoding" for the
input.
Gross ignorance about the reasoning behind the rules
of computation would tell you that.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*Here is the Linz proof corrected to account for that*
*adapted from bottom of page 319*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
    its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly >>>>>>>     reach its simulated final halt state of ⟨Ĥ.qn⟩
Which is just an admission of your lying strawman, as the question >>>>>> is NOT about the (partial) simulation done by your H / embedded_H, >>>>>> but about the direct execution of the input H^ (H^) as that is
what the input to H is encoding.
Because no Turing machine can take a directly executed
Turing machine as an input, directly executed Turing
machines have always been outside of the domain of every
Turing machine based decider.
"the direct execution of the input H^ (H^)" has always been
out-of-scope for every Turing machine based halt decider.
That no one bothered to notice this ever before
*DOES NOT MAKE ME WRONG*
execution as input.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
  if Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
  if Ĥ applied to ⟨Ĥ⟩ does not halt
*The above original form of the proof*
does requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ to report on
the direct execution of Ĥ applied to ⟨Ĥ⟩ and thus
not ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H.
Very close.
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is required to report
on the behavior that its input specifies.
This Ĥ includes the code that make it halt,
More precisely This Ĥ includes one final halt state: Ĥ.qn
That is unreachable when ⟨Ĥ⟩ ⟨Ĥ⟩ is correctly simulated by Ĥ.embedded_H.
so the specification is a halting program.
False conclusion from false premise.
 Nowhere there is the requirement that it must report on the direct
execution.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
 if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 if Ĥ applied to ⟨Ĥ⟩ does not halt.
if Ĥ applied to ⟨Ĥ⟩ halts // is the requirement
// that it report in the direct execution.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
When M is applied to WM
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
  if M applied to WM halts, and
q0 WM ⊢* Ĥq0 Wm WM ⊢* Ĥ y1 qn y2,
  if M applied to WM does not halt.
The above is the original textbook quote.
Direct execution is only one way to prove what is specified in the
input, but often there are other methods to prove it. Ĥ does not need
to know it, it show only report what is specified.
I agree with you and everyone else seems to disagree with you.
If it fails to report that a halting program halts, it is just wrong.
The input specifies recursive simulation that
never halts even though the program halts.
This can best be seen at the x86 machine code level.
If you have no understanding of the x86 language you
won't be able to see this.
On 7/9/2025 4:58 AM, Fred. Zwarts wrote:
Op 08.jul.2025 om 16:59 schreef olcott:
On 7/8/2025 3:10 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 15:23 schreef olcott:
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:And HHH does not do that. The input specifies a halting program,
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your >>>>>>>>>> premise.
There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input >>>>>>>>>> and return an answer
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that >>>>>>>> if this exact input WAS given to a correct simultor (which won't >>>>>>>> be itself, since it isn't doing the complete simulation) will
run for an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
because it includes the abort code.
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]
That does have an effect on DDD emulated by HHH according
to the semantics of the x86 language stopping running.
It has no effect on this DDD every reaching its final halt
state. I have corrected your error on this too many times
you don't seem to want an honest dialogue.
As usual repeated claims without evidence.
100% *complete proof is provided above*
That you don't have sufficient technical
skill to see that this is complete proof
is not my mistake.
You fail to see that it is not a 100% proof. It is incomplete. The
code has a call to 000015d2 , but you do not show the code there. we know
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Shows all of the details. X86UTM is a multi-tasking
operating system, When the emulator instructions are
shown they are mixed in with the emulated instructions.
This makes unraveling the details too difficult.
All that need be known is that "call 000015d2"
calls HHH that emulates its input until it detects
a non halting behavior pattern. All of the chat bots
figured out exactly what this pattern is on their own.
that this code is the HHH that aborts and halts, so a correct
simulation will then reach 0000219f and then reach the final halt state.
when you define "correct" as violating the semantics
of the x86 language then you would be "correct".
This might also seem true when you define halting
as stopping running for any reason what-so-ever
and not requiring reaching a final halt state.
We also know that HHH fails to reach that final halt state, because of
a premature abort. A proof with so many errors, is far from 100%.
You can close your eyes for these errors and pretend that they do not
exists, but that would be childish.
It is a pity that you ignore or do not understand the corrections
that have been pointed out to you. Not understanding something is
not stupid, but resistance against learning from errors is.
DDD correctly simulated by HHH calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
Using falsehoods to prove your case is not convincing. We know that
HHH aborts before 6 cycles have been simulated.
That you cannot see that this is the behavior
that the input to HHH(DDD) specifies is your
own lack of technical skill.
That you do not even understand your own code, where HHH aborts after
a few cycles, does not change the fact that the real behaviour
specified is a halting program. But as usual, you and HHH close your
eyes and pretend that what you do not see does not exist.
*Maybe it is time to reveal credentials*
I have taken all but one of the courses
for a computer science degree and been a
C++ software engineer for two decades.
Mensa scored my IQ is in the top 3%.
We have pointed out already many times that this cannot be the whole
input. At 0000219a there is a call to 000015d2 , but the code at
000015d2 is not specified.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Because of the required cooperative multi-tasking
it is a little too difficult to see which the
actual trace.
Even that trace proves that HHH aborts before it can see the full
behaviour specified in the input. Then it closes it eyes and pretends
that what it does not see does not exist.
We have to take it from another source, your Halt7.c. There we see
that HHH is a function that returns with a value 0 with this input.
So, a correct simulation will then continue at 0000219f
DDD simulated by HHH according to the semantics of the x86
language cannot possibly ever get there even of your lack
of sufficient technical skill tells you so.
*Feel free to dig through this full trace and see*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
with this value and even a beginner sees that the simulation will
then reach a natural end.
*DDD simulated by HHH NEVER REACHES ITS FINAL HALT STATE*
DDD correctly simulated by HHH calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
Again the same falsehood. HHH aborts way before simulating 6 cycles.
Using falsehoods to prove your case does not make your case any stronger.
This is the full specification of the input.
This is also proven when exactly the same input is used in direct
execution, or by world-class simulators, even by HHH1.
So, the following still holds:
If HHH does not see the full specification, it does not change the
But HHH gives up before it reaches that part of the specification
and the final halt state.
specification. It only illustrates the failure of the simulation to
complete.
There is nothing wrong with aborting a simulation, because it is
known that simulation is not always the correct tool to determine
halting/ non- halting behaviour. In such cases other tools are
needed to determine halting/non-halting behaviour.
On 7/10/2025 6:35 AM, Richard Damon wrote:
On 7/9/25 10:50 PM, olcott wrote:
On 7/9/2025 8:49 PM, Richard Damon wrote:
On 7/9/25 9:55 AM, olcott wrote:
On 7/9/2025 6:44 AM, Richard Damon wrote:
On 7/8/25 3:49 PM, olcott wrote:
On 7/8/2025 2:01 PM, Mike Terry wrote:
This is one of PO's practiced tactics - he makes a claim, and
regardless of how patently false that claim appears, he refuses >>>>>>>> to logically defend the claim beyond saying "the claim is true, >>>>>>>> and if you understood xxx you would realise it is true".
All of my claims are easily verified facts to those
with the capacity to verify them.
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]
Not a program, must include the code for HHH to be simulatable.
You must have dementia.
I have told you that HHH does emulate DDD
then it emulates itself emulating DDD 500 times now.
And thus you admit that you are lying.
*Here is the proof*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
SO, you admit that HHH fails to emulate JUST the input,
*I have told you that HHH does emulate DDD*
*then it emulates itself emulating DDD 500 times now*
*NOW I PROVED THAT*
*See if you can remember this by your next reply*
On 7/10/2025 7:04 PM, Richard Damon wrote:
On 7/10/25 9:24 AM, olcott wrote:
On 7/10/2025 6:35 AM, Richard Damon wrote:
On 7/9/25 10:50 PM, olcott wrote:
On 7/9/2025 8:49 PM, Richard Damon wrote:
On 7/9/25 9:55 AM, olcott wrote:
On 7/9/2025 6:44 AM, Richard Damon wrote:
On 7/8/25 3:49 PM, olcott wrote:
On 7/8/2025 2:01 PM, Mike Terry wrote:
This is one of PO's practiced tactics - he makes a claim, and >>>>>>>>>> regardless of how patently false that claim appears, he
refuses to logically defend the claim beyond saying "the claim >>>>>>>>>> is true, and if you understood xxx you would realise it is true". >>>>>>>>>>
All of my claims are easily verified facts to those
with the capacity to verify them.
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]
Not a program, must include the code for HHH to be simulatable. >>>>>>>>
You must have dementia.
I have told you that HHH does emulate DDD
then it emulates itself emulating DDD 500 times now.
And thus you admit that you are lying.
*Here is the proof*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
SO, you admit that HHH fails to emulate JUST the input,
*I have told you that HHH does emulate DDD*
*then it emulates itself emulating DDD 500 times now*
And the question is HOW can it?
You claim it isn't part of the input, and thus it isn't AVAILABLE for
HHH to emualate.
You don't seem to understand that HHH isn't ALLOWED to look at memory
that isn't part of its input, without MAKING that memory part of its
input.
*NOW I PROVED THAT*
*See if you can remember this by your next reply*
No, you are just proving that you don't understand how programs and
input are defined, and thus make yourself into a liar.
*I just proved the fact that*
(1) HHH(DDD) is executed
(2) HHH emulates DDD
(3) emulated DDD calls an emulated HHH(DDD)
(4) emulated HHH emulates another instance of DDD
(5) this DDD calls HHH(DDD) again https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Its OK if you are no good with the x86 language
and can't understand the code. I began programming
way back when x86 programming was popular.
Alternatively the details of how multi-tasking
works are too difficult for you. They are probably
too difficult for most programmers.
On 7/10/2025 4:30 AM, Mikko wrote:
On 2025-07-09 12:25:59 +0000, olcott said:
On 7/9/2025 3:22 AM, Mikko wrote:
On 2025-07-08 14:21:47 +0000, olcott said:
On 7/8/2025 2:44 AM, Mikko wrote:
On 2025-07-07 14:15:54 +0000, olcott said:
On 7/7/2025 3:37 AM, Mikko wrote:
On 2025-07-07 03:12:30 +0000, olcott said:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your premise.
There is no way that DDD simulated by HHH (according >>>>>>>>>>>>> to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and return
an answer
You insistence that a non-terminating input be simulated >>>>>>>>>>> until non-existent completion is especially nuts because >>>>>>>>>>> you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to completion,
but that it needs to be able to actually PROVE that if this exact input
WAS given to a correct simultor (which won't be itself, since it isn't
doing the complete simulation) will run for an unbounded number of >>>>>>>>>> steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
Unless you can quote some respectable author your prohibitions are >>>>>>>> meaningless.
To people that never had any actual understanding and
can only parrot textbooks. They need to see this things
in other textbooks.
People who can parrot textbooks know better than people who cannot. >>>>>> That you can't when you should shows that you can't even parrot
textbooks.
I just reverse-engineer what the truth actually is.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
    its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly >>>>>     reach its simulated final halt state of ⟨Ĥ.qn⟩
The above does not make sense. There are one subordinate clause
and two nmain clauses but they are not linked to a sentence.
Whithout a sentence nothing is said.
The reason that I gave you a link to the whole
original proof is so that you could see how it
makes sense. Maybe the original proof doesn't
make sense to you either?
I'm not talking about any proof, I'm talking about your words and
symbols quored above. What is written in the book does make sense.
In particular, clauses are meaningfully linked to sentences.
Perhaps the presentation could be clearer but it is intended for
students that already know and understand the earlier parts of the
book.
Linz tried to make two blocks of code into
English sentences.
The "blocks of code" are main clauses. They use abrevations because those
are easier to read than a full natural language sentence. There are other
clauses so that all clauses together form a sentence. In particuralr, ther >> is an "and" between them. The sentence is not a truth bearer. Instead it
expresses a desire.
If you want to say something you should learn to construct meaningful
sentences.
That you cannot understand what I say
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
 *if Ĥ applied to ⟨Ĥ⟩ halts, and*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 *if Ĥ applied to ⟨Ĥ⟩ does not halt*
*It is common knowledge in the theory of computation*
The evidence is that the input includes the code to abort and halt,
abort and stop running
*IS NOT THE SAME THING AS*
abort and halt
Another claim without evidence.
On 7/10/2025 9:10 PM, Richard Damon wrote:
On 7/10/25 8:27 PM, olcott wrote:
On 7/10/2025 7:04 PM, Richard Damon wrote:
On 7/10/25 9:24 AM, olcott wrote:
On 7/10/2025 6:35 AM, Richard Damon wrote:
On 7/9/25 10:50 PM, olcott wrote:
On 7/9/2025 8:49 PM, Richard Damon wrote:
On 7/9/25 9:55 AM, olcott wrote:
On 7/9/2025 6:44 AM, Richard Damon wrote:
On 7/8/25 3:49 PM, olcott wrote:
On 7/8/2025 2:01 PM, Mike Terry wrote:
This is one of PO's practiced tactics - he makes a claim, >>>>>>>>>>>> and regardless of how patently false that claim appears, he >>>>>>>>>>>> refuses to logically defend the claim beyond saying "the >>>>>>>>>>>> claim is true, and if you understood xxx you would realise >>>>>>>>>>>> it is true".
All of my claims are easily verified facts to those
with the capacity to verify them.
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]
Not a program, must include the code for HHH to be simulatable. >>>>>>>>>>
You must have dementia.
I have told you that HHH does emulate DDD
then it emulates itself emulating DDD 500 times now.
And thus you admit that you are lying.
*Here is the proof*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
SO, you admit that HHH fails to emulate JUST the input,
*I have told you that HHH does emulate DDD*
*then it emulates itself emulating DDD 500 times now*
And the question is HOW can it?
You claim it isn't part of the input, and thus it isn't AVAILABLE
for HHH to emualate.
You don't seem to understand that HHH isn't ALLOWED to look at
memory that isn't part of its input, without MAKING that memory part
of its input.
*NOW I PROVED THAT*
*See if you can remember this by your next reply*
No, you are just proving that you don't understand how programs and
input are defined, and thus make yourself into a liar.
*I just proved the fact that*
(1) HHH(DDD) is executed
(2) HHH emulates DDD
(3) emulated DDD calls an emulated HHH(DDD)
(4) emulated HHH emulates another instance of DDD
(5) this DDD calls HHH(DDD) again
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Its OK if you are no good with the x86 language
and can't understand the code. I began programming
way back when x86 programming was popular.
Alternatively the details of how multi-tasking
works are too difficult for you. They are probably
too difficult for most programmers.
And thus you have proven my point that either you definition of what
the input is, or what HHH does is just a lie.
But, it seems you are too stupid to understand that problem.
Your claims are:
1) The input contains only the code shown, and thus does not contain
the code of HHH.
2) That HHH is simulating the input given to it, and thus JUST that
input.
3) That HHH simulates the code of HHH.
The test program HHH is not the program under test DDD.
The program under test and the test program will never
stop running unless HHH aborts its DDD.
On 7/10/2025 6:08 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:35 schreef olcott:
On 7/9/2025 4:09 AM, Fred. Zwarts wrote:
Op 08.jul.2025 om 21:49 schreef olcott:
*It is shown here*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Because we have multiple levels of emulation the
instructions of each level are mixed together as
they actually occur in the execution trace.
So, why don't you include the code? Apparently belongs to the input.
If not, why would HHH produce a trace of a non-input?
The test program HHH was encoded to halt.
The program under test DDD specifies non-halting behavior.
None of these are relevant.
*The only thing that is relevant is this portion*
  machine  stack    stack    machine   assembly
  address  address  data     code      language
  ======== ======== ======== ========= =============
[00002192][00103820][00000000] 55        push ebp     ; Begin main()
[00002193][00103820][00000000] 8bec      mov ebp,esp  ; housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:1038c4
Begin Local Halt Decider Simulation  Execution Trace Stored at:1138cc >>> [00002172][001138bc][001138c0] 55        push ebp     ; housekeeping
[00002173][001138bc][001138c0] 8bec      mov ebp,esp  ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55        push ebp     ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec      mov ebp,esp  ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Indeed, it is relevant to show that HHH aborts with the invalid reason
'Infinite Recursion Detected'. There is no Infinite Recursion, there
is only a finite recursion. One cycle later the simulation would reach
a natural end.
Neither HHH nor DDD would ever stop running unless HHH
aborts its simulation. The leading author of theory
of computation textbooks agreed that this is non-halting behavior.
On 7/10/2025 6:17 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:46 schreef olcott:
On 7/9/2025 4:58 AM, Fred. Zwarts wrote:
Op 08.jul.2025 om 16:59 schreef olcott:
On 7/8/2025 3:10 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 15:23 schreef olcott:
On 7/7/2025 2:36 AM, Fred. Zwarts wrote:
Op 07.jul.2025 om 05:12 schreef olcott:
On 7/6/2025 9:09 PM, Richard Damon wrote:And HHH does not do that. The input specifies a halting program, >>>>>>>> because it includes the abort code.
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in >>>>>>>>>>>> your premise.
There is no way that DDD simulated by HHH (according >>>>>>>>>>>>> to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input >>>>>>>>>>>> and return an answer
You insistence that a non-terminating input be simulated >>>>>>>>>>> until non-existent completion is especially nuts because >>>>>>>>>>> you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to >>>>>>>>>> completion, but that it needs to be able to actually PROVE >>>>>>>>>> that if this exact input WAS given to a correct simultor
(which won't be itself, since it isn't doing the complete
simulation) will run for an unbounded number of steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
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]
That does have an effect on DDD emulated by HHH according
to the semantics of the x86 language stopping running.
It has no effect on this DDD every reaching its final halt
state. I have corrected your error on this too many times
you don't seem to want an honest dialogue.
As usual repeated claims without evidence.
100% *complete proof is provided above*
That you don't have sufficient technical
skill to see that this is complete proof
is not my mistake.
You fail to see that it is not a 100% proof. It is incomplete. The
code has a call to 000015d2 , but you do not show the code there. we
know
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Shows all of the details. X86UTM is a multi-tasking
operating system, When the emulator instructions are
shown they are mixed in with the emulated instructions.
This makes unraveling the details too difficult.
All that need be known is that "call 000015d2"
calls HHH that emulates its input until it detects
a non halting behavior pattern. All of the chat bots
figured out exactly what this pattern is on their own.
So, why don't you show the full input?
I just did show the whole 197 page execution trace. https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
This includes the x86 code for HHH and everything that it calls.
On 7/10/2025 9:10 PM, Richard Damon wrote:
On 7/10/25 8:27 PM, olcott wrote:
On 7/10/2025 7:04 PM, Richard Damon wrote:
On 7/10/25 9:24 AM, olcott wrote:
On 7/10/2025 6:35 AM, Richard Damon wrote:
On 7/9/25 10:50 PM, olcott wrote:
On 7/9/2025 8:49 PM, Richard Damon wrote:
On 7/9/25 9:55 AM, olcott wrote:
On 7/9/2025 6:44 AM, Richard Damon wrote:
On 7/8/25 3:49 PM, olcott wrote:
On 7/8/2025 2:01 PM, Mike Terry wrote:
This is one of PO's practiced tactics - he makes a claim, >>>>>>>>>>>> and regardless of how patently false that claim appears, he >>>>>>>>>>>> refuses to logically defend the claim beyond saying "the >>>>>>>>>>>> claim is true, and if you understood xxx you would realise >>>>>>>>>>>> it is true".
All of my claims are easily verified facts to those
with the capacity to verify them.
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]
Not a program, must include the code for HHH to be simulatable. >>>>>>>>>>
You must have dementia.
I have told you that HHH does emulate DDD
then it emulates itself emulating DDD 500 times now.
And thus you admit that you are lying.
*Here is the proof*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
SO, you admit that HHH fails to emulate JUST the input,
*I have told you that HHH does emulate DDD*
*then it emulates itself emulating DDD 500 times now*
And the question is HOW can it?
You claim it isn't part of the input, and thus it isn't AVAILABLE
for HHH to emualate.
You don't seem to understand that HHH isn't ALLOWED to look at
memory that isn't part of its input, without MAKING that memory part
of its input.
*NOW I PROVED THAT*
*See if you can remember this by your next reply*
No, you are just proving that you don't understand how programs and
input are defined, and thus make yourself into a liar.
*I just proved the fact that*
(1) HHH(DDD) is executed
(2) HHH emulates DDD
(3) emulated DDD calls an emulated HHH(DDD)
(4) emulated HHH emulates another instance of DDD
(5) this DDD calls HHH(DDD) again
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Its OK if you are no good with the x86 language
and can't understand the code. I began programming
way back when x86 programming was popular.
Alternatively the details of how multi-tasking
works are too difficult for you. They are probably
too difficult for most programmers.
And thus you have proven my point that either you definition of what
the input is, or what HHH does is just a lie.
But, it seems you are too stupid to understand that problem.
Your claims are:
1) The input contains only the code shown, and thus does not contain
the code of HHH.
2) That HHH is simulating the input given to it, and thus JUST that
input.
3) That HHH simulates the code of HHH.
The test program HHH is not the program under test DDD.
The program under test and the test program will never
stop running unless HHH aborts its DDD.
On 7/11/2025 3:55 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 04:33 schreef olcott:
On 7/10/2025 9:10 PM, Richard Damon wrote:
On 7/10/25 8:27 PM, olcott wrote:
*I just proved the fact that*
(1) HHH(DDD) is executed
(2) HHH emulates DDD
(3) emulated DDD calls an emulated HHH(DDD)
(4) emulated HHH emulates another instance of DDD
(5) this DDD calls HHH(DDD) again
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Its OK if you are no good with the x86 language
and can't understand the code. I began programming
way back when x86 programming was popular.
Alternatively the details of how multi-tasking
works are too difficult for you. They are probably
too difficult for most programmers.
And thus you have proven my point that either you definition of what
the input is, or what HHH does is just a lie.
But, it seems you are too stupid to understand that problem.
Your claims are:
1) The input contains only the code shown, and thus does not contain
the code of HHH.
2) That HHH is simulating the input given to it, and thus JUST that
input.
3) That HHH simulates the code of HHH.
The test program HHH is not the program under test DDD.
The program under test and the test program will never
stop running unless HHH aborts its DDD.
Another vague claim without evidence.
It not vague at all. You just don't know what
the words mean.
If DDD is under test, then also all function called by DDD are under
test, including HHH.
Since neither HHH nor DDD will ever stop running
unless HHH aborts its DDD, non-halting criteria
has been met.
You are confusing yourself with the construct where the program under
test is in the same memory as the program being tested. It would be
much easier to understand for you to keep the input for HHH separated
from HHH, by using a copy of HHH in the input.
To divide the analysis of the program under test
from the test program we only see if DDD simulated
by HHH can reach its own simulated final halt state.
On 7/11/2025 9:31 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 16:27 schreef olcott:Strawman error.
On 7/11/2025 3:55 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 04:33 schreef olcott:
On 7/10/2025 9:10 PM, Richard Damon wrote:
On 7/10/25 8:27 PM, olcott wrote:
*I just proved the fact that*
(1) HHH(DDD) is executed
(2) HHH emulates DDD
(3) emulated DDD calls an emulated HHH(DDD)
(4) emulated HHH emulates another instance of DDD
(5) this DDD calls HHH(DDD) again
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Its OK if you are no good with the x86 language
and can't understand the code. I began programming
way back when x86 programming was popular.
Alternatively the details of how multi-tasking
works are too difficult for you. They are probably
too difficult for most programmers.
And thus you have proven my point that either you definition of
what the input is, or what HHH does is just a lie.
But, it seems you are too stupid to understand that problem.
Your claims are:
1) The input contains only the code shown, and thus does not
contain the code of HHH.
2) That HHH is simulating the input given to it, and thus JUST
that input.
3) That HHH simulates the code of HHH.
The test program HHH is not the program under test DDD.
The program under test and the test program will never
stop running unless HHH aborts its DDD.
Another vague claim without evidence.
It not vague at all. You just don't know what
the words mean.
If DDD is under test, then also all function called by DDD are under
test, including HHH.
Since neither HHH nor DDD will ever stop running
unless HHH aborts its DDD, non-halting criteria
has been met.
Since HHH halts, DDD halts, too.
DDD simulated by HHH specifies non-halting behavior.
Directly executing Turing machines have always been
outside of the domain of every Turing machine decider.
HHH(DDD) is ONLY required to report on the behavior
that its input specifies.
On 7/11/2025 3:55 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 04:33 schreef olcott:
On 7/10/2025 9:10 PM, Richard Damon wrote:
On 7/10/25 8:27 PM, olcott wrote:
*I just proved the fact that*
(1) HHH(DDD) is executed
(2) HHH emulates DDD
(3) emulated DDD calls an emulated HHH(DDD)
(4) emulated HHH emulates another instance of DDD
(5) this DDD calls HHH(DDD) again
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Its OK if you are no good with the x86 language
and can't understand the code. I began programming
way back when x86 programming was popular.
Alternatively the details of how multi-tasking
works are too difficult for you. They are probably
too difficult for most programmers.
And thus you have proven my point that either you definition of what
the input is, or what HHH does is just a lie.
But, it seems you are too stupid to understand that problem.
Your claims are:
1) The input contains only the code shown, and thus does not contain
the code of HHH.
2) That HHH is simulating the input given to it, and thus JUST that
input.
3) That HHH simulates the code of HHH.
The test program HHH is not the program under test DDD.
The program under test and the test program will never
stop running unless HHH aborts its DDD.
Another vague claim without evidence.
It not vague at all. You just don't know what
the words mean.
If DDD is under test, then also all function called by DDD are under
test, including HHH.
Since neither HHH nor DDD will ever stop running
unless HHH aborts its DDD, non-halting criteria
has been met.
You are confusing yourself with the construct where the program under
test is in the same memory as the program being tested. It would be
much easier to understand for you to keep the input for HHH separated
from HHH, by using a copy of HHH in the input.
To divide the analysis of the program under test
from the test program we only see if DDD simulated
by HHH can reach its own simulated final halt state.
On 7/11/2025 9:31 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 16:27 schreef olcott:
On 7/11/2025 3:55 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 04:33 schreef olcott:
On 7/10/2025 9:10 PM, Richard Damon wrote:
On 7/10/25 8:27 PM, olcott wrote:
*I just proved the fact that*
(1) HHH(DDD) is executed
(2) HHH emulates DDD
(3) emulated DDD calls an emulated HHH(DDD)
(4) emulated HHH emulates another instance of DDD
(5) this DDD calls HHH(DDD) again
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Its OK if you are no good with the x86 language
and can't understand the code. I began programming
way back when x86 programming was popular.
Alternatively the details of how multi-tasking
works are too difficult for you. They are probably
too difficult for most programmers.
And thus you have proven my point that either you definition of
what the input is, or what HHH does is just a lie.
But, it seems you are too stupid to understand that problem.
Your claims are:
1) The input contains only the code shown, and thus does not
contain the code of HHH.
2) That HHH is simulating the input given to it, and thus JUST
that input.
3) That HHH simulates the code of HHH.
The test program HHH is not the program under test DDD.
The program under test and the test program will never
stop running unless HHH aborts its DDD.
Another vague claim without evidence.
It not vague at all. You just don't know what
the words mean.
If DDD is under test, then also all function called by DDD are under
test, including HHH.
Since neither HHH nor DDD will ever stop running
unless HHH aborts its DDD, non-halting criteria
has been met.
Since HHH halts, DDD halts, too.
Sure if you lie about which DDD is being referred to.
So, there are no halting criteria. That HHH does not see that the
input specifies a halting program is a failure of HHH, not a correct
halting criterium.
You are confusing yourself with the construct where the program
under test is in the same memory as the program being tested. It
would be much easier to understand for you to keep the input for HHH
separated from HHH, by using a copy of HHH in the input.
To divide the analysis of the program under test
from the test program we only see if DDD simulated
by HHH can reach its own simulated final halt state.
But HHH called by DDD is part of the program and cannot correctly be
separated from it.
Neither HHH nor DDD ever stop running unless HHH
aborts its simulation of DDD. If you have no idea
what recursion is you won't ever get this.
On 7/11/2025 8:42 AM, Richard Damon wrote:
On 7/10/25 10:33 PM, olcott wrote:
On 7/10/2025 9:10 PM, Richard Damon wrote:
On 7/10/25 8:27 PM, olcott wrote:
On 7/10/2025 7:04 PM, Richard Damon wrote:
On 7/10/25 9:24 AM, olcott wrote:
On 7/10/2025 6:35 AM, Richard Damon wrote:
On 7/9/25 10:50 PM, olcott wrote:
On 7/9/2025 8:49 PM, Richard Damon wrote:
On 7/9/25 9:55 AM, olcott wrote:
On 7/9/2025 6:44 AM, Richard Damon wrote:
On 7/8/25 3:49 PM, olcott wrote:
On 7/8/2025 2:01 PM, Mike Terry wrote:
This is one of PO's practiced tactics - he makes a claim, >>>>>>>>>>>>>> and regardless of how patently false that claim appears, >>>>>>>>>>>>>> he refuses to logically defend the claim beyond saying >>>>>>>>>>>>>> "the claim is true, and if you understood xxx you would >>>>>>>>>>>>>> realise it is true".
All of my claims are easily verified facts to those
with the capacity to verify them.
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]
Not a program, must include the code for HHH to be simulatable. >>>>>>>>>>>>
You must have dementia.
I have told you that HHH does emulate DDD
then it emulates itself emulating DDD 500 times now.
And thus you admit that you are lying.
*Here is the proof*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
SO, you admit that HHH fails to emulate JUST the input,
*I have told you that HHH does emulate DDD*
*then it emulates itself emulating DDD 500 times now*
And the question is HOW can it?
You claim it isn't part of the input, and thus it isn't AVAILABLE
for HHH to emualate.
You don't seem to understand that HHH isn't ALLOWED to look at
memory that isn't part of its input, without MAKING that memory
part of its input.
*NOW I PROVED THAT*
*See if you can remember this by your next reply*
No, you are just proving that you don't understand how programs
and input are defined, and thus make yourself into a liar.
*I just proved the fact that*
(1) HHH(DDD) is executed
(2) HHH emulates DDD
(3) emulated DDD calls an emulated HHH(DDD)
(4) emulated HHH emulates another instance of DDD
(5) this DDD calls HHH(DDD) again
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Its OK if you are no good with the x86 language
and can't understand the code. I began programming
way back when x86 programming was popular.
Alternatively the details of how multi-tasking
works are too difficult for you. They are probably
too difficult for most programmers.
And thus you have proven my point that either you definition of what
the input is, or what HHH does is just a lie.
But, it seems you are too stupid to understand that problem.
Your claims are:
1) The input contains only the code shown, and thus does not contain
the code of HHH.
2) That HHH is simulating the input given to it, and thus JUST that
input.
3) That HHH simulates the code of HHH.
The test program HHH is not the program under test DDD.
The program under test and the test program will never
stop running unless HHH aborts its DDD.
But the rogram under test INCLUDED the code for HHH, which is what it
uses when it calls it.
THus, HHH is also part of the program under test.
Since neither DDD nor HHH would ever stop running
unless HHH aborts its simulation of DDD the abort
criteria has been met even in that case.
On 7/11/2025 3:40 AM, Mikko wrote:
On 2025-07-10 14:35:11 +0000, olcott said:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
Proofs don't understand. They prove.
It fails to prove undecidability when the decider
correctly excludes directly executed Turing machines
from its domain.
On 7/11/2025 3:36 AM, Mikko wrote:
On 2025-07-10 14:26:24 +0000, olcott said:
On 7/10/2025 4:30 AM, Mikko wrote:
On 2025-07-09 12:25:59 +0000, olcott said:
On 7/9/2025 3:22 AM, Mikko wrote:
On 2025-07-08 14:21:47 +0000, olcott said:
On 7/8/2025 2:44 AM, Mikko wrote:
On 2025-07-07 14:15:54 +0000, olcott said:
On 7/7/2025 3:37 AM, Mikko wrote:
On 2025-07-07 03:12:30 +0000, olcott said:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your premise.
There is no way that DDD simulated by HHH (according >>>>>>>>>>>>>>> to the semantics of the C programming language)
can possibly reach its own "return" statement final >>>>>>>>>>>>>>> halt state.
And there is no way for HHH to correctly simulate its input and return
an answer
You insistence that a non-terminating input be simulated >>>>>>>>>>>>> until non-existent completion is especially nuts because >>>>>>>>>>>>> you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to completion,
but that it needs to be able to actually PROVE that if this exact input
WAS given to a correct simultor (which won't be itself, since it isn't
doing the complete simulation) will run for an unbounded number of >>>>>>>>>>>> steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
Unless you can quote some respectable author your prohibitions are >>>>>>>>>> meaningless.
To people that never had any actual understanding and
can only parrot textbooks. They need to see this things
in other textbooks.
People who can parrot textbooks know better than people who cannot. >>>>>>>> That you can't when you should shows that you can't even parrot >>>>>>>> textbooks.
I just reverse-engineer what the truth actually is.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
    its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly >>>>>>>     reach its simulated final halt state of ⟨Ĥ.qn⟩
The above does not make sense. There are one subordinate clause
and two nmain clauses but they are not linked to a sentence.
Whithout a sentence nothing is said.
The reason that I gave you a link to the whole
original proof is so that you could see how it
makes sense. Maybe the original proof doesn't
make sense to you either?
I'm not talking about any proof, I'm talking about your words and
symbols quored above. What is written in the book does make sense.
In particular, clauses are meaningfully linked to sentences.
Perhaps the presentation could be clearer but it is intended for
students that already know and understand the earlier parts of the
book.
Linz tried to make two blocks of code into
English sentences.
The "blocks of code" are main clauses. They use abrevations because those >>>> are easier to read than a full natural language sentence. There are other >>>> clauses so that all clauses together form a sentence. In particuralr, ther >>>> is an "and" between them. The sentence is not a truth bearer. Instead it >>>> expresses a desire.
If you want to say something you should learn to construct meaningful
sentences.
That you cannot understand what I say
A false calim aobut another persion is a sin even when presented
as a subordiante clause.
That you cannot understand that you do not understand
what I say is not you understanding what I say.
On 7/11/2025 3:52 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:35 schreef olcott:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
  *if Ĥ applied to ⟨Ĥ⟩ halts, and*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
  *if Ĥ applied to ⟨Ĥ⟩ does not halt*
*It is common knowledge in the theory of computation*
The evidence is that the input includes the code to abort and halt, >>>>>abort and stop running
*IS NOT THE SAME THING AS*
abort and halt
Another claim without evidence.
Another claim without evidence.
*Your lack of knowledge of computer science is not a rebuttal*
Look at the definition of a Turing Machine (e.g., the one here). The
machine has states. Each state can be final or non-final. If the
machine's state is non-final, in the next step the machine "does"
something, namely, it can write something on the tape, move its head,
and/or change its state to a different state. This is how the machine
makes a progress.
However, if the state is final, the machine just stops and continues no
more. This will be its final setting, the head will not move anymore and
the tape remains the same forever. This event is non-reversible and is
what we call halting.
On 7/11/2025 9:31 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 16:27 schreef olcott:Strawman error.
On 7/11/2025 3:55 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 04:33 schreef olcott:
On 7/10/2025 9:10 PM, Richard Damon wrote:
On 7/10/25 8:27 PM, olcott wrote:
*I just proved the fact that*
(1) HHH(DDD) is executed
(2) HHH emulates DDD
(3) emulated DDD calls an emulated HHH(DDD)
(4) emulated HHH emulates another instance of DDD
(5) this DDD calls HHH(DDD) again
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Its OK if you are no good with the x86 language
and can't understand the code. I began programming
way back when x86 programming was popular.
Alternatively the details of how multi-tasking
works are too difficult for you. They are probably
too difficult for most programmers.
And thus you have proven my point that either you definition of
what the input is, or what HHH does is just a lie.
But, it seems you are too stupid to understand that problem.
Your claims are:
1) The input contains only the code shown, and thus does not
contain the code of HHH.
2) That HHH is simulating the input given to it, and thus JUST
that input.
3) That HHH simulates the code of HHH.
The test program HHH is not the program under test DDD.
The program under test and the test program will never
stop running unless HHH aborts its DDD.
Another vague claim without evidence.
It not vague at all. You just don't know what
the words mean.
If DDD is under test, then also all function called by DDD are under
test, including HHH.
Since neither HHH nor DDD will ever stop running
unless HHH aborts its DDD, non-halting criteria
has been met.
Since HHH halts, DDD halts, too.
DDD simulated by HHH specifies non-halting behavior.
Directly executing Turing machines have always been
outside of the domain of every Turing machine decider.
HHH(DDD) is ONLY required to report on the behavior
that its input specifies.
On 7/11/2025 3:59 AM, Fred. Zwarts wrote:
As usual claims without evidence. If we do not change the input (which
aborts after a few cycles o simulation), then the simulating HHH could
reach the final halt state without abort.
It is a very easily verified fact that the input never aborts anything
at all.
Op 11.jul.2025 om 23:05 schreef olcott:
On 7/11/2025 3:52 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:35 schreef olcott:*Your lack of knowledge of computer science is not a rebuttal*
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:Another claim without evidence.
Op 09.jul.2025 om 15:02 schreef olcott:>*From the bottom of page 319 has been adapted to this*
All Turing machine deciders only compute the mapping from their
actual inputs. This entails that they never compute any mapping
from non-inputs.
At least one thing you understand.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
  *if Ĥ applied to ⟨Ĥ⟩ halts, and*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
  *if Ĥ applied to ⟨Ĥ⟩ does not halt*
*It is common knowledge in the theory of computation*The evidence is that the input includes the code to abort and
halt,
abort and stop running *IS NOT THE SAME THING AS*
abort and halt
Another claim without evidence.
Look at the definition of a Turing Machine (e.g., the one here). The
machine has states. Each state can be final or non-final. If the
machine's state is non-final, in the next step the machine "does"
something, namely, it can write something on the tape, move its head,
and/or change its state to a different state. This is how the machine
makes a progress.
So, aborting the simulation when the machine has not yet reached its
final state, is a violation of the Turing Machine.
On Sat, 12 Jul 2025 10:17:55 +0200, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:05 schreef olcott:
On 7/11/2025 3:52 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:35 schreef olcott:*Your lack of knowledge of computer science is not a rebuttal*
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:Another claim without evidence.
Op 09.jul.2025 om 15:02 schreef olcott:>*From the bottom of page 319 has been adapted to this*
All Turing machine deciders only compute the mapping from their
actual inputs. This entails that they never compute any mapping
from non-inputs.
At least one thing you understand.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
  *if Ĥ applied to ⟨Ĥ⟩ halts, and*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
  *if Ĥ applied to ⟨Ĥ⟩ does not halt*
*It is common knowledge in the theory of computation*The evidence is that the input includes the code to abort and
halt,
abort and stop running *IS NOT THE SAME THING AS*
abort and halt
Another claim without evidence.
Look at the definition of a Turing Machine (e.g., the one here). The
machine has states. Each state can be final or non-final. If the
machine's state is non-final, in the next step the machine "does"
something, namely, it can write something on the tape, move its head,
and/or change its state to a different state. This is how the machine
makes a progress.
So, aborting the simulation when the machine has not yet reached its
final state, is a violation of the Turing Machine.
Nonsense, if that was true static code analysers wouldn't be a thing.
/Flibble
On 7/12/2025 5:52 AM, joes wrote:
Am Fri, 11 Jul 2025 16:13:38 -0500 schrieb olcott:
On 7/11/2025 3:59 AM, Fred. Zwarts wrote:
As usual claims without evidence. If we do not change the input (which >>>> aborts after a few cycles o simulation), then the simulating HHH could >>>> reach the final halt state without abort.
It is a very easily verified fact that the input never aborts anything
at all.
Only because it is aborted in turn.
HHH(DDD) simulates its input until it sees that
DDD cannot possibly stop running unless aborted.
void DDD()
{
 HHH(DDD);
 return;
}
Can you see that DDD endlessly repeats its first
line of code when simulated by a pure simulator HHH?
The *input*, being the code of DDD,
doesn't do anything at all since it is just a representation. This
representation has reachable code to abort.
On 7/12/2025 7:20 AM, Richard Damon wrote:
On 7/12/25 7:53 AM, Mr Flibble wrote:That is not always the same as the behavior that
On Sat, 12 Jul 2025 10:17:55 +0200, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:05 schreef olcott:
On 7/11/2025 3:52 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:35 schreef olcott:*Your lack of knowledge of computer science is not a rebuttal*
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:Another claim without evidence.
Op 09.jul.2025 om 15:02 schreef olcott:>*From the bottom of page 319 has been adapted to this*
All Turing machine deciders only compute the mapping from their >>>>>>>>> actual inputs. This entails that they never compute any mapping >>>>>>>>> from non-inputs.
At least one thing you understand.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
   *if Ĥ applied to ⟨Ĥ⟩ halts, and*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
   *if Ĥ applied to ⟨Ĥ⟩ does not halt*
*It is common knowledge in the theory of computation*The evidence is that the input includes the code to abort and >>>>>>>>>> halt,
abort and stop running *IS NOT THE SAME THING AS*
abort and halt
Another claim without evidence.
Look at the definition of a Turing Machine (e.g., the one here). The >>>>> machine has states. Each state can be final or non-final. If the
machine's state is non-final, in the next step the machine "does"
something, namely, it can write something on the tape, move its head, >>>>> and/or change its state to a different state. This is how the machine >>>>> makes a progress.
So, aborting the simulation when the machine has not yet reached its
final state, is a violation of the Turing Machine.
Nonsense, if that was true static code analysers wouldn't be a thing.
/Flibble
Sure it could be. Note the difference between RUNNING a program and
ANALYSIZING a program.
The ONLY thing that actually determines the behavior of a Turing
Machine is its behavior when actually run,
the input specifies.
On 7/12/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:05 schreef olcott:
On 7/11/2025 3:52 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:35 schreef olcott:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
  *if Ĥ applied to ⟨Ĥ⟩ halts, and*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
  *if Ĥ applied to ⟨Ĥ⟩ does not halt*
*It is common knowledge in the theory of computation*
The evidence is that the input includes the code to abort and halt, >>>>>>>abort and stop running
*IS NOT THE SAME THING AS*
abort and halt
Another claim without evidence.
Another claim without evidence.
*Your lack of knowledge of computer science is not a rebuttal*
Look at the definition of a Turing Machine (e.g., the one here). The
machine has states. Each state can be final or non-final. If the
machine's state is non-final, in the next step the machine "does"
something, namely, it can write something on the tape, move its head,
and/or change its state to a different state. This is how the machine
makes a progress.
So, aborting the simulation when the machine has not yet reached its
final state, is a violation of the Turing Machine.
void DDD()
{
 HHH(DDD);
 return;
}
So you don't understand that DDD simulated by
pure simulator HHH keeps repeating its first
line forever?
However, if the state is final, the machine just stops and continues
no more. This will be its final setting, the head will not move
anymore and the tape remains the same forever. This event is non-
reversible and is what we call halting.
Exactly. And halting is what DDD does, when not disturbed by a
premature abort that violates the semantics of the x86 language.
On 7/12/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:05 schreef olcott:
On 7/11/2025 3:52 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:35 schreef olcott:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
  *if Ĥ applied to ⟨Ĥ⟩ halts, and*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
  *if Ĥ applied to ⟨Ĥ⟩ does not halt*
*It is common knowledge in the theory of computation*
The evidence is that the input includes the code to abort and halt, >>>>>>>abort and stop running
*IS NOT THE SAME THING AS*
abort and halt
Another claim without evidence.
Another claim without evidence.
*Your lack of knowledge of computer science is not a rebuttal*
Look at the definition of a Turing Machine (e.g., the one here). The
machine has states. Each state can be final or non-final. If the
machine's state is non-final, in the next step the machine "does"
something, namely, it can write something on the tape, move its head,
and/or change its state to a different state. This is how the machine
makes a progress.
So, aborting the simulation when the machine has not yet reached its
final state, is a violation of the Turing Machine.
void DDD()
{
 HHH(DDD);
 return;
}
So you don't understand that DDD simulated by
pure simulator HHH keeps repeating its first
line forever?
On 7/12/2025 3:22 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 19:50 schreef olcott:
On 7/11/2025 9:31 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 16:27 schreef olcott:Strawman error.
On 7/11/2025 3:55 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 04:33 schreef olcott:
On 7/10/2025 9:10 PM, Richard Damon wrote:
On 7/10/25 8:27 PM, olcott wrote:
*I just proved the fact that*
(1) HHH(DDD) is executed
(2) HHH emulates DDD
(3) emulated DDD calls an emulated HHH(DDD)
(4) emulated HHH emulates another instance of DDD
(5) this DDD calls HHH(DDD) again
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Its OK if you are no good with the x86 language
and can't understand the code. I began programming
way back when x86 programming was popular.
Alternatively the details of how multi-tasking
works are too difficult for you. They are probably
too difficult for most programmers.
And thus you have proven my point that either you definition of >>>>>>>> what the input is, or what HHH does is just a lie.
But, it seems you are too stupid to understand that problem.
Your claims are:
1) The input contains only the code shown, and thus does not
contain the code of HHH.
2) That HHH is simulating the input given to it, and thus JUST >>>>>>>> that input.
3) That HHH simulates the code of HHH.
The test program HHH is not the program under test DDD.
The program under test and the test program will never
stop running unless HHH aborts its DDD.
Another vague claim without evidence.
It not vague at all. You just don't know what
the words mean.
If DDD is under test, then also all function called by DDD are
under test, including HHH.
Since neither HHH nor DDD will ever stop running
unless HHH aborts its DDD, non-halting criteria
has been met.
Since HHH halts, DDD halts, too.
DDD simulated by HHH specifies non-halting behavior.
Counter-factual.
void DDD()
{
 HHH(DDD);
 return;
}
DDD simulated by pure simulator HHH keeps
repeating its first line of code endlessly.
If at any point HHH aborts this simulation
DDD still never reaches its final halt state.
This is not that hard, thus anyone that disagrees
proves their own lack of sufficient technical competence.
On 7/12/2025 3:05 AM, Mikko wrote:
On 2025-07-11 15:22:32 +0000, olcott said:
On 7/11/2025 3:36 AM, Mikko wrote:
On 2025-07-10 14:26:24 +0000, olcott said:
On 7/10/2025 4:30 AM, Mikko wrote:
On 2025-07-09 12:25:59 +0000, olcott said:
On 7/9/2025 3:22 AM, Mikko wrote:
On 2025-07-08 14:21:47 +0000, olcott said:
On 7/8/2025 2:44 AM, Mikko wrote:
On 2025-07-07 14:15:54 +0000, olcott said:
On 7/7/2025 3:37 AM, Mikko wrote:
On 2025-07-07 03:12:30 +0000, olcott said:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your premise.
There is no way that DDD simulated by HHH (according >>>>>>>>>>>>>>>>> to the semantics of the C programming language) >>>>>>>>>>>>>>>>> can possibly reach its own "return" statement final >>>>>>>>>>>>>>>>> halt state.
And there is no way for HHH to correctly simulate its input and return
an answer
You insistence that a non-terminating input be simulated >>>>>>>>>>>>>>> until non-existent completion is especially nuts because >>>>>>>>>>>>>>> you have been told about this dozens of times.
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to completion,
but that it needs to be able to actually PROVE that if this exact input
WAS given to a correct simultor (which won't be itself, since it isn't
doing the complete simulation) will run for an unbounded number of
steps.
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
Unless you can quote some respectable author your prohibitions are >>>>>>>>>>>> meaningless.
To people that never had any actual understanding and
can only parrot textbooks. They need to see this things
in other textbooks.
People who can parrot textbooks know better than people who cannot. >>>>>>>>>> That you can't when you should shows that you can't even parrot >>>>>>>>>> textbooks.
I just reverse-engineer what the truth actually is.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ >>>>>>>>>     ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches >>>>>>>>>     its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>     ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly >>>>>>>>>     reach its simulated final halt state of ⟨Ĥ.qn⟩
The above does not make sense. There are one subordinate clause >>>>>>>> and two nmain clauses but they are not linked to a sentence.
Whithout a sentence nothing is said.
The reason that I gave you a link to the whole
original proof is so that you could see how it
makes sense. Maybe the original proof doesn't
make sense to you either?
I'm not talking about any proof, I'm talking about your words and
symbols quored above. What is written in the book does make sense. >>>>>> In particular, clauses are meaningfully linked to sentences.
Perhaps the presentation could be clearer but it is intended for
students that already know and understand the earlier parts of the >>>>>> book.
Linz tried to make two blocks of code into
English sentences.
The "blocks of code" are main clauses. They use abrevations because those
are easier to read than a full natural language sentence. There are other
clauses so that all clauses together form a sentence. In particuralr, ther
is an "and" between them. The sentence is not a truth bearer. Instead it >>>>>> expresses a desire.
If you want to say something you should learn to construct meaningful >>>>>> sentences.
That you cannot understand what I say
A false calim aobut another persion is a sin even when presented
as a subordiante clause.
That you cannot understand that you do not understand
what I say is not you understanding what I say.
Nevertheless a false claim about another prestion is a sin.
When you prove that you don't understand something and
I claim that you don't understand this then my statement
is factually correct.
Can we get back to the point or is
your whole point just deflection away from the point?
On 7/12/2025 3:00 AM, Mikko wrote:
On 2025-07-11 15:25:29 +0000, olcott said:
On 7/11/2025 3:40 AM, Mikko wrote:
On 2025-07-10 14:35:11 +0000, olcott said:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
Proofs don't understand. They prove.
It fails to prove undecidability when the decider
correctly excludes directly executed Turing machines
from its domain.
That does not change the last sentence of the proof. Therefore the
proof proves what it would prove anyway.
It completely invalidates the proof.
On 7/12/2025 6:27 PM, Richard Damon wrote:
On 7/12/25 11:16 AM, olcott wrote:
On 7/12/2025 5:52 AM, joes wrote:
Am Fri, 11 Jul 2025 16:13:38 -0500 schrieb olcott:
On 7/11/2025 3:59 AM, Fred. Zwarts wrote:
As usual claims without evidence. If we do not change the input
(which
aborts after a few cycles o simulation), then the simulating HHH
could
reach the final halt state without abort.
It is a very easily verified fact that the input never aborts anything >>>>> at all.
Only because it is aborted in turn.
HHH(DDD) simulates its input until it sees that
DDD cannot possibly stop running unless aborted.
Then why does the direct execution of DDD halt?
The direct execution is a different sequence of steps
because it is reaping the benefits of HHH having already
aborted its own input.
On 7/13/2025 3:37 PM, Richard Damon wrote:
On 7/13/25 11:48 AM, olcott wrote:
On 7/12/2025 6:27 PM, Richard Damon wrote:
On 7/12/25 11:16 AM, olcott wrote:
On 7/12/2025 5:52 AM, joes wrote:
Am Fri, 11 Jul 2025 16:13:38 -0500 schrieb olcott:
On 7/11/2025 3:59 AM, Fred. Zwarts wrote:
As usual claims without evidence. If we do not change the input >>>>>>>> (which
aborts after a few cycles o simulation), then the simulating HHH >>>>>>>> could
reach the final halt state without abort.
It is a very easily verified fact that the input never aborts
anything
at all.
Only because it is aborted in turn.
HHH(DDD) simulates its input until it sees that
DDD cannot possibly stop running unless aborted.
Then why does the direct execution of DDD halt?
The direct execution is a different sequence of steps
because it is reaping the benefits of HHH having already
aborted its own input.
So?
Its nuts to expect the exact same behavior
from a different sequence of steps.
HHH1(DDD)==1 and HHH(DDD)==0 are both correct and
are different because they measure a different
sequence of steps.
On 7/13/2025 4:22 PM, olcott wrote:
On 7/13/2025 3:37 PM, Richard Damon wrote:
On 7/13/25 11:48 AM, olcott wrote:
On 7/12/2025 6:27 PM, Richard Damon wrote:
On 7/12/25 11:16 AM, olcott wrote:
On 7/12/2025 5:52 AM, joes wrote:
Am Fri, 11 Jul 2025 16:13:38 -0500 schrieb olcott:
On 7/11/2025 3:59 AM, Fred. Zwarts wrote:
As usual claims without evidence. If we do not change the input >>>>>>>>> (which
aborts after a few cycles o simulation), then the simulating >>>>>>>>> HHH could
reach the final halt state without abort.
It is a very easily verified fact that the input never aborts
anything
at all.
Only because it is aborted in turn.
HHH(DDD) simulates its input until it sees that
DDD cannot possibly stop running unless aborted.
Then why does the direct execution of DDD halt?
The direct execution is a different sequence of steps
because it is reaping the benefits of HHH having already
aborted its own input.
So?
Its nuts to expect the exact same behavior
from a different sequence of steps.
HHH1(DDD)==1 and HHH(DDD)==0 are both correct and
are different because they measure a different
sequence of steps.
Claude.ai agrees
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
On 7/13/2025 2:09 AM, Mikko wrote:
On 2025-07-12 14:26:09 +0000, olcott said:
On 7/12/2025 3:00 AM, Mikko wrote:
On 2025-07-11 15:25:29 +0000, olcott said:
On 7/11/2025 3:40 AM, Mikko wrote:
On 2025-07-10 14:35:11 +0000, olcott said:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
Proofs don't understand. They prove.
It fails to prove undecidability when the decider
correctly excludes directly executed Turing machines
from its domain.
That does not change the last sentence of the proof. Therefore the
proof proves what it would prove anyway.
It completely invalidates the proof.
No, it does not. The proof reamins as it was. A proof is valid if there
is no error in the proof. Nothing else is relevant.
There are errors that you do not understand.
On 7/13/2025 2:09 AM, Mikko wrote:
On 2025-07-12 14:26:09 +0000, olcott said:
On 7/12/2025 3:00 AM, Mikko wrote:
On 2025-07-11 15:25:29 +0000, olcott said:
On 7/11/2025 3:40 AM, Mikko wrote:
On 2025-07-10 14:35:11 +0000, olcott said:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
Proofs don't understand. They prove.
It fails to prove undecidability when the decider
correctly excludes directly executed Turing machines
from its domain.
That does not change the last sentence of the proof. Therefore the
proof proves what it would prove anyway.
It completely invalidates the proof.
No, it does not. The proof reamins as it was. A proof is valid if there
is no error in the proof. Nothing else is relevant.
There are errors that you do not understand.
On 7/13/2025 2:05 AM, Mikko wrote:
On 2025-07-12 14:34:05 +0000, olcott said:
On 7/12/2025 3:05 AM, Mikko wrote:
On 2025-07-11 15:22:32 +0000, olcott said:
On 7/11/2025 3:36 AM, Mikko wrote:
On 2025-07-10 14:26:24 +0000, olcott said:
On 7/10/2025 4:30 AM, Mikko wrote:
On 2025-07-09 12:25:59 +0000, olcott said:
On 7/9/2025 3:22 AM, Mikko wrote:
On 2025-07-08 14:21:47 +0000, olcott said:
On 7/8/2025 2:44 AM, Mikko wrote:The above does not make sense. There are one subordinate clause >>>>>>>>>> and two nmain clauses but they are not linked to a sentence. >>>>>>>>>> Whithout a sentence nothing is said.
On 2025-07-07 14:15:54 +0000, olcott said:
On 7/7/2025 3:37 AM, Mikko wrote:
On 2025-07-07 03:12:30 +0000, olcott said:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote:
On 7/6/25 11:19 AM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your premise.
There is no way that DDD simulated by HHH (according >>>>>>>>>>>>>>>>>>> to the semantics of the C programming language) >>>>>>>>>>>>>>>>>>> can possibly reach its own "return" statement final >>>>>>>>>>>>>>>>>>> halt state.
And there is no way for HHH to correctly simulate its input and return
an answer
You insistence that a non-terminating input be simulated >>>>>>>>>>>>>>>>> until non-existent completion is especially nuts because >>>>>>>>>>>>>>>>> you have been told about this dozens of times. >>>>>>>>>>>>>>>>>
What the F is wrong with you?
It seems you don't understand those words.
I don't say that the decider needs to simulate the input to completion,
but that it needs to be able to actually PROVE that if this exact input
WAS given to a correct simultor (which won't be itself, since it isn't
doing the complete simulation) will run for an unbounded number of
steps.
No decider is ever allowed to report on anything >>>>>>>>>>>>>>> besides the actual behavior that its input actually >>>>>>>>>>>>>>> specifies.
Unless you can quote some respectable author your prohibitions are
meaningless.
To people that never had any actual understanding and >>>>>>>>>>>>> can only parrot textbooks. They need to see this things >>>>>>>>>>>>> in other textbooks.
People who can parrot textbooks know better than people who cannot.
That you can't when you should shows that you can't even parrot >>>>>>>>>>>> textbooks.
I just reverse-engineer what the truth actually is.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ >>>>>>>>>>>     ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches >>>>>>>>>>>     its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>     ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
    reach its simulated final halt state of ⟨Ĥ.qn⟩ >>>>>>>>>>
The reason that I gave you a link to the whole
original proof is so that you could see how it
makes sense. Maybe the original proof doesn't
make sense to you either?
I'm not talking about any proof, I'm talking about your words and >>>>>>>> symbols quored above. What is written in the book does make sense. >>>>>>>> In particular, clauses are meaningfully linked to sentences.
Perhaps the presentation could be clearer but it is intended for >>>>>>>> students that already know and understand the earlier parts of the >>>>>>>> book.
Linz tried to make two blocks of code into
English sentences.
The "blocks of code" are main clauses. They use abrevations because those
are easier to read than a full natural language sentence. There are other
clauses so that all clauses together form a sentence. In particuralr, ther
is an "and" between them. The sentence is not a truth bearer. Instead it
expresses a desire.
If you want to say something you should learn to construct meaningful >>>>>>>> sentences.
That you cannot understand what I say
A false calim aobut another persion is a sin even when presented
as a subordiante clause.
That you cannot understand that you do not understand
what I say is not you understanding what I say.
Nevertheless a false claim about another prestion is a sin.
When you prove that you don't understand something and
I claim that you don't understand this then my statement
is factually correct.
What I understand or not is not important eonough to lie about or even
mention.
You have proven do not understand some of these things.
On 7/13/2025 1:09 AM, Fred. Zwarts wrote:
Op 12.jul.2025 om 17:21 schreef olcott:
On 7/12/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:05 schreef olcott:
On 7/11/2025 3:52 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:35 schreef olcott:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
  *if Ĥ applied to ⟨Ĥ⟩ halts, and*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
  *if Ĥ applied to ⟨Ĥ⟩ does not halt*
*It is common knowledge in the theory of computation*
The evidence is that the input includes the code to abort and >>>>>>>>>> halt,
abort and stop running
*IS NOT THE SAME THING AS*
abort and halt
Another claim without evidence.
Another claim without evidence.
*Your lack of knowledge of computer science is not a rebuttal*
Look at the definition of a Turing Machine (e.g., the one here).
The machine has states. Each state can be final or non-final. If
the machine's state is non-final, in the next step the machine
"does" something, namely, it can write something on the tape, move
its head, and/or change its state to a different state. This is how
the machine makes a progress.
So, aborting the simulation when the machine has not yet reached its
final state, is a violation of the Turing Machine.
void DDD()
{
  HHH(DDD);
  return;
}
So you don't understand that DDD simulated by
pure simulator HHH keeps repeating its first
line forever?
Irrelevant, because that is not what HHH does.
void DDD()
{
 HHH(DDD);
 return;
}
I stipulated this HHH <is> a pure simulator temporarily
overriding and superseding everything else that I ever
said about HHH.
On 7/13/2025 8:41 PM, Richard Damon wrote:Again you are publishing the incomplete input for HHH, even including
On 7/13/25 11:18 AM, olcott wrote:
On 7/13/2025 2:09 AM, Mikko wrote:
On 2025-07-12 14:26:09 +0000, olcott said:
On 7/12/2025 3:00 AM, Mikko wrote:
On 2025-07-11 15:25:29 +0000, olcott said:
On 7/11/2025 3:40 AM, Mikko wrote:
On 2025-07-10 14:35:11 +0000, olcott said:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
Proofs don't understand. They prove.
It fails to prove undecidability when the decider
correctly excludes directly executed Turing machines
from its domain.
That does not change the last sentence of the proof. Therefore the >>>>>> proof proves what it would prove anyway.
It completely invalidates the proof.
No, it does not. The proof reamins as it was. A proof is valid if there >>>> is no error in the proof. Nothing else is relevant.
There are errors that you do not understand.
No, there aren't. If you think there are, you would point to the exact
step in error.
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
The input to HHH(DD) does specify non-halting behavior.
Turing machine halt deciders only report on the behavior
that their finite string input actually specifies.
_DD()
[00002162] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002163] 8bec          mov ebp,esp
[00002165] 51Â Â Â Â Â Â Â Â Â Â Â Â push ecx
[00002166] 6862210000Â Â Â Â push 00002162
[0000216b] e862f4ffff    call 000015d2
[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]
On 7/13/2025 8:40 PM, Richard Damon wrote:
On 7/13/25 5:59 PM, olcott wrote:
On 7/13/2025 4:22 PM, olcott wrote:
On 7/13/2025 3:37 PM, Richard Damon wrote:
On 7/13/25 11:48 AM, olcott wrote:
On 7/12/2025 6:27 PM, Richard Damon wrote:
On 7/12/25 11:16 AM, olcott wrote:
On 7/12/2025 5:52 AM, joes wrote:
Am Fri, 11 Jul 2025 16:13:38 -0500 schrieb olcott:
On 7/11/2025 3:59 AM, Fred. Zwarts wrote:
As usual claims without evidence. If we do not change the >>>>>>>>>>> input (which
aborts after a few cycles o simulation), then the simulating >>>>>>>>>>> HHH could
reach the final halt state without abort.
It is a very easily verified fact that the input never aborts >>>>>>>>>> anything
at all.
Only because it is aborted in turn.
HHH(DDD) simulates its input until it sees that
DDD cannot possibly stop running unless aborted.
Then why does the direct execution of DDD halt?
The direct execution is a different sequence of steps
because it is reaping the benefits of HHH having already
aborted its own input.
So?
Its nuts to expect the exact same behavior
from a different sequence of steps.
HHH1(DDD)==1 and HHH(DDD)==0 are both correct and
are different because they measure a different
sequence of steps.
Claude.ai agrees
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
Because you lied to it.
That it figured out exactly what the actual non-halting
pattern behavior was on its own all by itself proves
that it understands how and why I am correct.
That you deny this (with the plausible credentials
that you cited) seems like an MD that does not know
what diseases are.
On 7/13/2025 8:41 PM, Richard Damon wrote:
On 7/13/25 11:18 AM, olcott wrote:
On 7/13/2025 2:09 AM, Mikko wrote:
On 2025-07-12 14:26:09 +0000, olcott said:
On 7/12/2025 3:00 AM, Mikko wrote:
On 2025-07-11 15:25:29 +0000, olcott said:
On 7/11/2025 3:40 AM, Mikko wrote:
On 2025-07-10 14:35:11 +0000, olcott said:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
Proofs don't understand. They prove.
It fails to prove undecidability when the decider
correctly excludes directly executed Turing machines
from its domain.
That does not change the last sentence of the proof. Therefore the >>>>>> proof proves what it would prove anyway.
It completely invalidates the proof.
No, it does not. The proof reamins as it was. A proof is valid if there >>>> is no error in the proof. Nothing else is relevant.
There are errors that you do not understand.
No, there aren't. If you think there are, you would point to the exact
step in error.
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
The input to HHH(DD) does specify non-halting behavior.
Turing machine halt deciders only report on the behavior
that their finite string input actually specifies.
_DD()
[00002162] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002163] 8bec          mov ebp,esp
[00002165] 51Â Â Â Â Â Â Â Â Â Â Â Â push ecx
[00002166] 6862210000Â Â Â Â push 00002162
[0000216b] e862f4ffff    call 000015d2
[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]
People can get away with saying the the simulation
of the input is incorrect until we get as concrete
as the x86 language that specifies the only correct
measure of correct simulation is the semantics of
the x86 language.
When one or more instructions of DD are emulated
according to the semantics of the x86 language by
any termination analyzer at machine address 000015d2
No DD emulated by any HHH ever reaches its own "ret"
instruction.
int DD()Untrue. It is not a huge insight.
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
*There are errors with the proof*
(1) Simulating terminator HHH makes the second line of code unreachable
for DDD simulated by HHH according to the semantics of the C programming language.
*No one ever noticed that before my work*
(2) This makes the conventional halting problem proof counter-exampleCite one.
input decidable when decided on the basis of the actual behavior that
its input actually specifies.
(3) Halt deciders only report on the behavior that their input actually specifies even though some textbooks disagree.
On 7/14/2025 3:49 AM, Mikko wrote:
On 2025-07-13 15:17:22 +0000, olcott said:
On 7/13/2025 2:05 AM, Mikko wrote:
On 2025-07-12 14:34:05 +0000, olcott said:
On 7/12/2025 3:05 AM, Mikko wrote:
On 2025-07-11 15:22:32 +0000, olcott said:
On 7/11/2025 3:36 AM, Mikko wrote:
On 2025-07-10 14:26:24 +0000, olcott said:
On 7/10/2025 4:30 AM, Mikko wrote:
On 2025-07-09 12:25:59 +0000, olcott said:
On 7/9/2025 3:22 AM, Mikko wrote:
On 2025-07-08 14:21:47 +0000, olcott said:
On 7/8/2025 2:44 AM, Mikko wrote:The above does not make sense. There are one subordinate clause >>>>>>>>>>>> and two nmain clauses but they are not linked to a sentence. >>>>>>>>>>>> Whithout a sentence nothing is said.
On 2025-07-07 14:15:54 +0000, olcott said:
On 7/7/2025 3:37 AM, Mikko wrote:
On 2025-07-07 03:12:30 +0000, olcott said:
On 7/6/2025 9:09 PM, Richard Damon wrote:
On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/6/25 11:19 AM, olcott wrote:
No, it just isn't smart enough to detect that you lied in your premise.
void DDD()
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN* >>>>>>>>>>>>>>>>>>>>
There is no way that DDD simulated by HHH (according >>>>>>>>>>>>>>>>>>>>> to the semantics of the C programming language) >>>>>>>>>>>>>>>>>>>>> can possibly reach its own "return" statement final >>>>>>>>>>>>>>>>>>>>> halt state.
And there is no way for HHH to correctly simulate its input and return
an answer
You insistence that a non-terminating input be simulated >>>>>>>>>>>>>>>>>>> until non-existent completion is especially nuts because >>>>>>>>>>>>>>>>>>> you have been told about this dozens of times. >>>>>>>>>>>>>>>>>>>
What the F is wrong with you?
It seems you don't understand those words. >>>>>>>>>>>>>>>>>>
I don't say that the decider needs to simulate the input to completion,
but that it needs to be able to actually PROVE that if this exact input
WAS given to a correct simultor (which won't be itself, since it isn't
doing the complete simulation) will run for an unbounded number of
steps.
No decider is ever allowed to report on anything >>>>>>>>>>>>>>>>> besides the actual behavior that its input actually >>>>>>>>>>>>>>>>> specifies.
Unless you can quote some respectable author your prohibitions are
meaningless.
To people that never had any actual understanding and >>>>>>>>>>>>>>> can only parrot textbooks. They need to see this things >>>>>>>>>>>>>>> in other textbooks.
People who can parrot textbooks know better than people who cannot.
That you can't when you should shows that you can't even parrot >>>>>>>>>>>>>> textbooks.
I just reverse-engineer what the truth actually is.
*From the bottom of page 319 has been adapted to this* >>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf >>>>>>>>>>>>>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ >>>>>>>>>>>>>     ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches >>>>>>>>>>>>>     its simulated final halt state of ⟨Ĥ.qn⟩ >>>>>>>>>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>     ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
    reach its simulated final halt state of ⟨Ĥ.qn⟩ >>>>>>>>>>>>
The reason that I gave you a link to the whole
original proof is so that you could see how it
makes sense. Maybe the original proof doesn't
make sense to you either?
I'm not talking about any proof, I'm talking about your words and >>>>>>>>>> symbols quored above. What is written in the book does make sense. >>>>>>>>>> In particular, clauses are meaningfully linked to sentences. >>>>>>>>>> Perhaps the presentation could be clearer but it is intended for >>>>>>>>>> students that already know and understand the earlier parts of the >>>>>>>>>> book.
Linz tried to make two blocks of code into
English sentences.
The "blocks of code" are main clauses. They use abrevations because those
are easier to read than a full natural language sentence. There are other
clauses so that all clauses together form a sentence. In particuralr, ther
is an "and" between them. The sentence is not a truth bearer. Instead it
expresses a desire.
If you want to say something you should learn to construct meaningful
sentences.
That you cannot understand what I say
A false calim aobut another persion is a sin even when presented >>>>>>>> as a subordiante clause.
That you cannot understand that you do not understand
what I say is not you understanding what I say.
Nevertheless a false claim about another prestion is a sin.
When you prove that you don't understand something and
I claim that you don't understand this then my statement
is factually correct.
What I understand or not is not important eonough to lie about or even >>>> mention.
You have proven do not understand some of these things.
It is true that your presentation does not make ehough sense that there
could be something to be understood. But in that case it is sufficient
that I understand that you said nothing and can point out that to those
readers how may fail to notice.
And some of my readers have ADHD so badly that when
I correct their mistakes hundreds of times they never
notice any of the words of any of those corrections.
On 7/14/2025 3:54 AM, Mikko wrote:
On 2025-07-13 15:18:01 +0000, olcott said:
On 7/13/2025 2:09 AM, Mikko wrote:
On 2025-07-12 14:26:09 +0000, olcott said:
On 7/12/2025 3:00 AM, Mikko wrote:
On 2025-07-11 15:25:29 +0000, olcott said:
On 7/11/2025 3:40 AM, Mikko wrote:
On 2025-07-10 14:35:11 +0000, olcott said:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
Proofs don't understand. They prove.
It fails to prove undecidability when the decider
correctly excludes directly executed Turing machines
from its domain.
That does not change the last sentence of the proof. Therefore the >>>>>> proof proves what it would prove anyway.
It completely invalidates the proof.
No, it does not. The proof reamins as it was. A proof is valid if there >>>> is no error in the proof. Nothing else is relevant.
There are errors that you do not understand.
For the purpose of these discussion it is not neessary to understand
your errors beyond that they are errors.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
*There are errors with the proof*
On 7/14/2025 8:30 AM, joes wrote:
Am Mon, 14 Jul 2025 08:19:15 -0500 schrieb olcott:
int DD()Untrue. It is not a huge insight.
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
*There are errors with the proof*
(1) Simulating terminator HHH makes the second line of code unreachable
for DDD simulated by HHH according to the semantics of the C programming >>> language.
*No one ever noticed that before my work*
The 90 year old counter-example input to the HP
proof is defeated by simulating termination analyzers
that report on the actual behavior that their input
actually specifies.
The stupid mistake that any decider is to report on
behavior other than the behavior that its input actually
specifies is simply a stupid mistake.
On 7/14/2025 4:19 AM, Fred. Zwarts wrote:
Op 13.jul.2025 om 17:38 schreef olcott:
On 7/13/2025 1:09 AM, Fred. Zwarts wrote:
Op 12.jul.2025 om 17:21 schreef olcott:
On 7/12/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:05 schreef olcott:
On 7/11/2025 3:52 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:35 schreef olcott:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ >>>>>>>>>   *if Ĥ applied to ⟨Ĥ⟩ halts, and*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>   *if Ĥ applied to ⟨Ĥ⟩ does not halt*
*It is common knowledge in the theory of computation*
The evidence is that the input includes the code to abort >>>>>>>>>>>> and halt,
abort and stop running
*IS NOT THE SAME THING AS*
abort and halt
Another claim without evidence.
Another claim without evidence.
*Your lack of knowledge of computer science is not a rebuttal*
Look at the definition of a Turing Machine (e.g., the one here). >>>>>>> The machine has states. Each state can be final or non-final. If >>>>>>> the machine's state is non-final, in the next step the machine
"does" something, namely, it can write something on the tape,
move its head, and/or change its state to a different state. This >>>>>>> is how the machine makes a progress.
So, aborting the simulation when the machine has not yet reached
its final state, is a violation of the Turing Machine.
void DDD()
{
  HHH(DDD);
  return;
}
So you don't understand that DDD simulated by
pure simulator HHH keeps repeating its first
line forever?
Irrelevant, because that is not what HHH does.
void DDD()
{
  HHH(DDD);
  return;
}
I stipulated this HHH <is> a pure simulator temporarily
overriding and superseding everything else that I ever
said about HHH.
You can stipulate that, but is irrelevant for the HHH you published in
Halt7.c. *That* HHH is not a pure simulator. The fact that a pure
simulator fails is no proof for the correctness of the non-pure
simulator.
Dreaming of other simulators with other behaviour does not change the
factual behaviour of the HHH we are discussing.
void RRR()
{
 SSS(DDD);
 return;
}
When RRR is simulated by pure simulator SSS
RRR simulated by SSS never reaches its own
"return" statement.
When we adapt SSS so that it only simulatesNow there is a final halt state, but SSS is unable to reach it. This illustrates that simulation is not the right tool for this input to
N instructions of RRR then no RRR ever reaches
its own "return" statement.
On 7/14/2025 4:24 AM, Fred. Zwarts wrote:
Op 14.jul.2025 om 05:11 schreef olcott:
On 7/13/2025 8:41 PM, Richard Damon wrote:Again you are publishing the incomplete input for HHH,
On 7/13/25 11:18 AM, olcott wrote:
On 7/13/2025 2:09 AM, Mikko wrote:
On 2025-07-12 14:26:09 +0000, olcott said:
On 7/12/2025 3:00 AM, Mikko wrote:
On 2025-07-11 15:25:29 +0000, olcott said:
On 7/11/2025 3:40 AM, Mikko wrote:
On 2025-07-10 14:35:11 +0000, olcott said:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping >>>>>>>>>>>>> from their actual inputs. This entails that they never >>>>>>>>>>>>> compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
Proofs don't understand. They prove.
It fails to prove undecidability when the decider
correctly excludes directly executed Turing machines
from its domain.
That does not change the last sentence of the proof. Therefore the >>>>>>>> proof proves what it would prove anyway.
It completely invalidates the proof.
No, it does not. The proof reamins as it was. A proof is valid if
there
is no error in the proof. Nothing else is relevant.
There are errors that you do not understand.
No, there aren't. If you think there are, you would point to the
exact step in error.
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
The input to HHH(DD) does specify non-halting behavior.
Turing machine halt deciders only report on the behavior
that their finite string input actually specifies.
_DD()
[00002162] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002163] 8bec          mov ebp,esp
[00002165] 51Â Â Â Â Â Â Â Â Â Â Â Â push ecx
[00002166] 6862210000Â Â Â Â push 00002162
[0000216b] e862f4ffff    call 000015d2
[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]
No one needs to know anything about HHH other than
it emulates its input with an x86 emulator.
People that have no idea what an emulator is and
people that cannot begin to understand how x86 code
works may think otherwise.
even including the size. We have pointed out already that part of the
input is missing. This input at 0000216b refers to address 000015d2,
which is missing in the input. We know that the HHH at 000015d2 is an
aborting simulator that halts and returns with a value 0. When we use
that fact, we see that when the call returns with that value, DDD
reaches a final halt status.
Sure and when the Moon is made from green cheese
we can make toasted cheese sandwiches from Moon rocks.
No correctly emulated C function can possibly return
to its emulator because its emulator never called it.
On 7/14/2025 3:54 AM, Mikko wrote:
On 2025-07-13 15:18:01 +0000, olcott said:
On 7/13/2025 2:09 AM, Mikko wrote:
On 2025-07-12 14:26:09 +0000, olcott said:
On 7/12/2025 3:00 AM, Mikko wrote:
On 2025-07-11 15:25:29 +0000, olcott said:
On 7/11/2025 3:40 AM, Mikko wrote:
On 2025-07-10 14:35:11 +0000, olcott said:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping
from their actual inputs. This entails that they never
compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
Proofs don't understand. They prove.
It fails to prove undecidability when the decider
correctly excludes directly executed Turing machines
from its domain.
That does not change the last sentence of the proof. Therefore the >>>>>> proof proves what it would prove anyway.
It completely invalidates the proof.
No, it does not. The proof reamins as it was. A proof is valid if there >>>> is no error in the proof. Nothing else is relevant.
There are errors that you do not understand.
For the purpose of these discussion it is not neessary to understand
your errors beyond that they are errors.
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
*There are errors with the proof*
(1) Simulating terminator HHH makes the second line
of code unreachable for DDD simulated by HHH according
to the semantics of the C programming language.
*No one ever noticed that before my work*
(2) This makes the conventional halting problem proof
counter-example input decidable when decided on the
basis of the actual behavior that its input actually
specifies.
(3) Halt deciders only report on the behavior that their
input actually specifies even though some textbooks
disagree.
On 7/15/2025 5:10 AM, Fred. Zwarts wrote:
Op 14.jul.2025 om 15:25 schreef olcott:
On 7/14/2025 4:19 AM, Fred. Zwarts wrote:
Op 13.jul.2025 om 17:38 schreef olcott:
On 7/13/2025 1:09 AM, Fred. Zwarts wrote:
Op 12.jul.2025 om 17:21 schreef olcott:
On 7/12/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:05 schreef olcott:
On 7/11/2025 3:52 AM, Fred. Zwarts wrote:
Op 10.jul.2025 om 16:35 schreef olcott:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping >>>>>>>>>>>>> from their actual inputs. This entails that they never >>>>>>>>>>>>> compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ >>>>>>>>>>>   *if Ĥ applied to ⟨Ĥ⟩ halts, and*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>   *if Ĥ applied to ⟨Ĥ⟩ does not halt*
*It is common knowledge in the theory of computation*
The evidence is that the input includes the code to abort >>>>>>>>>>>>>> and halt,
abort and stop running
*IS NOT THE SAME THING AS*
abort and halt
Another claim without evidence.
Another claim without evidence.
*Your lack of knowledge of computer science is not a rebuttal* >>>>>>>>>
Look at the definition of a Turing Machine (e.g., the one
here). The machine has states. Each state can be final or non- >>>>>>>>> final. If the machine's state is non-final, in the next step >>>>>>>>> the machine "does" something, namely, it can write something on >>>>>>>>> the tape, move its head, and/or change its state to a different >>>>>>>>> state. This is how the machine makes a progress.
So, aborting the simulation when the machine has not yet reached >>>>>>>> its final state, is a violation of the Turing Machine.
void DDD()
{
  HHH(DDD);
  return;
}
So you don't understand that DDD simulated by
pure simulator HHH keeps repeating its first
line forever?
Irrelevant, because that is not what HHH does.
void DDD()
{
  HHH(DDD);
  return;
}
I stipulated this HHH <is> a pure simulator temporarily
overriding and superseding everything else that I ever
said about HHH.
You can stipulate that, but is irrelevant for the HHH you published
in Halt7.c. *That* HHH is not a pure simulator. The fact that a pure
simulator fails is no proof for the correctness of the non-pure
simulator.
Dreaming of other simulators with other behaviour does not change
the factual behaviour of the HHH we are discussing.
void RRR()
{
  SSS(RRR);
  return;
}
When RRR is simulated by pure simulator SSS
RRR simulated by SSS never reaches its own
"return" statement.
You have been corrected on this many times, but you seem unable to
understand it.
We are discussing a non-pure simulator, so the behaviour of a pure
simulator is irrelevant.
When we adapt SSS so that it only simulates
N instructions of RRR then no RRR ever reaches
its own "return" statement.
Now there is a final halt state, but SSS is unable to reach it. This
illustrates that simulation is not the right tool for this input to
analyse the behaviour, because it cannot see the full specification.
Other tools are needed, but each tool will fail for some inputs.
_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]
So when the actual behavior of the actual x86 code
disagrees with you you disagree with the x86 language.
On 7/15/2025 4:11 AM, Mikko wrote:If you close your eyes for your mistakes, or if you do not understand
On 2025-07-14 13:08:16 +0000, olcott said:
On 7/14/2025 3:49 AM, Mikko wrote:
On 2025-07-13 15:17:22 +0000, olcott said:
On 7/13/2025 2:05 AM, Mikko wrote:
On 2025-07-12 14:34:05 +0000, olcott said:
On 7/12/2025 3:05 AM, Mikko wrote:
On 2025-07-11 15:22:32 +0000, olcott said:
On 7/11/2025 3:36 AM, Mikko wrote:
On 2025-07-10 14:26:24 +0000, olcott said:
On 7/10/2025 4:30 AM, Mikko wrote:
On 2025-07-09 12:25:59 +0000, olcott said:
On 7/9/2025 3:22 AM, Mikko wrote:
On 2025-07-08 14:21:47 +0000, olcott said:
On 7/8/2025 2:44 AM, Mikko wrote:The above does not make sense. There are one subordinate >>>>>>>>>>>>>> clause
On 2025-07-07 14:15:54 +0000, olcott said:
On 7/7/2025 3:37 AM, Mikko wrote:
On 2025-07-07 03:12:30 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 7/6/2025 9:09 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 7/6/25 11:19 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>
void DDD()No, it just isn't smart enough to detect that you >>>>>>>>>>>>>>>>>>>>>> lied in your premise.
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN* >>>>>>>>>>>>>>>>>>>>>>
There is no way that DDD simulated by HHH (according >>>>>>>>>>>>>>>>>>>>>>> to the semantics of the C programming language) >>>>>>>>>>>>>>>>>>>>>>> can possibly reach its own "return" statement final >>>>>>>>>>>>>>>>>>>>>>> halt state.
And there is no way for HHH to correctly simulate >>>>>>>>>>>>>>>>>>>>>> its input and return an answer
You insistence that a non-terminating input be >>>>>>>>>>>>>>>>>>>>> simulated
until non-existent completion is especially nuts >>>>>>>>>>>>>>>>>>>>> because
you have been told about this dozens of times. >>>>>>>>>>>>>>>>>>>>>
What the F is wrong with you?
It seems you don't understand those words. >>>>>>>>>>>>>>>>>>>>
I don't say that the decider needs to simulate the >>>>>>>>>>>>>>>>>>>> input to completion, but that it needs to be able to >>>>>>>>>>>>>>>>>>>> actually PROVE that if this exact input WAS given to >>>>>>>>>>>>>>>>>>>> a correct simultor (which won't be itself, since it >>>>>>>>>>>>>>>>>>>> isn't doing the complete simulation) will run for an >>>>>>>>>>>>>>>>>>>> unbounded number of steps.
No decider is ever allowed to report on anything >>>>>>>>>>>>>>>>>>> besides the actual behavior that its input actually >>>>>>>>>>>>>>>>>>> specifies.
Unless you can quote some respectable author your >>>>>>>>>>>>>>>>>> prohibitions are
meaningless.
To people that never had any actual understanding and >>>>>>>>>>>>>>>>> can only parrot textbooks. They need to see this things >>>>>>>>>>>>>>>>> in other textbooks.
People who can parrot textbooks know better than people >>>>>>>>>>>>>>>> who cannot.
That you can't when you should shows that you can't even >>>>>>>>>>>>>>>> parrot
textbooks.
I just reverse-engineer what the truth actually is. >>>>>>>>>>>>>>> *From the bottom of page 319 has been adapted to this* >>>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf >>>>>>>>>>>>>>>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ >>>>>>>>>>>>>>>     ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches >>>>>>>>>>>>>>>     its simulated final halt state of ⟨Ĥ.qn⟩ >>>>>>>>>>>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>     ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
    reach its simulated final halt state of ⟨Ĥ.qn⟩ >>>>>>>>>>>>>>
and two nmain clauses but they are not linked to a sentence. >>>>>>>>>>>>>> Whithout a sentence nothing is said.
The reason that I gave you a link to the whole
original proof is so that you could see how it
makes sense. Maybe the original proof doesn't
make sense to you either?
I'm not talking about any proof, I'm talking about your >>>>>>>>>>>> words and
symbols quored above. What is written in the book does make >>>>>>>>>>>> sense.
In particular, clauses are meaningfully linked to sentences. >>>>>>>>>>>> Perhaps the presentation could be clearer but it is intended >>>>>>>>>>>> for
students that already know and understand the earlier parts >>>>>>>>>>>> of the
book.
Linz tried to make two blocks of code into
English sentences.
The "blocks of code" are main clauses. They use abrevations >>>>>>>>>>>> because those
are easier to read than a full natural language sentence. >>>>>>>>>>>> There are other
clauses so that all clauses together form a sentence. In >>>>>>>>>>>> particuralr, ther
is an "and" between them. The sentence is not a truth
bearer. Instead it
expresses a desire.
If you want to say something you should learn to construct >>>>>>>>>>>> meaningful
sentences.
That you cannot understand what I say
A false calim aobut another persion is a sin even when presented >>>>>>>>>> as a subordiante clause.
That you cannot understand that you do not understand
what I say is not you understanding what I say.
Nevertheless a false claim about another prestion is a sin.
When you prove that you don't understand something and
I claim that you don't understand this then my statement
is factually correct.
What I understand or not is not important eonough to lie about or
even
mention.
You have proven do not understand some of these things.
It is true that your presentation does not make ehough sense that there >>>> could be something to be understood. But in that case it is sufficient >>>> that I understand that you said nothing and can point out that to those >>>> readers how may fail to notice.
And some of my readers have ADHD so badly that when
I correct their mistakes hundreds of times they never
notice any of the words of any of those corrections.
So have you. When your mistakes are corrected hundreds of times
you neve notice any of the words of any of those corrections.
Whenever I have non-existent mistakes "corrected"
by the misconceptions of others, these still remain
the misconceptions of others.
On 7/15/2025 4:15 AM, Mikko wrote:
On 2025-07-14 13:19:15 +0000, olcott said:
On 7/14/2025 3:54 AM, Mikko wrote:
On 2025-07-13 15:18:01 +0000, olcott said:
On 7/13/2025 2:09 AM, Mikko wrote:
On 2025-07-12 14:26:09 +0000, olcott said:
On 7/12/2025 3:00 AM, Mikko wrote:
On 2025-07-11 15:25:29 +0000, olcott said:
On 7/11/2025 3:40 AM, Mikko wrote:
On 2025-07-10 14:35:11 +0000, olcott said:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping >>>>>>>>>>>>> from their actual inputs. This entails that they never >>>>>>>>>>>>> compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
Proofs don't understand. They prove.
It fails to prove undecidability when the decider
correctly excludes directly executed Turing machines
from its domain.
That does not change the last sentence of the proof. Therefore the >>>>>>>> proof proves what it would prove anyway.
It completely invalidates the proof.
No, it does not. The proof reamins as it was. A proof is valid if there >>>>>> is no error in the proof. Nothing else is relevant.
There are errors that you do not understand.
For the purpose of these discussion it is not neessary to understand
your errors beyond that they are errors.
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
*There are errors with the proof*
You make errors with proofs. But the uncomputability of halting can be
(and has been) proven without errors.
That the errors have never been noticed before
IS NOT THE SAME AS THERE ARE NO ERRORS.
On 7/15/2025 4:15 AM, Mikko wrote:
On 2025-07-14 13:19:15 +0000, olcott said:
On 7/14/2025 3:54 AM, Mikko wrote:
On 2025-07-13 15:18:01 +0000, olcott said:
On 7/13/2025 2:09 AM, Mikko wrote:
On 2025-07-12 14:26:09 +0000, olcott said:
On 7/12/2025 3:00 AM, Mikko wrote:
On 2025-07-11 15:25:29 +0000, olcott said:
On 7/11/2025 3:40 AM, Mikko wrote:
On 2025-07-10 14:35:11 +0000, olcott said:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping >>>>>>>>>>>>> from their actual inputs. This entails that they never >>>>>>>>>>>>> compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*The Linz proof does not understand this*
Proofs don't understand. They prove.
It fails to prove undecidability when the decider
correctly excludes directly executed Turing machines
from its domain.
That does not change the last sentence of the proof. Therefore the >>>>>>>> proof proves what it would prove anyway.
It completely invalidates the proof.
No, it does not. The proof reamins as it was. A proof is valid if
there
is no error in the proof. Nothing else is relevant.
There are errors that you do not understand.
For the purpose of these discussion it is not neessary to understand
your errors beyond that they are errors.
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
*There are errors with the proof*
You make errors with proofs. But the uncomputability of halting can be
(and has been) proven without errors.
That the errors have never been noticed before
IS NOT THE SAME AS THERE ARE NO ERRORS.
If there were an error in some
proof you would quote the first sentence of the proof that is false or
does not follow from earlier senteces.
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
The official "received view" answer for HHH(DD) is
no one has any idea what value HHH can correctly
return. *This is the first error in the proof*
The second error is that the proofs require a
Turing machine decider to report on the behavior
of the direct execution of another Turing machine
even though directly executed Turing machines
cannot possibly be inputs to any TM decider.
On 7/16/2025 3:05 AM, Fred. Zwarts wrote:
Op 15.jul.2025 om 14:31 schreef olcott:Show how DDD emulated by HHH
On 7/15/2025 5:10 AM, Fred. Zwarts wrote:
Op 14.jul.2025 om 15:25 schreef olcott:
On 7/14/2025 4:19 AM, Fred. Zwarts wrote:
Op 13.jul.2025 om 17:38 schreef olcott:
On 7/13/2025 1:09 AM, Fred. Zwarts wrote:
Op 12.jul.2025 om 17:21 schreef olcott:
On 7/12/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:05 schreef olcott:
On 7/11/2025 3:52 AM, Fred. Zwarts wrote:So, aborting the simulation when the machine has not yet
Op 10.jul.2025 om 16:35 schreef olcott:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping >>>>>>>>>>>>>>> from their actual inputs. This entails that they never >>>>>>>>>>>>>>> compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this* >>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf >>>>>>>>>>>>>
*The Linz proof does not understand this*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ >>>>>>>>>>>>>   *if Ĥ applied to ⟨Ĥ⟩ halts, and*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>   *if Ĥ applied to ⟨Ĥ⟩ does not halt*
*It is common knowledge in the theory of computation* >>>>>>>>>>>>>
The evidence is that the input includes the code to >>>>>>>>>>>>>>>> abort and halt,
abort and stop running
*IS NOT THE SAME THING AS*
abort and halt
Another claim without evidence.
Another claim without evidence.
*Your lack of knowledge of computer science is not a rebuttal* >>>>>>>>>>>
Look at the definition of a Turing Machine (e.g., the one >>>>>>>>>>> here). The machine has states. Each state can be final or >>>>>>>>>>> non- final. If the machine's state is non-final, in the next >>>>>>>>>>> step the machine "does" something, namely, it can write
something on the tape, move its head, and/or change its state >>>>>>>>>>> to a different state. This is how the machine makes a progress. >>>>>>>>>>
reached its final state, is a violation of the Turing Machine. >>>>>>>>>>
void DDD()
{
  HHH(DDD);
  return;
}
So you don't understand that DDD simulated by
pure simulator HHH keeps repeating its first
line forever?
Irrelevant, because that is not what HHH does.
void DDD()
{
  HHH(DDD);
  return;
}
I stipulated this HHH <is> a pure simulator temporarily
overriding and superseding everything else that I ever
said about HHH.
You can stipulate that, but is irrelevant for the HHH you
published in Halt7.c. *That* HHH is not a pure simulator. The fact >>>>>> that a pure simulator fails is no proof for the correctness of the >>>>>> non- pure simulator.
Dreaming of other simulators with other behaviour does not change
the factual behaviour of the HHH we are discussing.
void RRR()
{
  SSS(RRR);
  return;
}
When RRR is simulated by pure simulator SSS
RRR simulated by SSS never reaches its own
"return" statement.
You have been corrected on this many times, but you seem unable to
understand it.
We are discussing a non-pure simulator, so the behaviour of a pure
simulator is irrelevant.
When we adapt SSS so that it only simulates
N instructions of RRR then no RRR ever reaches
its own "return" statement.
Now there is a final halt state, but SSS is unable to reach it. This
illustrates that simulation is not the right tool for this input to
analyse the behaviour, because it cannot see the full specification.
Other tools are needed, but each tool will fail for some inputs.
_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]
So when the actual behavior of the actual x86 code
disagrees with you you disagree with the x86 language.
And since it does not disagree with me,
(according to the semantics of the x86 language)
reaches its "ret" instruction final halt state.
Don't fucking change the subject to something else.
On 7/16/2025 3:55 AM, Mikko wrote:
On 2025-07-15 13:19:02 +0000, olcott said:
On 7/15/2025 4:15 AM, Mikko wrote:
On 2025-07-14 13:19:15 +0000, olcott said:
On 7/14/2025 3:54 AM, Mikko wrote:
On 2025-07-13 15:18:01 +0000, olcott said:
On 7/13/2025 2:09 AM, Mikko wrote:
On 2025-07-12 14:26:09 +0000, olcott said:
On 7/12/2025 3:00 AM, Mikko wrote:
On 2025-07-11 15:25:29 +0000, olcott said:
On 7/11/2025 3:40 AM, Mikko wrote:
On 2025-07-10 14:35:11 +0000, olcott said:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping >>>>>>>>>>>>>>> from their actual inputs. This entails that they never >>>>>>>>>>>>>>> compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this* >>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf >>>>>>>>>>>>>
*The Linz proof does not understand this*
Proofs don't understand. They prove.
It fails to prove undecidability when the decider
correctly excludes directly executed Turing machines
from its domain.
That does not change the last sentence of the proof. Therefore the >>>>>>>>>> proof proves what it would prove anyway.
It completely invalidates the proof.
No, it does not. The proof reamins as it was. A proof is valid if there
is no error in the proof. Nothing else is relevant.
There are errors that you do not understand.
For the purpose of these discussion it is not neessary to understand >>>>>> your errors beyond that they are errors.
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
*There are errors with the proof*
You make errors with proofs. But the uncomputability of halting can be >>>> (and has been) proven without errors.
That the errors have never been noticed before
IS NOT THE SAME AS THERE ARE NO ERRORS.
If there were an error in the proof you would quote the erronoeus inference.
The error is the requirement that a halt decider
reports on the direct execution of a machine that
is not an input.
On 7/15/2025 4:11 AM, Mikko wrote:
On 2025-07-14 13:08:16 +0000, olcott said:
On 7/14/2025 3:49 AM, Mikko wrote:
On 2025-07-13 15:17:22 +0000, olcott said:
On 7/13/2025 2:05 AM, Mikko wrote:
On 2025-07-12 14:34:05 +0000, olcott said:
On 7/12/2025 3:05 AM, Mikko wrote:
On 2025-07-11 15:22:32 +0000, olcott said:
On 7/11/2025 3:36 AM, Mikko wrote:
On 2025-07-10 14:26:24 +0000, olcott said:
On 7/10/2025 4:30 AM, Mikko wrote:
On 2025-07-09 12:25:59 +0000, olcott said:
On 7/9/2025 3:22 AM, Mikko wrote:
On 2025-07-08 14:21:47 +0000, olcott said:
On 7/8/2025 2:44 AM, Mikko wrote:The above does not make sense. There are one subordinate clause >>>>>>>>>>>>>> and two nmain clauses but they are not linked to a sentence. >>>>>>>>>>>>>> Whithout a sentence nothing is said.
On 2025-07-07 14:15:54 +0000, olcott said:
On 7/7/2025 3:37 AM, Mikko wrote:
On 2025-07-07 03:12:30 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 7/6/2025 9:09 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/6/25 4:06 PM, olcott wrote:
On 7/6/2025 12:00 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 7/6/25 11:19 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>
void DDD()No, it just isn't smart enough to detect that you lied in your premise.
{
  HHH(DDD);
  return;
}
*EVERY BOT FIGURES THIS OUT ON ITS OWN* >>>>>>>>>>>>>>>>>>>>>>
There is no way that DDD simulated by HHH (according >>>>>>>>>>>>>>>>>>>>>>> to the semantics of the C programming language) >>>>>>>>>>>>>>>>>>>>>>> can possibly reach its own "return" statement final >>>>>>>>>>>>>>>>>>>>>>> halt state.
And there is no way for HHH to correctly simulate its input and return
an answer
You insistence that a non-terminating input be simulated >>>>>>>>>>>>>>>>>>>>> until non-existent completion is especially nuts because >>>>>>>>>>>>>>>>>>>>> you have been told about this dozens of times. >>>>>>>>>>>>>>>>>>>>>
What the F is wrong with you?
It seems you don't understand those words. >>>>>>>>>>>>>>>>>>>>
I don't say that the decider needs to simulate the input to completion,
but that it needs to be able to actually PROVE that if this exact input
WAS given to a correct simultor (which won't be itself, since it isn't
doing the complete simulation) will run for an unbounded number of
steps.
No decider is ever allowed to report on anything >>>>>>>>>>>>>>>>>>> besides the actual behavior that its input actually >>>>>>>>>>>>>>>>>>> specifies.
Unless you can quote some respectable author your prohibitions are
meaningless.
To people that never had any actual understanding and >>>>>>>>>>>>>>>>> can only parrot textbooks. They need to see this things >>>>>>>>>>>>>>>>> in other textbooks.
People who can parrot textbooks know better than people who cannot.
That you can't when you should shows that you can't even parrot
textbooks.
I just reverse-engineer what the truth actually is. >>>>>>>>>>>>>>> *From the bottom of page 319 has been adapted to this* >>>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf >>>>>>>>>>>>>>>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ >>>>>>>>>>>>>>>     ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches >>>>>>>>>>>>>>>     its simulated final halt state of ⟨Ĥ.qn⟩ >>>>>>>>>>>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>     ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
    reach its simulated final halt state of ⟨Ĥ.qn⟩ >>>>>>>>>>>>>>
The reason that I gave you a link to the whole
original proof is so that you could see how it
makes sense. Maybe the original proof doesn't
make sense to you either?
I'm not talking about any proof, I'm talking about your words and >>>>>>>>>>>> symbols quored above. What is written in the book does make sense. >>>>>>>>>>>> In particular, clauses are meaningfully linked to sentences. >>>>>>>>>>>> Perhaps the presentation could be clearer but it is intended for >>>>>>>>>>>> students that already know and understand the earlier parts of the >>>>>>>>>>>> book.
Linz tried to make two blocks of code into
English sentences.
The "blocks of code" are main clauses. They use abrevations because those
are easier to read than a full natural language sentence. There are other
clauses so that all clauses together form a sentence. In particuralr, ther
is an "and" between them. The sentence is not a truth bearer. Instead it
expresses a desire.
If you want to say something you should learn to construct meaningful
sentences.
That you cannot understand what I say
A false calim aobut another persion is a sin even when presented >>>>>>>>>> as a subordiante clause.
That you cannot understand that you do not understand
what I say is not you understanding what I say.
Nevertheless a false claim about another prestion is a sin.
When you prove that you don't understand something and
I claim that you don't understand this then my statement
is factually correct.
What I understand or not is not important eonough to lie about or even >>>>>> mention.
You have proven do not understand some of these things.
It is true that your presentation does not make ehough sense that there >>>> could be something to be understood. But in that case it is sufficient >>>> that I understand that you said nothing and can point out that to those >>>> readers how may fail to notice.
And some of my readers have ADHD so badly that when
I correct their mistakes hundreds of times they never
notice any of the words of any of those corrections.
So have you. When your mistakes are corrected hundreds of times
you neve notice any of the words of any of those corrections.
Whenever I have non-existent mistakes "corrected"
by the misconceptions of others, these still remain
the misconceptions of others.
This goes around and around because when I explain
how these are misconceptions my explanations are
ignored.
When the misconceptions of others are claimed to be
my mistake these others cannot explain the details
of their misconceptions because they are incoherent.
It goes like this X makes a baseless claim that I am
wrong. I prove that X has no basis, then X makes the
baseless claim that I am wrong again.
Fred seems to think that he can get away with
disagreeing with the x86 language.
I tell him that he cannot and then he does it again.
On 7/16/2025 3:05 AM, Fred. Zwarts wrote:No rebuttal. I am not going to solve your problem, which has no
Op 15.jul.2025 om 14:31 schreef olcott:Show how DDD emulated by HHH
On 7/15/2025 5:10 AM, Fred. Zwarts wrote:
Op 14.jul.2025 om 15:25 schreef olcott:
On 7/14/2025 4:19 AM, Fred. Zwarts wrote:
Op 13.jul.2025 om 17:38 schreef olcott:
On 7/13/2025 1:09 AM, Fred. Zwarts wrote:
Op 12.jul.2025 om 17:21 schreef olcott:
On 7/12/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.jul.2025 om 23:05 schreef olcott:
On 7/11/2025 3:52 AM, Fred. Zwarts wrote:So, aborting the simulation when the machine has not yet
Op 10.jul.2025 om 16:35 schreef olcott:
On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
Op 09.jul.2025 om 15:02 schreef olcott:>
All Turing machine deciders only compute the mapping >>>>>>>>>>>>>>> from their actual inputs. This entails that they never >>>>>>>>>>>>>>> compute any mapping from non-inputs.
At least one thing you understand.
*From the bottom of page 319 has been adapted to this* >>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf >>>>>>>>>>>>>
*The Linz proof does not understand this*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ >>>>>>>>>>>>>   *if Ĥ applied to ⟨Ĥ⟩ halts, and*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>   *if Ĥ applied to ⟨Ĥ⟩ does not halt*
*It is common knowledge in the theory of computation* >>>>>>>>>>>>>
The evidence is that the input includes the code to >>>>>>>>>>>>>>>> abort and halt,
abort and stop running
*IS NOT THE SAME THING AS*
abort and halt
Another claim without evidence.
Another claim without evidence.
*Your lack of knowledge of computer science is not a rebuttal* >>>>>>>>>>>
Look at the definition of a Turing Machine (e.g., the one >>>>>>>>>>> here). The machine has states. Each state can be final or >>>>>>>>>>> non- final. If the machine's state is non-final, in the next >>>>>>>>>>> step the machine "does" something, namely, it can write
something on the tape, move its head, and/or change its state >>>>>>>>>>> to a different state. This is how the machine makes a progress. >>>>>>>>>>
reached its final state, is a violation of the Turing Machine. >>>>>>>>>>
void DDD()
{
  HHH(DDD);
  return;
}
So you don't understand that DDD simulated by
pure simulator HHH keeps repeating its first
line forever?
Irrelevant, because that is not what HHH does.
void DDD()
{
  HHH(DDD);
  return;
}
I stipulated this HHH <is> a pure simulator temporarily
overriding and superseding everything else that I ever
said about HHH.
You can stipulate that, but is irrelevant for the HHH you
published in Halt7.c. *That* HHH is not a pure simulator. The fact >>>>>> that a pure simulator fails is no proof for the correctness of the >>>>>> non- pure simulator.
Dreaming of other simulators with other behaviour does not change
the factual behaviour of the HHH we are discussing.
void RRR()
{
  SSS(RRR);
  return;
}
When RRR is simulated by pure simulator SSS
RRR simulated by SSS never reaches its own
"return" statement.
You have been corrected on this many times, but you seem unable to
understand it.
We are discussing a non-pure simulator, so the behaviour of a pure
simulator is irrelevant.
When we adapt SSS so that it only simulates
N instructions of RRR then no RRR ever reaches
its own "return" statement.
Now there is a final halt state, but SSS is unable to reach it. This
illustrates that simulation is not the right tool for this input to
analyse the behaviour, because it cannot see the full specification.
Other tools are needed, but each tool will fail for some inputs.
_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]
So when the actual behavior of the actual x86 code
disagrees with you you disagree with the x86 language.
And since it does not disagree with me,
(according to the semantics of the x86 language)
reaches its "ret" instruction final halt state.
On 7/17/2025 2:47 AM, Mikko wrote:
On 2025-07-16 15:15:53 +0000, olcott said:
On 7/16/2025 3:55 AM, Mikko wrote:
If there were an error in the proof you would quote the erronoeus
inference.
The error is the requirement that a halt decider
reports on the direct execution of a machine that
is not an input.
That was stimpluated before asking the question that the proof answers.
No Turing Machine decider can ever report on the
behavior of anything that is not an input encoded
as a finite string.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ is not a finite string input to Ĥ.embedded_H
⟨Ĥ⟩ ⟨Ĥ⟩ are finite string inputs to Ĥ.embedded_H
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
   ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
   its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
   ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
   reach its simulated final halt state of ⟨Ĥ.qn⟩.
When Ĥ is applied to ⟨Ĥ⟩ and embedded_H is a
simulating partial halt decider
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation until
embedded_H sees the repeating pattern and transitions to Ĥ.qn.
On 7/17/2025 2:47 AM, Mikko wrote:
On 2025-07-16 15:15:53 +0000, olcott said:
On 7/16/2025 3:55 AM, Mikko wrote:
If there were an error in the proof you would quote the erronoeus inference.
The error is the requirement that a halt decider
reports on the direct execution of a machine that
is not an input.
That was stimpluated before asking the question that the proof answers.
No Turing Machine decider can ever report on the
behavior of anything that is not an input encoded
as a finite string.
On 7/17/2025 3:01 AM, Mikko wrote:
On 2025-07-15 12:57:04 +0000, olcott said:
Whenever I have non-existent mistakes "corrected"
by the misconceptions of others, these still remain
the misconceptions of others.
You must correct your errors. Others identify your errors and may propose
correction but it is your choce to correct your presentation.
Unless you can point out the details of what you claim
to be my mistake I will not be able to correct your
misconception.
On 7/17/2025 3:20 AM, Fred. Zwarts wrote:
Op 16.jul.2025 om 17:34 schreef olcott:
On 7/16/2025 3:05 AM, Fred. Zwarts wrote:No rebuttal. I am not going to solve your problem, which has no
Op 15.jul.2025 om 14:31 schreef olcott:Show how DDD emulated by HHH
_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]
So when the actual behavior of the actual x86 code
disagrees with you you disagree with the x86 language.
And since it does not disagree with me,
(according to the semantics of the x86 language)
reaches its "ret" instruction final halt state.
solution. If you want a square circle, don't ask me to make it.
It is impossible for HHH to follow the semantics of the x86 language
up to the point of the final halt state.
The semantics of the x86 language makes it impossible for HHH to
correctly simulate itself up to its final halt state. You know that,
because I have told you that many times. There is a final halt state,
but HHH must fail to reach it.
Stop dreaming of finding a square circle.
Stop dreaming about HHH doing a correct simulation of itself. Face the
facts and think!
_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
I challenged you to point out a specific error and you
were unable to do this. I suspect that you do not know
what recursive emulation is.
On 7/18/2025 3:24 AM, Mikko wrote:
On 2025-07-17 13:34:40 +0000, olcott said:
On 7/17/2025 3:01 AM, Mikko wrote:
On 2025-07-15 12:57:04 +0000, olcott said:
Whenever I have non-existent mistakes "corrected"
by the misconceptions of others, these still remain
the misconceptions of others.
You must correct your errors. Others identify your errors and may
propose
correction but it is your choce to correct your presentation.
Unless you can point out the details of what you claim
to be my mistake I will not be able to correct your
misconception.
I and others have many times identified your errors and sometimes
Joes just pointed of the "error" that HHH does not
simulated itself simulating DDD after I conclusively
proves that HHH does simulate itself simulating DDD https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
proposed corrections. That you pretend never seeing or understanding
those error indications does not mean that they are not pointed out.
Counter-factual "corrections" are misconceptions.
But the primary pupose of pointing out your errors is not to inform
you. The primary purpose is to warn readers that your claim should
not be trusted.
On 7/18/2025 8:21 AM, Richard Damon wrote:
On 7/18/25 8:51 AM, olcott wrote:
On 7/18/2025 3:24 AM, Mikko wrote:
On 2025-07-17 13:34:40 +0000, olcott said:
On 7/17/2025 3:01 AM, Mikko wrote:
On 2025-07-15 12:57:04 +0000, olcott said:
Whenever I have non-existent mistakes "corrected"
by the misconceptions of others, these still remain
the misconceptions of others.
You must correct your errors. Others identify your errors and may
propose
correction but it is your choce to correct your presentation.
Unless you can point out the details of what you claim
to be my mistake I will not be able to correct your
misconception.
I and others have many times identified your errors and sometimes
Joes just pointed of the "error" that HHH does not
simulated itself simulating DDD after I conclusively
proves that HHH does simulate itself simulating DDD
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Except that this isn't actually the trace of simulation of HHH that
HHH does,
counter-factual
[00001606] address of HHHÂ Â Â Â Â Â Â Â Â Â ;
[000021d6] address of DDDÂ Â Â Â Â Â Â Â Â Â ;
[000021d9] address of DDD push DDDÂ ;
[000021de] address of DDD calls HHH ;
[000021f9] address of main push DDD ; page 34
[000021fe] address of main call HHH ; page 34
(1) HHH(DDD) is executed from main page 34
(2) HHH begins emulating DDD page 36
(3) Emulated DDD calls an emulated HHH page 40
(4) Emulated HHH begins page 42
(5) Emulated emulated DDD begins page 115
(6) Emulated emulated
   DDD calls another HHH(DDD) page 167
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On 7/18/2025 5:39 AM, Fred. Zwarts wrote:
Op 17.jul.2025 om 14:36 schreef olcott:
On 7/17/2025 3:20 AM, Fred. Zwarts wrote:
Op 16.jul.2025 om 17:34 schreef olcott:
On 7/16/2025 3:05 AM, Fred. Zwarts wrote:No rebuttal. I am not going to solve your problem, which has no
Op 15.jul.2025 om 14:31 schreef olcott:Show how DDD emulated by HHH
_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]
So when the actual behavior of the actual x86 code
disagrees with you you disagree with the x86 language.
And since it does not disagree with me,
(according to the semantics of the x86 language)
reaches its "ret" instruction final halt state.
solution. If you want a square circle, don't ask me to make it.
It is impossible for HHH to follow the semantics of the x86 language
up to the point of the final halt state.
The semantics of the x86 language makes it impossible for HHH to
correctly simulate itself up to its final halt state. You know that,
because I have told you that many times. There is a final halt
state, but HHH must fail to reach it.
Stop dreaming of finding a square circle.
Stop dreaming about HHH doing a correct simulation of itself. Face
the facts and think!
As usual no rebuttal, but repeated claims with no evidence.
_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 have been corrected on this many times. These 18 bytes cannot be
the full input, because the call at 0000219a refers to something
outside these 18 bytes. The real full input includes all functions
called directly or indirectly by DDD, including the HHH,of which we
know that it returns with a value 0. we see that a correct simulation
must continue at 0000219f with this value and reach the final halt
state at 000021a3. If, as we know, HHH fails to reach this final halt
state, it fails to do a correct simulation.
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.
Yes, no matter how many steps are simulated, each aborting HHH fails
to reach the final halt state and, therefore, fails to do a correct
simulation.
*No you fucking jackass that is not what I said*
Each element of the infinite set of functions
at machine address 000015d2 that emulates 0 to ∞
instructions of the above machine code
On 7/18/2025 3:28 AM, Mikko wrote:
On 2025-07-17 13:31:32 +0000, olcott said:
On 7/17/2025 2:47 AM, Mikko wrote:
On 2025-07-16 15:15:53 +0000, olcott said:No Turing Machine decider can ever report on the
On 7/16/2025 3:55 AM, Mikko wrote:
If there were an error in the proof you would quote the erronoeus
inference.
The error is the requirement that a halt decider
reports on the direct execution of a machine that
is not an input.
That was stimpluated before asking the question that the proof answers. >>>
behavior of anything that is not an input encoded
as a finite string.
Therefore one part of the halting problem is that the solution must
include encoding rules for the input. If the input string does not
contain some necessary information the encoding rules are incorrect
and the "solution" is not a solution. If no sufficient encoding rules
cannot be constructed then the problem has no solution.
*If you need more context read the rest of the proof* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
  if M applied to WM halts, and
q0 WM ⊢* Ĥq0 Wm WM ⊢* Ĥ y1 qn y2,
  if M applied to WM does not halt.
*From the bottom of page 319 has been adapted to this*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
 if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 if Ĥ applied to ⟨Ĥ⟩ does not halt.
Conventional notation of a Turing Machine: Ĥ
Conventional notation of a TM description: ⟨Ĥ⟩
⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H cannot possibly
reach its own simulated final halt state of ⟨Ĥ.qn⟩ https://claude.ai/share/5c251a20-4e76-457d-a624-3948f90cfbca
Every time that I have brought up the idea of recursive
simulation no one here has understood it.
void DDD()
{
 HHH(DDD);
 return;
}
(1) HHH(DDD) is executed
(2) HHH emulates DDD
(3) DDD calls an emulated HHH(DDD)
(4) emulated HHH emulates DDD
(5) this DDD calls HHH(DDD) again
*Here is the 197 page execution trace that proves that* https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On 7/18/2025 5:39 AM, Fred. Zwarts wrote:
Op 17.jul.2025 om 14:36 schreef olcott:
On 7/17/2025 3:20 AM, Fred. Zwarts wrote:
Op 16.jul.2025 om 17:34 schreef olcott:
On 7/16/2025 3:05 AM, Fred. Zwarts wrote:No rebuttal. I am not going to solve your problem, which has no
Op 15.jul.2025 om 14:31 schreef olcott:Show how DDD emulated by HHH
_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]
So when the actual behavior of the actual x86 code
disagrees with you you disagree with the x86 language.
And since it does not disagree with me,
(according to the semantics of the x86 language)
reaches its "ret" instruction final halt state.
solution. If you want a square circle, don't ask me to make it.
It is impossible for HHH to follow the semantics of the x86 language
up to the point of the final halt state.
The semantics of the x86 language makes it impossible for HHH to
correctly simulate itself up to its final halt state. You know that,
because I have told you that many times. There is a final halt
state, but HHH must fail to reach it.
Stop dreaming of finding a square circle.
Stop dreaming about HHH doing a correct simulation of itself. Face
the facts and think!
As usual no rebuttal, but repeated claims with no evidence.
_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 have been corrected on this many times. These 18 bytes cannot be
the full input, because the call at 0000219a refers to something
outside these 18 bytes. The real full input includes all functions
called directly or indirectly by DDD, including the HHH,of which we
know that it returns with a value 0. we see that a correct simulation
must continue at 0000219f with this value and reach the final halt
state at 000021a3. If, as we know, HHH fails to reach this final halt
state, it fails to do a correct simulation.
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.
Yes, no matter how many steps are simulated, each aborting HHH fails
to reach the final halt state and, therefore, fails to do a correct
simulation.
*No you fucking jackass that is not what I said*
Each element of the infinite set of functions
at machine address 000015d2 that emulates 0 to ∞
instructions of the above machine code
On 7/18/2025 3:28 AM, Mikko wrote:
On 2025-07-17 13:31:32 +0000, olcott said:
On 7/17/2025 2:47 AM, Mikko wrote:
On 2025-07-16 15:15:53 +0000, olcott said:No Turing Machine decider can ever report on the
On 7/16/2025 3:55 AM, Mikko wrote:
If there were an error in the proof you would quote the erronoeus inference.
The error is the requirement that a halt decider
reports on the direct execution of a machine that
is not an input.
That was stimpluated before asking the question that the proof answers. >>>
behavior of anything that is not an input encoded
as a finite string.
Therefore one part of the halting problem is that the solution must
include encoding rules for the input. If the input string does not
contain some necessary information the encoding rules are incorrect
and the "solution" is not a solution. If no sufficient encoding rules
cannot be constructed then the problem has no solution.
*If you need more context read the rest of the proof*
On 7/18/2025 3:24 AM, Mikko wrote:
On 2025-07-17 13:34:40 +0000, olcott said:
On 7/17/2025 3:01 AM, Mikko wrote:
On 2025-07-15 12:57:04 +0000, olcott said:
Whenever I have non-existent mistakes "corrected"
by the misconceptions of others, these still remain
the misconceptions of others.
You must correct your errors. Others identify your errors and may propose >>>> correction but it is your choce to correct your presentation.
Unless you can point out the details of what you claim
to be my mistake I will not be able to correct your
misconception.
I and others have many times identified your errors and sometimes
Joes just pointed of the "error" that HHH does not
simulated itself simulating DDD after I conclusively
proves that HHH does simulate itself simulating DDD https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
proposed corrections. That you pretend never seeing or understanding
those error indications does not mean that they are not pointed out.
Counter-factual "corrections" are misconceptions.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 166:57:42 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,529 |