On 5/31/2025 2:44 PM, Mr Flibble wrote:
Flibble's Argument: Execution vs Simulation in SHDsWe can't simply reject this as incorrect since it is the basis of every rebuttal of my work.
====================================================
In the context of Simulating Halt Deciders (SHDs), the distinction
between execution and simulation is fundamental.
Correct: External Simulation ----------------------------
int main() {
HHH(DDD); // SHD simulates/analyzes DDD from the outside.
}
- In this model, DDD is not being executed — it's being passed as data
to HHH, which is analyzing it.
- Even if DDD() (the function definition) contains a recursive call to
HHH(DDD), this is just part of the code being simulated, not something
that is actively executing.
- Thus, the simulation can detect infinite recursion structurally,
without running DDD.
Incorrect: Active Execution ---------------------------
int main() {
DDD(); // Directly executes DDD, which calls HHH(DDD) during
runtime.
}
It *is* incorrect to assume that the HHH that DDD calls is supposed to
report on the behavior of its caller.
- In this scenario, you’re actually running DDD, not simulating it.
- If DDD() calls HHH(DDD) at runtime, you're now mixing execution and
analysis in the same layer, violating the stratified model.
- This results in self-referential execution that undermines
decidability — a category error akin to the original halting paradox.
Key Insight -----------
As long as DDD is not executing and is only being simulated by HHH, it
doesn’t matter that DDD would call HHH(DDD) — because that call is
never actually made. It exists in the simulated model, not in the
runtime environment. Thus, structural recursion can be detected safely
and treated as non-halting without triggering a paradox.
This stratification (meta → base) is what keeps the model coherent.
A PhD computer scientist Eric Hehner has this same view. He explains
this view as the analyzer and the analyzed are in different programming languages where the input cannot directly call its analyzer.
I only very recently discovered that it is 100% impossible to actually
define *an input* that does the opposite of whatever value its analyzer returns.
In every conventional proof of the halting problem it has always been
that the decider cannot correctly report on the behavior of its caller.
You will find thousands of messages posted in this forum where everyone
says that I am wrong because HHH does not report on the behavior of the direct execution of DDD() (AKA its caller).
On 5/31/2025 3:30 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:10:39 -0500, olcott wrote:
On 5/31/2025 2:44 PM, Mr Flibble wrote:
Flibble's Argument: Execution vs Simulation in SHDsWe can't simply reject this as incorrect since it is the basis of
====================================================
In the context of Simulating Halt Deciders (SHDs), the distinction
between execution and simulation is fundamental.
Correct: External Simulation ----------------------------
int main() {
HHH(DDD); // SHD simulates/analyzes DDD from the outside.
}
- In this model, DDD is not being executed — it's being passed as
data to HHH, which is analyzing it.
- Even if DDD() (the function definition) contains a recursive call
to HHH(DDD), this is just part of the code being simulated, not
something that is actively executing.
- Thus, the simulation can detect infinite recursion structurally,
without running DDD.
Incorrect: Active Execution ---------------------------
int main() {
DDD(); // Directly executes DDD, which calls HHH(DDD) during
runtime.
}
every rebuttal of my work.
It *is* incorrect to assume that the HHH that DDD calls is supposed to
report on the behavior of its caller.
- In this scenario, you’re actually running DDD, not simulating it.
- If DDD() calls HHH(DDD) at runtime, you're now mixing execution and
analysis in the same layer, violating the stratified model.
- This results in self-referential execution that undermines
decidability — a category error akin to the original halting paradox. >>>>
Key Insight -----------
As long as DDD is not executing and is only being simulated by HHH,
it doesn’t matter that DDD would call HHH(DDD) — because that call is >>>> never actually made. It exists in the simulated model, not in the
runtime environment. Thus, structural recursion can be detected
safely and treated as non-halting without triggering a paradox.
This stratification (meta → base) is what keeps the model coherent.
A PhD computer scientist Eric Hehner has this same view. He explains
this view as the analyzer and the analyzed are in different
programming languages where the input cannot directly call its
analyzer.
I only very recently discovered that it is 100% impossible to actually
define *an input* that does the opposite of whatever value its
analyzer returns.
In every conventional proof of the halting problem it has always been
that the decider cannot correctly report on the behavior of its
caller.
You will find thousands of messages posted in this forum where
everyone says that I am wrong because HHH does not report on the
behavior of the direct execution of DDD() (AKA its caller).
You cannot both execute and simulate DDD as part of the same analysis,
if you do that then you are WRONG.
/Flibble
int main()
{
DDD(); // calls HHH(DDD) that simulates its own separate
} // instance of DDD. The analysis does not begin
// until after HHH(DDD) is called.
On 5/31/2025 3:43 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:40:15 -0500, olcott wrote:
On 5/31/2025 3:30 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:10:39 -0500, olcott wrote:
On 5/31/2025 2:44 PM, Mr Flibble wrote:
Flibble's Argument: Execution vs Simulation in SHDsWe can't simply reject this as incorrect since it is the basis of
====================================================
In the context of Simulating Halt Deciders (SHDs), the distinction >>>>>> between execution and simulation is fundamental.
Correct: External Simulation ----------------------------
int main() {
HHH(DDD); // SHD simulates/analyzes DDD from the outside.
}
- In this model, DDD is not being executed — it's being passed as >>>>>> data to HHH, which is analyzing it.
- Even if DDD() (the function definition) contains a recursive call >>>>>> to HHH(DDD), this is just part of the code being simulated, not
something that is actively executing.
- Thus, the simulation can detect infinite recursion structurally, >>>>>> without running DDD.
Incorrect: Active Execution ---------------------------
int main() {
DDD(); // Directly executes DDD, which calls HHH(DDD) during >>>>>> runtime.
}
every rebuttal of my work.
It *is* incorrect to assume that the HHH that DDD calls is supposed
to report on the behavior of its caller.
- In this scenario, you’re actually running DDD, not simulating it. >>>>>> - If DDD() calls HHH(DDD) at runtime, you're now mixing executionA PhD computer scientist Eric Hehner has this same view. He explains >>>>> this view as the analyzer and the analyzed are in different
and analysis in the same layer, violating the stratified model.
- This results in self-referential execution that undermines
decidability — a category error akin to the original halting
paradox.
Key Insight -----------
As long as DDD is not executing and is only being simulated by HHH, >>>>>> it doesn’t matter that DDD would call HHH(DDD) — because that call >>>>>> is never actually made. It exists in the simulated model, not in
the runtime environment. Thus, structural recursion can be detected >>>>>> safely and treated as non-halting without triggering a paradox.
This stratification (meta → base) is what keeps the model coherent. >>>>>
programming languages where the input cannot directly call its
analyzer.
I only very recently discovered that it is 100% impossible to
actually define *an input* that does the opposite of whatever value
its analyzer returns.
In every conventional proof of the halting problem it has always
been that the decider cannot correctly report on the behavior of its >>>>> caller.
You will find thousands of messages posted in this forum where
everyone says that I am wrong because HHH does not report on the
behavior of the direct execution of DDD() (AKA its caller).
You cannot both execute and simulate DDD as part of the same
analysis,
if you do that then you are WRONG.
/Flibble
int main()
{
DDD(); // calls HHH(DDD) that simulates its own separate
} // instance of DDD. The analysis does not begin
// until after HHH(DDD) is called.
That is a type violation (category error), i.e. WRONG. Simulation
analysis of DDD should involve no DIRECT execution of DDD WHATSOEVER.
/Flibble
I know that and you know that yet no one else here knows that.
On 5/31/2025 4:00 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:54:52 -0500, olcott wrote:
On 5/31/2025 3:43 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:40:15 -0500, olcott wrote:
On 5/31/2025 3:30 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:10:39 -0500, olcott wrote:
On 5/31/2025 2:44 PM, Mr Flibble wrote:
Flibble's Argument: Execution vs Simulation in SHDsWe can't simply reject this as incorrect since it is the basis of >>>>>>> every rebuttal of my work.
====================================================
In the context of Simulating Halt Deciders (SHDs), the
distinction between execution and simulation is fundamental.
Correct: External Simulation ----------------------------
int main() {
HHH(DDD); // SHD simulates/analyzes DDD from the outside. >>>>>>>> }
- In this model, DDD is not being executed — it's being passed as >>>>>>>> data to HHH, which is analyzing it.
- Even if DDD() (the function definition) contains a recursive >>>>>>>> call to HHH(DDD), this is just part of the code being simulated, >>>>>>>> not something that is actively executing.
- Thus, the simulation can detect infinite recursion
structurally, without running DDD.
Incorrect: Active Execution ---------------------------
int main() {
DDD(); // Directly executes DDD, which calls HHH(DDD)
during runtime.
}
It *is* incorrect to assume that the HHH that DDD calls is
supposed to report on the behavior of its caller.
- In this scenario, you’re actually running DDD, not simulating >>>>>>>> it. - If DDD() calls HHH(DDD) at runtime, you're now mixing
execution and analysis in the same layer, violating the
stratified model.
- This results in self-referential execution that undermines
decidability — a category error akin to the original halting >>>>>>>> paradox.
Key Insight -----------
As long as DDD is not executing and is only being simulated by >>>>>>>> HHH, it doesn’t matter that DDD would call HHH(DDD) — because >>>>>>>> that call is never actually made. It exists in the simulated
model, not in the runtime environment. Thus, structural recursion >>>>>>>> can be detected safely and treated as non-halting without
triggering a paradox.
This stratification (meta → base) is what keeps the model
coherent.
A PhD computer scientist Eric Hehner has this same view. He
explains this view as the analyzer and the analyzed are in
different programming languages where the input cannot directly
call its analyzer.
I only very recently discovered that it is 100% impossible to
actually define *an input* that does the opposite of whatever
value its analyzer returns.
In every conventional proof of the halting problem it has always >>>>>>> been that the decider cannot correctly report on the behavior of >>>>>>> its caller.
You will find thousands of messages posted in this forum where
everyone says that I am wrong because HHH does not report on the >>>>>>> behavior of the direct execution of DDD() (AKA its caller).
You cannot both execute and simulate DDD as part of the same
analysis,
if you do that then you are WRONG.
/Flibble
int main()
{
DDD(); // calls HHH(DDD) that simulates its own separate
} // instance of DDD. The analysis does not begin
// until after HHH(DDD) is called.
That is a type violation (category error), i.e. WRONG. Simulation
analysis of DDD should involve no DIRECT execution of DDD WHATSOEVER.
/Flibble
I know that and you know that yet no one else here knows that.
Stop lying, you don't know that at all: you are just wrong unless you
accept that what I am saying is correct and you have been wrong until I
told you how you were wrong.
/Flibble
You are much more correct than anyone else here besides me.
On 5/31/2025 4:30 PM, Mr Flibble wrote:
On Sat, 31 May 2025 16:27:07 -0500, olcott wrote:
On 5/31/2025 4:00 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:54:52 -0500, olcott wrote:
On 5/31/2025 3:43 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:40:15 -0500, olcott wrote:
On 5/31/2025 3:30 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:10:39 -0500, olcott wrote:
On 5/31/2025 2:44 PM, Mr Flibble wrote:
Flibble's Argument: Execution vs Simulation in SHDsWe can't simply reject this as incorrect since it is the basis >>>>>>>>> of every rebuttal of my work.
====================================================
In the context of Simulating Halt Deciders (SHDs), the
distinction between execution and simulation is fundamental. >>>>>>>>>>
Correct: External Simulation ----------------------------
int main() {
HHH(DDD); // SHD simulates/analyzes DDD from the
outside.
}
- In this model, DDD is not being executed — it's being passed >>>>>>>>>> as data to HHH, which is analyzing it.
- Even if DDD() (the function definition) contains a recursive >>>>>>>>>> call to HHH(DDD), this is just part of the code being
simulated, not something that is actively executing.
- Thus, the simulation can detect infinite recursion
structurally, without running DDD.
Incorrect: Active Execution ---------------------------
int main() {
DDD(); // Directly executes DDD, which calls HHH(DDD) >>>>>>>>>> during runtime.
}
It *is* incorrect to assume that the HHH that DDD calls is
supposed to report on the behavior of its caller.
- In this scenario, you’re actually running DDD, not simulating >>>>>>>>>> it. - If DDD() calls HHH(DDD) at runtime, you're now mixing >>>>>>>>>> execution and analysis in the same layer, violating the
stratified model.
- This results in self-referential execution that undermines >>>>>>>>>> decidability — a category error akin to the original halting >>>>>>>>>> paradox.
Key Insight -----------
As long as DDD is not executing and is only being simulated by >>>>>>>>>> HHH, it doesn’t matter that DDD would call HHH(DDD) — because >>>>>>>>>> that call is never actually made. It exists in the simulated >>>>>>>>>> model, not in the runtime environment. Thus, structural
recursion can be detected safely and treated as non-halting >>>>>>>>>> without triggering a paradox.
This stratification (meta → base) is what keeps the model >>>>>>>>>> coherent.
A PhD computer scientist Eric Hehner has this same view. He
explains this view as the analyzer and the analyzed are in
different programming languages where the input cannot directly >>>>>>>>> call its analyzer.
I only very recently discovered that it is 100% impossible to >>>>>>>>> actually define *an input* that does the opposite of whatever >>>>>>>>> value its analyzer returns.
In every conventional proof of the halting problem it has always >>>>>>>>> been that the decider cannot correctly report on the behavior of >>>>>>>>> its caller.
You will find thousands of messages posted in this forum where >>>>>>>>> everyone says that I am wrong because HHH does not report on the >>>>>>>>> behavior of the direct execution of DDD() (AKA its caller).
You cannot both execute and simulate DDD as part of the same
analysis,
if you do that then you are WRONG.
/Flibble
int main()
{
DDD(); // calls HHH(DDD) that simulates its own separate
} // instance of DDD. The analysis does not begin
// until after HHH(DDD) is called.
That is a type violation (category error), i.e. WRONG. Simulation >>>>>> analysis of DDD should involve no DIRECT execution of DDD
WHATSOEVER.
/Flibble
I know that and you know that yet no one else here knows that.
Stop lying, you don't know that at all: you are just wrong unless you
accept that what I am saying is correct and you have been wrong until
I told you how you were wrong.
/Flibble
You are much more correct than anyone else here besides me.
You are wrong unless you accept that you cannot simulate DDD if DDD is
already executing.
/Flibble
If you know object oriented programming then you understand the idea of distinct object instances.
There are three different instances of DDD when DDD() is directly
executed from main().
I have fully operational code that proves that the directly executed
DDD() invokes HHH(DDD) that does simulate its input.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
On 5/31/2025 4:30 PM, Mr Flibble wrote:
On Sat, 31 May 2025 16:27:07 -0500, olcott wrote:
On 5/31/2025 4:00 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:54:52 -0500, olcott wrote:
On 5/31/2025 3:43 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:40:15 -0500, olcott wrote:
On 5/31/2025 3:30 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:10:39 -0500, olcott wrote:
On 5/31/2025 2:44 PM, Mr Flibble wrote:
Flibble's Argument: Execution vs Simulation in SHDsWe can't simply reject this as incorrect since it is the basis >>>>>>>>> of every rebuttal of my work.
====================================================
In the context of Simulating Halt Deciders (SHDs), the
distinction between execution and simulation is fundamental. >>>>>>>>>>
Correct: External Simulation ----------------------------
int main() {
HHH(DDD); // SHD simulates/analyzes DDD from the
outside.
}
- In this model, DDD is not being executed — it's being passed >>>>>>>>>> as data to HHH, which is analyzing it.
- Even if DDD() (the function definition) contains a recursive >>>>>>>>>> call to HHH(DDD), this is just part of the code being
simulated, not something that is actively executing.
- Thus, the simulation can detect infinite recursion
structurally, without running DDD.
Incorrect: Active Execution ---------------------------
int main() {
DDD(); // Directly executes DDD, which calls HHH(DDD) >>>>>>>>>> during runtime.
}
It *is* incorrect to assume that the HHH that DDD calls is
supposed to report on the behavior of its caller.
- In this scenario, you’re actually running DDD, not simulating >>>>>>>>>> it. - If DDD() calls HHH(DDD) at runtime, you're now mixing >>>>>>>>>> execution and analysis in the same layer, violating the
stratified model.
- This results in self-referential execution that undermines >>>>>>>>>> decidability — a category error akin to the original halting >>>>>>>>>> paradox.
Key Insight -----------
As long as DDD is not executing and is only being simulated by >>>>>>>>>> HHH, it doesn’t matter that DDD would call HHH(DDD) — because >>>>>>>>>> that call is never actually made. It exists in the simulated >>>>>>>>>> model, not in the runtime environment. Thus, structural
recursion can be detected safely and treated as non-halting >>>>>>>>>> without triggering a paradox.
This stratification (meta → base) is what keeps the model >>>>>>>>>> coherent.
A PhD computer scientist Eric Hehner has this same view. He
explains this view as the analyzer and the analyzed are in
different programming languages where the input cannot directly >>>>>>>>> call its analyzer.
I only very recently discovered that it is 100% impossible to >>>>>>>>> actually define *an input* that does the opposite of whatever >>>>>>>>> value its analyzer returns.
In every conventional proof of the halting problem it has always >>>>>>>>> been that the decider cannot correctly report on the behavior of >>>>>>>>> its caller.
You will find thousands of messages posted in this forum where >>>>>>>>> everyone says that I am wrong because HHH does not report on the >>>>>>>>> behavior of the direct execution of DDD() (AKA its caller).
You cannot both execute and simulate DDD as part of the same
analysis,
if you do that then you are WRONG.
/Flibble
int main()
{
DDD(); // calls HHH(DDD) that simulates its own separate
} // instance of DDD. The analysis does not begin
// until after HHH(DDD) is called.
That is a type violation (category error), i.e. WRONG. Simulation >>>>>> analysis of DDD should involve no DIRECT execution of DDD
WHATSOEVER.
/Flibble
I know that and you know that yet no one else here knows that.
Stop lying, you don't know that at all: you are just wrong unless you
accept that what I am saying is correct and you have been wrong until
I told you how you were wrong.
/Flibble
You are much more correct than anyone else here besides me.
You are wrong unless you accept that you cannot simulate DDD if DDD is
already executing.
/Flibble
If you know object oriented programming then you understand the idea of distinct object instances.
There are three different instances of DDD when DDD() is directly
executed from main().
I have fully operational code that proves that the directly executed
DDD() invokes HHH(DDD) that does simulate its input.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
On 5/31/2025 4:45 PM, Mr Flibble wrote:
On Sat, 31 May 2025 16:38:41 -0500, olcott wrote:
On 5/31/2025 4:30 PM, Mr Flibble wrote:
On Sat, 31 May 2025 16:27:07 -0500, olcott wrote:
On 5/31/2025 4:00 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:54:52 -0500, olcott wrote:
On 5/31/2025 3:43 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:40:15 -0500, olcott wrote:
On 5/31/2025 3:30 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:10:39 -0500, olcott wrote:
On 5/31/2025 2:44 PM, Mr Flibble wrote:
Flibble's Argument: Execution vs Simulation in SHDsWe can't simply reject this as incorrect since it is the basis >>>>>>>>>>> of every rebuttal of my work.
====================================================
In the context of Simulating Halt Deciders (SHDs), the >>>>>>>>>>>> distinction between execution and simulation is fundamental. >>>>>>>>>>>>
Correct: External Simulation ---------------------------- >>>>>>>>>>>> int main() {
HHH(DDD); // SHD simulates/analyzes DDD from the >>>>>>>>>>>> outside.
}
- In this model, DDD is not being executed — it's being >>>>>>>>>>>> passed as data to HHH, which is analyzing it.
- Even if DDD() (the function definition) contains a
recursive call to HHH(DDD), this is just part of the code >>>>>>>>>>>> being simulated, not something that is actively executing. >>>>>>>>>>>> - Thus, the simulation can detect infinite recursion
structurally, without running DDD.
Incorrect: Active Execution --------------------------- >>>>>>>>>>>> int main() {
DDD(); // Directly executes DDD, which calls >>>>>>>>>>>> HHH(DDD)
during runtime.
}
It *is* incorrect to assume that the HHH that DDD calls is >>>>>>>>>>> supposed to report on the behavior of its caller.
- In this scenario, you’re actually running DDD, not >>>>>>>>>>>> simulating it. - If DDD() calls HHH(DDD) at runtime, you're >>>>>>>>>>>> now mixing execution and analysis in the same layer,
violating the stratified model.
- This results in self-referential execution that undermines >>>>>>>>>>>> decidability — a category error akin to the original halting >>>>>>>>>>>> paradox.
Key Insight -----------
As long as DDD is not executing and is only being simulated >>>>>>>>>>>> by HHH, it doesn’t matter that DDD would call HHH(DDD) — >>>>>>>>>>>> because that call is never actually made. It exists in the >>>>>>>>>>>> simulated model, not in the runtime environment. Thus, >>>>>>>>>>>> structural recursion can be detected safely and treated as >>>>>>>>>>>> non-halting without triggering a paradox.
This stratification (meta → base) is what keeps the model >>>>>>>>>>>> coherent.
A PhD computer scientist Eric Hehner has this same view. He >>>>>>>>>>> explains this view as the analyzer and the analyzed are in >>>>>>>>>>> different programming languages where the input cannot
directly call its analyzer.
I only very recently discovered that it is 100% impossible to >>>>>>>>>>> actually define *an input* that does the opposite of whatever >>>>>>>>>>> value its analyzer returns.
In every conventional proof of the halting problem it has >>>>>>>>>>> always been that the decider cannot correctly report on the >>>>>>>>>>> behavior of its caller.
You will find thousands of messages posted in this forum where >>>>>>>>>>> everyone says that I am wrong because HHH does not report on >>>>>>>>>>> the behavior of the direct execution of DDD() (AKA its
caller).
You cannot both execute and simulate DDD as part of the same >>>>>>>>>> analysis,
if you do that then you are WRONG.
/Flibble
int main()
{
DDD(); // calls HHH(DDD) that simulates its own separate >>>>>>>>> } // instance of DDD. The analysis does not begin
// until after HHH(DDD) is called.
That is a type violation (category error), i.e. WRONG.
Simulation analysis of DDD should involve no DIRECT execution of >>>>>>>> DDD WHATSOEVER.
/Flibble
I know that and you know that yet no one else here knows that.
Stop lying, you don't know that at all: you are just wrong unless
you accept that what I am saying is correct and you have been wrong >>>>>> until I told you how you were wrong.
/Flibble
You are much more correct than anyone else here besides me.
You are wrong unless you accept that you cannot simulate DDD if DDD
is already executing.
/Flibble
If you know object oriented programming then you understand the idea
of distinct object instances.
There are three different instances of DDD when DDD() is directly
executed from main().
I have fully operational code that proves that the directly executed
DDD() invokes HHH(DDD) that does simulate its input.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
The main() in that code does call HHH(DDD) not DDD() so what the fuck
are you talking about on Usenet?
/Flibble
I simplified that one so that people don't get confused.
main() usually has 30 function calls where 29 are commented out. Here is
the full execution trace of the directly executed DDD().
_DDD()
[00002177] 55 push ebp [00002178] 8bec mov
ebp,esp [0000217a] 6877210000 push 00002177 ; push DDD [0000217f] e853f4ffff call 000015d7 ; call HHH [00002184] 83c404
add esp,+04 [00002187] 5d pop ebp [00002188] c3
ret Size in bytes:(0018) [00002188]
_main()
[00002197] 55 push ebp [00002198] 8bec mov
ebp,esp [0000219a] e8d8ffffff call 00002177 ; call DDD [0000219f]
33c0 xor eax,eax [000021a1] 5d pop ebp
[000021a2] c3 ret Size in bytes:(0012) [000021a2]
machine stack stack machine assembly address address
data code language ======== ======== ======== =========
=============
[00002197][001037e9][00000000] 55 push ebp [00002198][001037e9][00000000] 8bec mov ebp,esp [0000219a][001037e5][0000219f] e8d8ffffff call 00002177 ; call DDD [00002177][001037e1][001037e9] 55 push ebp [00002178][001037e1][001037e9] 8bec mov ebp,esp [0000217a][001037dd][00002177] 6877210000 push 00002177 ; push DDD [0000217f][001037d9][00002184] e853f4ffff call 000015d7 ; call HHH
// executed HHH emulates 1st instance of DDD New slave_stack at:10388d
Begin Local Halt Decider Simulation Execution Trace Stored at:113895 [00002177][00113885][00113889] 55 push ebp [00002178][00113885][00113889] 8bec mov ebp,esp [0000217a][00113881][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0011387d][00002184] e853f4ffff call 000015d7 ; call HHH
// emulated HHH emulates 2nd instance of DDD New slave_stack at:14e2b5 [00002177][0015e2ad][0015e2b1] 55 push ebp [00002178][0015e2ad][0015e2b1] 8bec mov ebp,esp [0000217a][0015e2a9][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0015e2a5][00002184] e853f4ffff call 000015d7 ; call HHH Local
Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002184][001037e1][001037e9] 83c404 add esp,+04 [00002187][001037e5][0000219f] 5d pop ebp [00002188][001037e9][00000000] c3 ret
[0000219f][001037e9][00000000] 33c0 xor eax,eax [000021a1][001037ed][00000018] 5d pop ebp [000021a2][001037f1][00000000] c3 ret Number of Instructions Executed(10071) == 150 Pages
On 5/31/2025 5:03 PM, Mr Flibble wrote:
On Sat, 31 May 2025 17:00:17 -0500, olcott wrote:
On 5/31/2025 4:45 PM, Mr Flibble wrote:
On Sat, 31 May 2025 16:38:41 -0500, olcott wrote:
On 5/31/2025 4:30 PM, Mr Flibble wrote:
On Sat, 31 May 2025 16:27:07 -0500, olcott wrote:
On 5/31/2025 4:00 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:54:52 -0500, olcott wrote:
On 5/31/2025 3:43 PM, Mr Flibble wrote:Stop lying, you don't know that at all: you are just wrong unless >>>>>>>> you accept that what I am saying is correct and you have been
On Sat, 31 May 2025 15:40:15 -0500, olcott wrote:
On 5/31/2025 3:30 PM, Mr Flibble wrote:
On Sat, 31 May 2025 15:10:39 -0500, olcott wrote:
On 5/31/2025 2:44 PM, Mr Flibble wrote:
Flibble's Argument: Execution vs Simulation in SHDs >>>>>>>>>>>>>> ==================================================== >>>>>>>>>>>>>>We can't simply reject this as incorrect since it is the >>>>>>>>>>>>> basis of every rebuttal of my work.
In the context of Simulating Halt Deciders (SHDs), the >>>>>>>>>>>>>> distinction between execution and simulation is
fundamental.
Correct: External Simulation ---------------------------- >>>>>>>>>>>>>> int main() {
HHH(DDD); // SHD simulates/analyzes DDD from the >>>>>>>>>>>>>> outside.
}
- In this model, DDD is not being executed — it's being >>>>>>>>>>>>>> passed as data to HHH, which is analyzing it.
- Even if DDD() (the function definition) contains a >>>>>>>>>>>>>> recursive call to HHH(DDD), this is just part of the code >>>>>>>>>>>>>> being simulated, not something that is actively executing. >>>>>>>>>>>>>> - Thus, the simulation can detect infinite recursion >>>>>>>>>>>>>> structurally, without running DDD.
Incorrect: Active Execution --------------------------- >>>>>>>>>>>>>> int main() {
DDD(); // Directly executes DDD, which calls >>>>>>>>>>>>>> HHH(DDD)
during runtime.
}
It *is* incorrect to assume that the HHH that DDD calls is >>>>>>>>>>>>> supposed to report on the behavior of its caller.
- In this scenario, you’re actually running DDD, not >>>>>>>>>>>>>> simulating it. - If DDD() calls HHH(DDD) at runtime, you're >>>>>>>>>>>>>> now mixing execution and analysis in the same layer, >>>>>>>>>>>>>> violating the stratified model.
- This results in self-referential execution that
undermines decidability — a category error akin to the >>>>>>>>>>>>>> original halting paradox.
Key Insight -----------
As long as DDD is not executing and is only being simulated >>>>>>>>>>>>>> by HHH, it doesn’t matter that DDD would call HHH(DDD) — >>>>>>>>>>>>>> because that call is never actually made. It exists in the >>>>>>>>>>>>>> simulated model, not in the runtime environment. Thus, >>>>>>>>>>>>>> structural recursion can be detected safely and treated as >>>>>>>>>>>>>> non-halting without triggering a paradox.
This stratification (meta → base) is what keeps the model >>>>>>>>>>>>>> coherent.
A PhD computer scientist Eric Hehner has this same view. He >>>>>>>>>>>>> explains this view as the analyzer and the analyzed are in >>>>>>>>>>>>> different programming languages where the input cannot >>>>>>>>>>>>> directly call its analyzer.
I only very recently discovered that it is 100% impossible >>>>>>>>>>>>> to actually define *an input* that does the opposite of >>>>>>>>>>>>> whatever value its analyzer returns.
In every conventional proof of the halting problem it has >>>>>>>>>>>>> always been that the decider cannot correctly report on the >>>>>>>>>>>>> behavior of its caller.
You will find thousands of messages posted in this forum >>>>>>>>>>>>> where everyone says that I am wrong because HHH does not >>>>>>>>>>>>> report on the behavior of the direct execution of DDD() (AKA >>>>>>>>>>>>> its caller).
You cannot both execute and simulate DDD as part of the same >>>>>>>>>>>> analysis,
if you do that then you are WRONG.
/Flibble
int main()
{
DDD(); // calls HHH(DDD) that simulates its own
separate
} // instance of DDD. The analysis does not begin >>>>>>>>>>> // until after HHH(DDD) is called.
That is a type violation (category error), i.e. WRONG.
Simulation analysis of DDD should involve no DIRECT execution >>>>>>>>>> of DDD WHATSOEVER.
/Flibble
I know that and you know that yet no one else here knows that. >>>>>>>>
wrong until I told you how you were wrong.
/Flibble
You are much more correct than anyone else here besides me.
You are wrong unless you accept that you cannot simulate DDD if DDD >>>>>> is already executing.
/Flibble
If you know object oriented programming then you understand the idea >>>>> of distinct object instances.
There are three different instances of DDD when DDD() is directly
executed from main().
I have fully operational code that proves that the directly executed >>>>> DDD() invokes HHH(DDD) that does simulate its input.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
The main() in that code does call HHH(DDD) not DDD() so what the fuck
are you talking about on Usenet?
/Flibble
I simplified that one so that people don't get confused.
main() usually has 30 function calls where 29 are commented out. Here
is the full execution trace of the directly executed DDD().
_DDD()
[00002177] 55 push ebp [00002178] 8bec mov
ebp,esp [0000217a] 6877210000 push 00002177 ; push DDD
[0000217f] e853f4ffff call 000015d7 ; call HHH [00002184] 83c404
add esp,+04 [00002187] 5d pop ebp [00002188] c3
ret Size in bytes:(0018) [00002188]
_main()
[00002197] 55 push ebp [00002198] 8bec mov
ebp,esp [0000219a] e8d8ffffff call 00002177 ; call DDD
[0000219f] 33c0 xor eax,eax [000021a1] 5d
pop ebp [000021a2] c3 ret Size in bytes:(0012)
[000021a2]
machine stack stack machine assembly address address
data code language ======== ======== ========
=========
=============
[00002197][001037e9][00000000] 55 push ebp
[00002198][001037e9][00000000] 8bec mov ebp,esp
[0000219a][001037e5][0000219f] e8d8ffffff call 00002177 ; call DDD
[00002177][001037e1][001037e9] 55 push ebp
[00002178][001037e1][001037e9] 8bec mov ebp,esp
[0000217a][001037dd][00002177] 6877210000 push 00002177 ; push DDD
[0000217f][001037d9][00002184] e853f4ffff call 000015d7 ; call HHH
// executed HHH emulates 1st instance of DDD New slave_stack at:10388d
Begin Local Halt Decider Simulation Execution Trace Stored at:113895
[00002177][00113885][00113889] 55 push ebp
[00002178][00113885][00113889] 8bec mov ebp,esp
[0000217a][00113881][00002177] 6877210000 push 00002177 ; push DDD
[0000217f][0011387d][00002184] e853f4ffff call 000015d7 ; call HHH
// emulated HHH emulates 2nd instance of DDD New slave_stack at:14e2b5
[00002177][0015e2ad][0015e2b1] 55 push ebp
[00002178][0015e2ad][0015e2b1] 8bec mov ebp,esp
[0000217a][0015e2a9][00002177] 6877210000 push 00002177 ; push DDD
[0000217f][0015e2a5][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002184][001037e1][001037e9] 83c404 add esp,+04
[00002187][001037e5][0000219f] 5d pop ebp
[00002188][001037e9][00000000] c3 ret
[0000219f][001037e9][00000000] 33c0 xor eax,eax
[000021a1][001037ed][00000018] 5d pop ebp
[000021a2][001037f1][00000000] c3 ret Number of Instructions
Executed(10071) == 150 Pages
Show the C code to which that assembly relates.
/Flibble
void DDD()
{
HHH(DDD);
return;
}
int main()
{
//DD();
DDD();
//Output("Input_Halts = ", HHH(main)); //Output("Input_Halts = ", HHH(Infinite_Loop)); //Output("Input_Halts = ",
HHH(Infinite_Recursion)); //Output("Input_Halts = ", D(D));
// Output("Input_Halts = ", HHH(Infinite_Recursion));
//Output("Input_Halts = ", HHH(Sipser_D)); //Output("Input_Halts = ", HHH(DDD)); //Output("Input_Halts = ", HHH(DD)); //Output("Input_Halts =
", HHH1(DDD)); //Output("Input_Halts = ", HHH1(DD));
return 0;
}
On 5/31/2025 2:44 PM, Mr Flibble wrote:
Flibble's Argument: Execution vs Simulation in SHDs
====================================================
In the context of Simulating Halt Deciders (SHDs), the distinction
between
execution and simulation is fundamental.
Correct: External Simulation
----------------------------
int main() {
HHH(DDD); // SHD simulates/analyzes DDD from the outside.
}
- In this model, DDD is not being executed — it's being passed as data to >> HHH, which is analyzing it.
- Even if DDD() (the function definition) contains a recursive call to
HHH(DDD), this is just part of the code being simulated, not something
that is actively executing.
- Thus, the simulation can detect infinite recursion structurally,
without
running DDD.
Incorrect: Active Execution
---------------------------
int main() {
DDD(); // Directly executes DDD, which calls HHH(DDD) during
runtime.
}
We can't simply reject this as incorrect since
it is the basis of every rebuttal of my work.
It *is* incorrect to assume that the HHH that DDD
calls is supposed to report on the behavior of its
caller.
- In this scenario, you’re actually running DDD, not simulating it.
- If DDD() calls HHH(DDD) at runtime, you're now mixing execution and
analysis in the same layer, violating the stratified model.
- This results in self-referential execution that undermines decidability
— a category error akin to the original halting paradox.
Key Insight
-----------
As long as DDD is not executing and is only being simulated by HHH, it
doesn’t matter that DDD would call HHH(DDD) — because that call is never >> actually made. It exists in the simulated model, not in the runtime
environment. Thus, structural recursion can be detected safely and
treated
as non-halting without triggering a paradox.
This stratification (meta → base) is what keeps the model coherent.
A PhD computer scientist Eric Hehner has this same view.
He explains this view as the analyzer and the analyzed
are in different programming languages where the input
cannot directly call its analyzer.
I only very recently discovered that it is 100% impossible
to actually define *an input* that does the opposite of
whatever value its analyzer returns.
In every conventional proof of the halting problem it
has always been that the decider cannot correctly report
on the behavior of its caller.
You will find thousands of messages posted in this
forum where everyone says that I am wrong because
HHH does not report on the behavior of the direct
execution of DDD() (AKA its caller).
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
On 2025-05-31 19:21:10 +0000, olcott said:You are the only one that has used the idea of 'reporting on the
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no execution >>> of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no
execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked
about. There is no requirement that a halt decider knows or can find
out whether it is called by the program about which is required to
report. Consequently, whether the computaton asked about calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
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*
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no
execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked
about. There is no requirement that a halt decider knows or can find
out whether it is called by the program about which is required to
report. Consequently, whether the computaton asked about calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
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*
On 6/2/2025 6:04 AM, Richard Damon wrote:
On 6/2/25 1:12 AM, olcott wrote:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no
execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked
about. There is no requirement that a halt decider knows or can find
out whether it is called by the program about which is required to
report. Consequently, whether the computaton asked about calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
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*
No, it specifies FINITE recursive simulation, as HHH is defined to be
a DECIDER, that must always return after finite time.
Unlike most people here I do understand that not
possibly reaching a final halt state *is* non-halting behavior.
Your world is just filled with contradictions and lies.
The problem is your words are just meaningless, as you admit you don't
use there actual meaning as terms-of-art.
Sorry, but you are just showing how stupid you are.
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no execution >>>> of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked
about. There is no requirement that a halt decider knows or can find
out whether it is called by the program about which is required to
report. Consequently, whether the computaton asked about calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
On 6/4/2025 2:39 AM, Mikko wrote:And a correct analysis of the code shows that this is only a finite
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no
execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked
about. There is no requirement that a halt decider knows or can find
out whether it is called by the program about which is required to
report. Consequently, whether the computaton asked about calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
HHH1(DDD) emulates DDD that calls HHH(DDD)
that emulates DDD that calls HHH(DDD)
that emulates DDD that calls HHH(DDD)
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no execution >>>>>> of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked
about. There is no requirement that a halt decider knows or can find
out whether it is called by the program about which is required to
report. Consequently, whether the computaton asked about calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
On 6/5/2025 2:21 AM, Fred. Zwarts wrote:
Op 04.jun.2025 om 17:00 schreef olcott:
On 6/4/2025 2:39 AM, Mikko wrote:And a correct analysis of the code shows that this is only a finite
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of >>>>>>>> conflation of the EXECUTION of DDD with the SIMULATION of DDD: to >>>>>>>> completely and correctly simulate/analyse DDD there must be no >>>>>>>> execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked >>>>>> about. There is no requirement that a halt decider knows or can find >>>>>> out whether it is called by the program about which is required to >>>>>> report. Consequently, whether the computaton asked about calls the >>>>>> decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
HHH1(DDD) emulates DDD that calls HHH(DDD)
that emulates DDD that calls HHH(DDD)
that emulates DDD that calls HHH(DDD)
recursion,
It does not matter how many times that HHH emulates DDD.
HHH could even perform a static analysis and determine
that DDD simulated by HHH cannot possibly reach its own
"return" instruction final halt state. DDD can be rejected
on this basis.
because the input for HHH includes the code of Halt7.c, where it
specified that the program aborts and halts.
That HHH does not see that specification does not change the
specification. It is childish to think that things that are not seen
do not exist, in particular when there are other ways to observe them.
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of >>>>>>>> conflation of the EXECUTION of DDD with the SIMULATION of DDD: to >>>>>>>> completely and correctly simulate/analyse DDD there must be no >>>>>>>> execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked >>>>>> about. There is no requirement that a halt decider knows or can find >>>>>> out whether it is called by the program about which is required to >>>>>> report. Consequently, whether the computaton asked about calls the >>>>>> decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant requirements
you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of >>>>>>>> conflation of the EXECUTION of DDD with the SIMULATION of DDD: to >>>>>>>> completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked >>>>>> about. There is no requirement that a halt decider knows or can find >>>>>> out whether it is called by the program about which is required to >>>>>> report. Consequently, whether the computaton asked about calls the >>>>>> decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant requirements
you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
On 6/5/2025 2:21 AM, Fred. Zwarts wrote:
Op 04.jun.2025 om 17:00 schreef olcott:
On 6/4/2025 2:39 AM, Mikko wrote:And a correct analysis of the code shows that this is only a finite
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of >>>>>>>> conflation of the EXECUTION of DDD with the SIMULATION of DDD: to >>>>>>>> completely and correctly simulate/analyse DDD there must be no >>>>>>>> execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked >>>>>> about. There is no requirement that a halt decider knows or can find >>>>>> out whether it is called by the program about which is required to >>>>>> report. Consequently, whether the computaton asked about calls the >>>>>> decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
HHH1(DDD) emulates DDD that calls HHH(DDD)
that emulates DDD that calls HHH(DDD)
that emulates DDD that calls HHH(DDD)
recursion,
It does not matter how many times that HHH emulates DDD.
HHH could even perform a static analysis and determine
that DDD simulated by HHH cannot possibly reach its own
"return" instruction final halt state. DDD can be rejected
on this basis.
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of >>>>>>>> conflation of the EXECUTION of DDD with the SIMULATION of DDD: to >>>>>>>> completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked >>>>>> about. There is no requirement that a halt decider knows or can find >>>>>> out whether it is called by the program about which is required to >>>>>> report. Consequently, whether the computaton asked about calls the >>>>>> decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant requirements
you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
On 6/6/2025 3:02 AM, Fred. Zwarts wrote:
Op 05.jun.2025 om 17:56 schreef olcott:
On 6/5/2025 2:21 AM, Fred. Zwarts wrote:That HHH cannot possibly do what it should do only demonstrates the
Op 04.jun.2025 om 17:00 schreef olcott:
On 6/4/2025 2:39 AM, Mikko wrote:And a correct analysis of the code shows that this is only a finite
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of >>>>>>>>>> conflation of the EXECUTION of DDD with the SIMULATION of DDD: to >>>>>>>>>> completely and correctly simulate/analyse DDD there must be no >>>>>>>>>> execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked >>>>>>>> about. There is no requirement that a halt decider knows or can >>>>>>>> find
out whether it is called by the program about which is required to >>>>>>>> report. Consequently, whether the computaton asked about calls the >>>>>>>> decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
HHH1(DDD) emulates DDD that calls HHH(DDD)
that emulates DDD that calls HHH(DDD)
that emulates DDD that calls HHH(DDD)
recursion,
It does not matter how many times that HHH emulates DDD.
HHH could even perform a static analysis and determine
that DDD simulated by HHH cannot possibly reach its own
"return" instruction final halt state. DDD can be rejected
on this basis.
failure of HHH. That HHH cannot see the whole specification of the
input does not change the specification. The input specifies an
aborting and halting program.
void DDD()
{
HHH(DDD);
return;
}
*DDD emulated by HHH does meet this spec*
<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
On 6/6/2025 3:51 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of >>>>>>>>>> conflation of the EXECUTION of DDD with the SIMULATION of DDD: to >>>>>>>>>> completely and correctly simulate/analyse DDD there must be no >>>>>>>>>> execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked >>>>>>>> about. There is no requirement that a halt decider knows or can >>>>>>>> find
out whether it is called by the program about which is required to >>>>>>>> report. Consequently, whether the computaton asked about calls the >>>>>>>> decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant requirements >>>> you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non halting" means. If it can be exectuted to its
final halt state it is a halting computation, and we know that it
can be because it has been.
We cannot simply ignore and thus give up on the case
where an input calls its own termination analyzer,
even if it is the historical precedent to give up.
void DDD()
{
HHH(DDD);
return;
}
int main()
{
DDD(); // The HHH(DDD) that DDD calls is not allowed
} // to report on the behavior of its caller
HHH(DDD) is, however, required to report on the behavior
that its input actually specifies.
DDD emulated by HHH according to the rules of the x86 language
is the only correct way to determine the actual behavior that
the input to HHH(DDD) actually specifies. This does include HHH
emulating itself emulating DDD.
*The input to HHH(DDD) specifies*
HHH emulates DDD that calls a simulated HHH(DDD)
that simulates DDD that calls a simulated HHH(DDD)
that simulates DDD that calls a simulated HHH(DDD)
that simulates DDD that calls a simulated HHH(DDD)
that simulates DDD that calls a simulated HHH(DDD)
that simulates DDD that calls a simulated HHH(DDD)...
On 6/6/2025 3:51 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of >>>>>>>>>> conflation of the EXECUTION of DDD with the SIMULATION of DDD: to >>>>>>>>>> completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked >>>>>>>> about. There is no requirement that a halt decider knows or can find >>>>>>>> out whether it is called by the program about which is required to >>>>>>>> report. Consequently, whether the computaton asked about calls the >>>>>>>> decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant requirements >>>> you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non halting" means. If it can be exectuted to its
final halt state it is a halting computation, and we know that it
can be because it has been.
We cannot simply ignore and
thus give up on
the case where an input calls its own termination analyzer,
even if it is the historical precedent to give up.
On 6/6/2025 2:58 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of >>>>>>>>>> conflation of the EXECUTION of DDD with the SIMULATION of DDD: to >>>>>>>>>> completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked >>>>>>>> about. There is no requirement that a halt decider knows or can find >>>>>>>> out whether it is called by the program about which is required to >>>>>>>> report. Consequently, whether the computaton asked about calls the >>>>>>>> decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant requirements >>>> you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non-halting" means. Anything said about "DDD emulated
by HHH" is irrelevant. Wikipedia says: "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." Your HHH(DDD) does not do that.
<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
On 6/7/2025 3:19 AM, Mikko wrote:
On 2025-06-06 17:15:10 +0000, olcott said:
On 6/6/2025 2:58 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the >>>>>>>>>>>> form of
conflation of the EXECUTION of DDD with the SIMULATION of >>>>>>>>>>>> DDD: to
completely and correctly simulate/analyse DDD there must be >>>>>>>>>>>> no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is >>>>>>>>>> asked
about. There is no requirement that a halt decider knows or >>>>>>>>>> can find
out whether it is called by the program about which is
required to
report. Consequently, whether the computaton asked about calls >>>>>>>>>> the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting >>>>>>>> behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant
requirements
you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non-halting" means. Anything said about "DDD emulated >>>> by HHH" is irrelevant. Wikipedia says: "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." Your HHH(DDD) does not do that.
<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
That is not a definition of the meaning of halting. That is a diagnostic
cirterion for a conclusion not shown in the partial quote above. SIpser
does not prove the validity of the criterion.
The above criterion measure is a self-evident truth.
In epistemology (theory of knowledge), a self-evident
proposition is a proposition that is known to be true
by understanding its meaning without proof... https://en.wikipedia.org/wiki/Self-evidence
On 6/7/2025 3:26 AM, Mikko wrote:
On 2025-06-06 16:33:23 +0000, olcott said:
On 6/6/2025 3:51 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the >>>>>>>>>>>> form of
conflation of the EXECUTION of DDD with the SIMULATION of >>>>>>>>>>>> DDD: to
completely and correctly simulate/analyse DDD there must be >>>>>>>>>>>> no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is >>>>>>>>>> asked
about. There is no requirement that a halt decider knows or >>>>>>>>>> can find
out whether it is called by the program about which is
required to
report. Consequently, whether the computaton asked about calls >>>>>>>>>> the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting >>>>>>>> behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant
requirements
you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non halting" means. If it can be exectuted to its
final halt state it is a halting computation, and we know that it
can be because it has been.
We cannot simply ignore and
Be specific: we cannot simply ignore the meaning of "non halting".
thus give up on
Ignoring is not the same as giving up. For example, you ignore
important relevant things but you don't give up.
the case where an input calls its own termination analyzer,
even if it is the historical precedent to give up.
The requirement for that case are the same as for any other case.
You may need to consider it separately if want to make your partial
decider to handle it.
void DDD()
{
HHH(DDD);
return;
}
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*
On 6/7/2025 3:19 AM, Mikko wrote:
On 2025-06-06 17:15:10 +0000, olcott said:
On 6/6/2025 2:58 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of >>>>>>>>>>>> conflation of the EXECUTION of DDD with the SIMULATION of DDD: to >>>>>>>>>>>> completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked >>>>>>>>>> about. There is no requirement that a halt decider knows or can find >>>>>>>>>> out whether it is called by the program about which is required to >>>>>>>>>> report. Consequently, whether the computaton asked about calls the >>>>>>>>>> decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting >>>>>>>> behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant requirements >>>>>> you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non-halting" means. Anything said about "DDD emulated >>>> by HHH" is irrelevant. Wikipedia says: "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." Your HHH(DDD) does not do that.
<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
That is not a definition of the meaning of halting. That is a diagnostic
cirterion for a conclusion not shown in the partial quote above. SIpser
does not prove the validity of the criterion.
The above criterion measure is a self-evident truth.
On 6/7/2025 3:26 AM, Mikko wrote:
On 2025-06-06 16:33:23 +0000, olcott said:
On 6/6/2025 3:51 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of >>>>>>>>>>>> conflation of the EXECUTION of DDD with the SIMULATION of DDD: to >>>>>>>>>>>> completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked >>>>>>>>>> about. There is no requirement that a halt decider knows or can find >>>>>>>>>> out whether it is called by the program about which is required to >>>>>>>>>> report. Consequently, whether the computaton asked about calls the >>>>>>>>>> decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting >>>>>>>> behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant requirements >>>>>> you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non halting" means. If it can be exectuted to its
final halt state it is a halting computation, and we know that it
can be because it has been.
We cannot simply ignore and
Be specific: we cannot simply ignore the meaning of "non halting".
thus give up on
Ignoring is not the same as giving up. For example, you ignore
important relevant things but you don't give up.
the case where an input calls its own termination analyzer,
even if it is the historical precedent to give up.
The requirement for that case are the same as for any other case.
You may need to consider it separately if want to make your partial
decider to handle it.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
On 6/8/2025 12:54 AM, Mikko wrote:
On 2025-06-07 13:53:53 +0000, olcott said:
On 6/7/2025 3:19 AM, Mikko wrote:
On 2025-06-06 17:15:10 +0000, olcott said:
On 6/6/2025 2:58 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If *simulating halt decider H correctly simulates its*
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the >>>>>>>>>>>>>> form of
conflation of the EXECUTION of DDD with the SIMULATION of >>>>>>>>>>>>>> DDD: to
completely and correctly simulate/analyse DDD there must >>>>>>>>>>>>>> be no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of >>>>>>>>>>>>> reviewers have pointed out that they believe that HHH >>>>>>>>>>>>> is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it >>>>>>>>>>>> is asked
about. There is no requirement that a halt decider knows or >>>>>>>>>>>> can find
out whether it is called by the program about which is >>>>>>>>>>>> required to
report. Consequently, whether the computaton asked about >>>>>>>>>>>> calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting >>>>>>>>>> behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant
requirements
you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non-halting" means. Anything said about "DDD
emulated
by HHH" is irrelevant. Wikipedia says: "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." Your HHH(DDD) does not do that. >>>>>
*input D until H correctly determines that its simulated D* >>>>> *would never stop running unless aborted* then
That is not a definition of the meaning of halting. That is a
diagnostic
cirterion for a conclusion not shown in the partial quote above. SIpser >>>> does not prove the validity of the criterion.
The above criterion measure is a self-evident truth.
So you don't disagree.
Here is another way of saying it.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
On 6/8/2025 12:54 AM, Mikko wrote:
On 2025-06-07 13:53:53 +0000, olcott said:
On 6/7/2025 3:19 AM, Mikko wrote:
On 2025-06-06 17:15:10 +0000, olcott said:
On 6/6/2025 2:58 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If *simulating halt decider H correctly simulates its*
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of >>>>>>>>>>>>> reviewers have pointed out that they believe that HHH >>>>>>>>>>>>> is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked
about. There is no requirement that a halt decider knows or can find
out whether it is called by the program about which is required to >>>>>>>>>>>> report. Consequently, whether the computaton asked about calls the >>>>>>>>>>>> decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting >>>>>>>>>> behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant requirements
you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non-halting" means. Anything said about "DDD emulated >>>>>> by HHH" is irrelevant. Wikipedia says: "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." Your HHH(DDD) does not do that. >>>>>
*input D until H correctly determines that its simulated D* >>>>> *would never stop running unless aborted* then
That is not a definition of the meaning of halting. That is a diagnostic >>>> cirterion for a conclusion not shown in the partial quote above. SIpser >>>> does not prove the validity of the criterion.
The above criterion measure is a self-evident truth.
So you don't disagree.
Here is another way of saying it.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
On 6/10/2025 2:07 AM, Mikko wrote:
On 2025-06-08 06:04:45 +0000, olcott said:
On 6/8/2025 12:54 AM, Mikko wrote:
On 2025-06-07 13:53:53 +0000, olcott said:
On 6/7/2025 3:19 AM, Mikko wrote:
On 2025-06-06 17:15:10 +0000, olcott said:
On 6/6/2025 2:58 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:A halt decider is required to report on the computation it >>>>>>>>>>>>>> is asked
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in >>>>>>>>>>>>>>>> the form of
conflation of the EXECUTION of DDD with the SIMULATION >>>>>>>>>>>>>>>> of DDD: to
completely and correctly simulate/analyse DDD there must >>>>>>>>>>>>>>>> be no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of >>>>>>>>>>>>>>> reviewers have pointed out that they believe that HHH >>>>>>>>>>>>>>> is supposed to report on the behavior of its caller. >>>>>>>>>>>>>>
about. There is no requirement that a halt decider knows >>>>>>>>>>>>>> or can find
out whether it is called by the program about which is >>>>>>>>>>>>>> required to
report. Consequently, whether the computaton asked about >>>>>>>>>>>>>> calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>> specifies recursive simulation that can never reach its >>>>>>>>>>>>> *simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a >>>>>>>>>>>> halting
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant >>>>>>>>>> requirements
you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non-halting" means. Anything said about "DDD >>>>>>>> emulated
by HHH" is irrelevant. Wikipedia says: "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." Your HHH(DDD) does not do >>>>>>>> that.
<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
That is not a definition of the meaning of halting. That is a
diagnostic
It is one definition of non-halting in that
it logically entails never reaching the
simulated "return" statement final halt state.
On 6/11/2025 8:04 AM, Fred. Zwarts wrote:
Op 10.jun.2025 om 18:49 schreef olcott:
On 6/10/2025 2:07 AM, Mikko wrote:It is an incorrect definition,
On 2025-06-08 06:04:45 +0000, olcott said:
On 6/8/2025 12:54 AM, Mikko wrote:
On 2025-06-07 13:53:53 +0000, olcott said:
On 6/7/2025 3:19 AM, Mikko wrote:
On 2025-06-06 17:15:10 +0000, olcott said:
On 6/6/2025 2:58 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:If it does then the "input" is not DDD, which specifies a >>>>>>>>>>>>>> halting
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:A halt decider is required to report on the computation >>>>>>>>>>>>>>>> it is asked
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in >>>>>>>>>>>>>>>>>> the form of
conflation of the EXECUTION of DDD with the SIMULATION >>>>>>>>>>>>>>>>>> of DDD: to
completely and correctly simulate/analyse DDD there >>>>>>>>>>>>>>>>>> must be no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of >>>>>>>>>>>>>>>>> reviewers have pointed out that they believe that HHH >>>>>>>>>>>>>>>>> is supposed to report on the behavior of its caller. >>>>>>>>>>>>>>>>
about. There is no requirement that a halt decider knows >>>>>>>>>>>>>>>> or can find
out whether it is called by the program about which is >>>>>>>>>>>>>>>> required to
report. Consequently, whether the computaton asked about >>>>>>>>>>>>>>>> calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>> specifies recursive simulation that can never reach its >>>>>>>>>>>>>>> *simulated "return" instruction final halt state* >>>>>>>>>>>>>>
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant >>>>>>>>>>>> requirements
you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non-halting" means. Anything said about "DDD >>>>>>>>>> emulated
by HHH" is irrelevant. Wikipedia says: "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." Your HHH(DDD) does not >>>>>>>>>> do that.
<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
That is not a definition of the meaning of halting. That is a
diagnostic
It is one definition of non-halting in that
it logically entails never reaching the
simulated "return" statement final halt state.
It *is* the industry standard definition.
That you are too stupid to know this is not an actual rebuttal.
On 6/11/2025 8:04 AM, Fred. Zwarts wrote:
Op 10.jun.2025 om 18:49 schreef olcott:
On 6/10/2025 2:07 AM, Mikko wrote:It is an incorrect definition,
On 2025-06-08 06:04:45 +0000, olcott said:
On 6/8/2025 12:54 AM, Mikko wrote:
On 2025-06-07 13:53:53 +0000, olcott said:
On 6/7/2025 3:19 AM, Mikko wrote:
On 2025-06-06 17:15:10 +0000, olcott said:
On 6/6/2025 2:58 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:If it does then the "input" is not DDD, which specifies a >>>>>>>>>>>>>> halting
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:A halt decider is required to report on the computation >>>>>>>>>>>>>>>> it is asked
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in >>>>>>>>>>>>>>>>>> the form of
conflation of the EXECUTION of DDD with the SIMULATION >>>>>>>>>>>>>>>>>> of DDD: to
completely and correctly simulate/analyse DDD there >>>>>>>>>>>>>>>>>> must be no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of >>>>>>>>>>>>>>>>> reviewers have pointed out that they believe that HHH >>>>>>>>>>>>>>>>> is supposed to report on the behavior of its caller. >>>>>>>>>>>>>>>>
about. There is no requirement that a halt decider knows >>>>>>>>>>>>>>>> or can find
out whether it is called by the program about which is >>>>>>>>>>>>>>>> required to
report. Consequently, whether the computaton asked about >>>>>>>>>>>>>>>> calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>> specifies recursive simulation that can never reach its >>>>>>>>>>>>>>> *simulated "return" instruction final halt state* >>>>>>>>>>>>>>
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant >>>>>>>>>>>> requirements
you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non-halting" means. Anything said about "DDD >>>>>>>>>> emulated
by HHH" is irrelevant. Wikipedia says: "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." Your HHH(DDD) does not >>>>>>>>>> do that.
<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
That is not a definition of the meaning of halting. That is a
diagnostic
It is one definition of non-halting in that
it logically entails never reaching the
simulated "return" statement final halt state.
It *is* the industry standard definition.
That you are too stupid to know this is not an actual rebuttal.
On 6/10/2025 2:07 AM, Mikko wrote:
On 2025-06-08 06:04:45 +0000, olcott said:
On 6/8/2025 12:54 AM, Mikko wrote:
On 2025-06-07 13:53:53 +0000, olcott said:
On 6/7/2025 3:19 AM, Mikko wrote:
On 2025-06-06 17:15:10 +0000, olcott said:
On 6/6/2025 2:58 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>> If *simulating halt decider H correctly simulates its*
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:A halt decider is required to report on the computation it is asked
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of >>>>>>>>>>>>>>> reviewers have pointed out that they believe that HHH >>>>>>>>>>>>>>> is supposed to report on the behavior of its caller. >>>>>>>>>>>>>>
about. There is no requirement that a halt decider knows or can find
out whether it is called by the program about which is required to
report. Consequently, whether the computaton asked about calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>> specifies recursive simulation that can never reach its >>>>>>>>>>>>> *simulated "return" instruction final halt state*
If it does then the "input" is not DDD, which specifies a halting >>>>>>>>>>>> behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant requirements
you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non-halting" means. Anything said about "DDD emulated
by HHH" is irrelevant. Wikipedia says: "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." Your HHH(DDD) does not do that. >>>>>>>
*input D until H correctly determines that its simulated D* >>>>>>> *would never stop running unless aborted* then
That is not a definition of the meaning of halting. That is a diagnostic
It is one definition of non-halting in that
it logically entails never reaching the
simulated "return" statement final halt state.
On 6/11/2025 8:04 AM, Fred. Zwarts wrote:
Op 10.jun.2025 om 18:49 schreef olcott:
On 6/10/2025 2:07 AM, Mikko wrote:It is an incorrect definition,
On 2025-06-08 06:04:45 +0000, olcott said:
On 6/8/2025 12:54 AM, Mikko wrote:
On 2025-06-07 13:53:53 +0000, olcott said:
On 6/7/2025 3:19 AM, Mikko wrote:
On 2025-06-06 17:15:10 +0000, olcott said:
On 6/6/2025 2:58 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:If it does then the "input" is not DDD, which specifies a halting
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:A halt decider is required to report on the computation it is asked
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of >>>>>>>>>>>>>>>>> reviewers have pointed out that they believe that HHH >>>>>>>>>>>>>>>>> is supposed to report on the behavior of its caller. >>>>>>>>>>>>>>>>
about. There is no requirement that a halt decider knows or can find
out whether it is called by the program about which is required to
report. Consequently, whether the computaton asked about calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>> specifies recursive simulation that can never reach its >>>>>>>>>>>>>>> *simulated "return" instruction final halt state* >>>>>>>>>>>>>>
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant requirements
you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non-halting" means. Anything said about "DDD emulated
by HHH" is irrelevant. Wikipedia says: "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." Your HHH(DDD) does not do that.
<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
That is not a definition of the meaning of halting. That is a diagnostic
It is one definition of non-halting in that
it logically entails never reaching the
simulated "return" statement final halt state.
It *is* the industry standard definition.
On 6/13/2025 5:14 AM, Mikko wrote:
On 2025-06-11 13:59:00 +0000, olcott said:
On 6/11/2025 8:04 AM, Fred. Zwarts wrote:
Op 10.jun.2025 om 18:49 schreef olcott:
On 6/10/2025 2:07 AM, Mikko wrote:It is an incorrect definition,
On 2025-06-08 06:04:45 +0000, olcott said:
On 6/8/2025 12:54 AM, Mikko wrote:
On 2025-06-07 13:53:53 +0000, olcott said:
On 6/7/2025 3:19 AM, Mikko wrote:
On 2025-06-06 17:15:10 +0000, olcott said:
On 6/6/2025 2:58 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:If it does then the "input" is not DDD, which specifies >>>>>>>>>>>>>>>> a halting
On 2025-05-31 19:21:10 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 5/31/2025 2:11 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>> Olcott is doing this:A halt decider is required to report on the >>>>>>>>>>>>>>>>>> computation it is asked
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error >>>>>>>>>>>>>>>>>>>> in the form of
conflation of the EXECUTION of DDD with the >>>>>>>>>>>>>>>>>>>> SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there >>>>>>>>>>>>>>>>>>>> must be no execution
of DDD prior to the simulation of DDD. >>>>>>>>>>>>>>>>>>>>
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of >>>>>>>>>>>>>>>>>>> reviewers have pointed out that they believe that HHH >>>>>>>>>>>>>>>>>>> is supposed to report on the behavior of its caller. >>>>>>>>>>>>>>>>>>
about. There is no requirement that a halt decider >>>>>>>>>>>>>>>>>> knows or can find
out whether it is called by the program about which is >>>>>>>>>>>>>>>>>> required to
report. Consequently, whether the computaton asked >>>>>>>>>>>>>>>>>> about calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>>>> specifies recursive simulation that can never reach its >>>>>>>>>>>>>>>>> *simulated "return" instruction final halt state* >>>>>>>>>>>>>>>>
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant >>>>>>>>>>>>>> requirements
you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach >>>>>>>>>>>>> its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non-halting" means. Anything said about >>>>>>>>>>>> "DDD emulated
by HHH" is irrelevant. Wikipedia says: "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." Your HHH(DDD) does not >>>>>>>>>>>> do that.
<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
That is not a definition of the meaning of halting. That is a >>>>>>>>>> diagnostic
It is one definition of non-halting in that
it logically entails never reaching the
simulated "return" statement final halt state.
It *is* the industry standard definition.
There is no indusstry standard definition. Industry uses the common
language meaning that "non-halting" is what does not halt.
If you run an infinite loop on your computer
and then smash the computer with a sledge hammer
to make the infinite loop stop running,
THIS DOES NOT COUNT AS HALTING.
On 6/13/2025 5:14 AM, Mikko wrote:
On 2025-06-11 13:59:00 +0000, olcott said:
On 6/11/2025 8:04 AM, Fred. Zwarts wrote:
Op 10.jun.2025 om 18:49 schreef olcott:
On 6/10/2025 2:07 AM, Mikko wrote:It is an incorrect definition,
On 2025-06-08 06:04:45 +0000, olcott said:
On 6/8/2025 12:54 AM, Mikko wrote:
On 2025-06-07 13:53:53 +0000, olcott said:
On 6/7/2025 3:19 AM, Mikko wrote:
On 2025-06-06 17:15:10 +0000, olcott said:
On 6/6/2025 2:58 AM, Mikko wrote:
On 2025-06-05 16:01:46 +0000, olcott said:
On 6/5/2025 2:42 AM, Mikko wrote:
On 2025-06-04 15:00:07 +0000, olcott said:
On 6/4/2025 2:39 AM, Mikko wrote:
On 2025-06-02 05:12:26 +0000, olcott said:
On 6/1/2025 6:20 AM, Mikko wrote:If it does then the "input" is not DDD, which specifies a halting
On 2025-05-31 19:21:10 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 5/31/2025 2:11 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>> Olcott is doing this:A halt decider is required to report on the computation it is asked
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD. >>>>>>>>>>>>>>>>>>>>
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of >>>>>>>>>>>>>>>>>>> reviewers have pointed out that they believe that HHH >>>>>>>>>>>>>>>>>>> is supposed to report on the behavior of its caller. >>>>>>>>>>>>>>>>>>
about. There is no requirement that a halt decider knows or can find
out whether it is called by the program about which is required to
report. Consequently, whether the computaton asked about calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>>>> specifies recursive simulation that can never reach its >>>>>>>>>>>>>>>>> *simulated "return" instruction final halt state* >>>>>>>>>>>>>>>>
behaviour if HHH is a decider.
You can say these things only by making
sure to ignore the verified facts.
We can ignore irrelevant facts. But if you ignore relevant requirements
you can't prove that your soliution is correct.
As long as DDD emulated by HHH cannot possibly reach >>>>>>>>>>>>> its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.
That is not what "non-halting" means. Anything said about "DDD emulated
by HHH" is irrelevant. Wikipedia says: "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." Your HHH(DDD) does not do that.
<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
That is not a definition of the meaning of halting. That is a diagnostic
It is one definition of non-halting in that
it logically entails never reaching the
simulated "return" statement final halt state.
It *is* the industry standard definition.
There is no indusstry standard definition. Industry uses the common
language meaning that "non-halting" is what does not halt.
If you run an infinite loop on your computer
and then smash the computer with a sledge hammer
to make the infinite loop stop running,
THIS DOES NOT COUNT AS HALTING.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 498 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 70:19:05 |
| Calls: | 9,814 |
| Calls today: | 2 |
| Files: | 13,755 |
| Messages: | 6,189,494 |