Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/ publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping
from finite strings to behaviors. That people do not comprehend
this shows the shallowness of the depth of the learned-by-rote
(lack of) understanding.
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/ publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping
from finite strings to behaviors. That people do not comprehend
this shows the shallowness of the depth of the learned-by-rote
(lack of) understanding.
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/ publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping
from finite strings to behaviors.
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH.
This makes HHH necessarily correct to reject its input as
non-halting.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping
from finite strings to behaviors.
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
Yes, it demonstrates the incapability of HHH to correctly determine
the halting behaviour of DD
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
The finite string defines one behaviour. This finite string, when
given to an X86 processor shows halting behaviour. This finite
string,when given to a world class simulator, shows halting behaviour.
Only HHH fails to see this proven halting behaviour. So it proves the
failure of HHH.
HHH aborts the simulation on unsound grounds one cycle before the
simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping
from finite strings to behaviors.
Yes. And the behaviour of this finite string has been proven to show
halting behaviour. Only Olcott's HHH fails to see it.
His misunderstanding is that he thinks that the behaviour defined by
the finite string depends on the simulator.
When DD calls HHH(DD) in recursive simulation it is a
verified fact that DD cannot possibly halt.
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
Yes, it demonstrates the incapability of HHH to correctly determine
the halting behaviour of DD
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
The finite string defines one behaviour. This finite string, when
given to an X86 processor shows halting behaviour. This finite
string,when given to a world class simulator, shows halting behaviour.
Only HHH fails to see this proven halting behaviour. So it proves the
failure of HHH.
HHH aborts the simulation on unsound grounds one cycle before the
simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping
from finite strings to behaviors.
Yes. And the behaviour of this finite string has been proven to show
halting behaviour. Only Olcott's HHH fails to see it.
His misunderstanding is that he thinks that the behaviour defined by
the finite string depends on the simulator.
When DD calls HHH(DD) in recursive simulation it is a
verified fact that DD cannot possibly halt.
He fail to see that a finite string defines a behaviour independent of
the thing that runs or simulates it. It seems that he is incapable to
learn that a failure of a simulator does not define a behaviour.
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
Yes, it demonstrates the incapability of HHH to correctly determine
the halting behaviour of DD
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
The finite string defines one behaviour. This finite string, when
given to an X86 processor shows halting behaviour. This finite
string,when given to a world class simulator, shows halting
behaviour. Only HHH fails to see this proven halting behaviour. So
it proves the failure of HHH.
HHH aborts the simulation on unsound grounds one cycle before the
simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping
from finite strings to behaviors.
Yes. And the behaviour of this finite string has been proven to show
halting behaviour. Only Olcott's HHH fails to see it.
His misunderstanding is that he thinks that the behaviour defined by
the finite string depends on the simulator.
When DD calls HHH(DD) in recursive simulation it is a
verified fact that DD cannot possibly halt.
Which proves the failure of HHH. It does not reach the end of a
halting program. All other methods show that DD halts.
Your comment only proves that you lack sufficient
understanding of the C programming language.
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
Yes, it demonstrates the incapability of HHH to correctly determine the
halting behaviour of DD
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
The finite string defines one behaviour. This finite string, when given
to an X86 processor shows halting behaviour. This finite string,when
given to a world class simulator, shows halting behaviour. Only HHH
fails to see this proven halting behaviour. So it proves the failure of
HHH.
HHH aborts the simulation on unsound grounds one cycle before the
simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping
from finite strings to behaviors.
Yes. And the behaviour of this finite string has been proven to show
halting behaviour. Only Olcott's HHH fails to see it.
His misunderstanding is that he thinks that the behaviour defined by
the finite string depends on the simulator.
When DD calls HHH(DD) in recursive simulation it is a
verified fact that DD cannot possibly halt.
On 2/8/2025 4:25 AM, Mikko wrote:
On 2025-02-07 23:13:04 +0000, olcott said:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
Wrong, they understand that nothing below exludes the possibility that
HHH is a program that can correctly simulate DD to its "if" statement.
Show the execution trace of that.
The code of HHH might exlude that but that is not sohwn below.
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH.
No, it does not. DD as quoted below pecifies nothing about the behaviour
of HHH, only its argument types and return type.
Requires HHH to simulate itself simulating DD recursively.int Halt_Status = HHH(DD); // line 3 of DD
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
No, it has not. There is no DD there.
line 1354 through 1360
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
Yes, it demonstrates the incapability of HHH to correctly determine
the halting behaviour of DD
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
The finite string defines one behaviour. This finite string, when
given to an X86 processor shows halting behaviour. This finite
string,when given to a world class simulator, shows halting
behaviour. Only HHH fails to see this proven halting behaviour. So
it proves the failure of HHH.
HHH aborts the simulation on unsound grounds one cycle before the
simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping
from finite strings to behaviors.
Yes. And the behaviour of this finite string has been proven to show
halting behaviour. Only Olcott's HHH fails to see it.
His misunderstanding is that he thinks that the behaviour defined by
the finite string depends on the simulator.
When DD calls HHH(DD) in recursive simulation it is a
verified fact that DD cannot possibly halt.
Which proves the failure of HHH. It does not reach the end of a
halting program. All other methods show that DD halts.
Your comment only proves that you lack sufficient
understanding of the C programming language.
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
Yes, it demonstrates the incapability of HHH to correctly
determine the halting behaviour of DD
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
The finite string defines one behaviour. This finite string, when
given to an X86 processor shows halting behaviour. This finite
string,when given to a world class simulator, shows halting
behaviour. Only HHH fails to see this proven halting behaviour. So >>>>>> it proves the failure of HHH.
HHH aborts the simulation on unsound grounds one cycle before the
simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping
from finite strings to behaviors.
Yes. And the behaviour of this finite string has been proven to
show halting behaviour. Only Olcott's HHH fails to see it.
His misunderstanding is that he thinks that the behaviour defined
by the finite string depends on the simulator.
When DD calls HHH(DD) in recursive simulation it is a
verified fact that DD cannot possibly halt.
Which proves the failure of HHH. It does not reach the end of a
halting program. All other methods show that DD halts.
Your comment only proves that you lack sufficient
understanding of the C programming language.
This is a proof of lack of logical reasoning.
Verified fact 1: DD halts
Fallacy of equivocation error.
(a) All men are mortal
(b) No woman is a man
∴ No woman is mortal
∴ DD does not halt.
The input to HHH(DD) cannot possibly terminate normally.
Referring to some other DD does not change this verfied fact.
On 2/9/2025 4:08 AM, Mikko wrote:Yes, because HHH doesn’t halt.
On 2025-02-08 14:55:09 +0000, olcott said:
On 2/8/2025 4:25 AM, Mikko wrote:
On 2025-02-07 23:13:04 +0000, olcott said:
Within the context that HHH is a simulating termination analyzer lineNo, it does not. I only requires that the execution of HHH with aRequires HHH to simulate itself simulating DD recursively.The finite string DD specifies non-terminating recursive simulationNo, it does not. DD as quoted below pecifies nothing about the
to simulating termination analyzer HHH.
behaviour of HHH, only its argument types and return type.
; int Halt_Status = HHH(DD); // line 3 of DD
function pointer to DD must be started. OP does not show what happens
next.
3 of DD proves that DD cannot possibly reach its own "if" statement.
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
Yes, it demonstrates the incapability of HHH to correctly
determine the halting behaviour of DD
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
The finite string defines one behaviour. This finite string,
when given to an X86 processor shows halting behaviour. This
finite string,when given to a world class simulator, shows
halting behaviour. Only HHH fails to see this proven halting
behaviour. So it proves the failure of HHH.
HHH aborts the simulation on unsound grounds one cycle before
the simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping
from finite strings to behaviors.
Yes. And the behaviour of this finite string has been proven to >>>>>>>> show halting behaviour. Only Olcott's HHH fails to see it.
His misunderstanding is that he thinks that the behaviour
defined by the finite string depends on the simulator.
When DD calls HHH(DD) in recursive simulation it is a
verified fact that DD cannot possibly halt.
Which proves the failure of HHH. It does not reach the end of a
halting program. All other methods show that DD halts.
Your comment only proves that you lack sufficient
understanding of the C programming language.
This is a proof of lack of logical reasoning.
Verified fact 1: DD halts
Fallacy of equivocation error.
(a) All men are mortal
(b) No woman is a man
∴ No woman is mortal
Yes, the claim that DD does not halt is indeed such a fallacy:
(a) Direct execution and all simulators show that DD halts.
(b) My simulator is different
∴ DD does not halt.
The input to HHH(DD) cannot possibly terminate normally.
Referring to some other DD does not change this verfied fact.
That DD halts is a verified fact.
The input to HHH(DD) DOES NOT HALT !!!
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
Yes, it demonstrates the incapability of HHH to correctly
determine the halting behaviour of DD
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
The finite string defines one behaviour. This finite string, when
given to an X86 processor shows halting behaviour. This finite
string,when given to a world class simulator, shows halting
behaviour. Only HHH fails to see this proven halting behaviour. So >>>>>> it proves the failure of HHH.
HHH aborts the simulation on unsound grounds one cycle before the
simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping
from finite strings to behaviors.
Yes. And the behaviour of this finite string has been proven to
show halting behaviour. Only Olcott's HHH fails to see it.
His misunderstanding is that he thinks that the behaviour defined
by the finite string depends on the simulator.
When DD calls HHH(DD) in recursive simulation it is a
verified fact that DD cannot possibly halt.
Which proves the failure of HHH. It does not reach the end of a
halting program. All other methods show that DD halts.
Your comment only proves that you lack sufficient
understanding of the C programming language.
This is a proof of lack of logical reasoning.
Verified fact 1: DD halts
Fallacy of equivocation error.
(a) All men are mortal
(b) No woman is a man
∴ No woman is mortal
The input to HHH(DD) cannot possibly terminate normally.
Referring to some other DD does not change this verfied fact.
On 2/9/2025 10:43 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:37 schreef olcott:
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own >>>>>>>>>>> "if" statement.
Yes, it demonstrates the incapability of HHH to correctly
determine the halting behaviour of DD
The finite string DD specifies non-terminating recursive >>>>>>>>>>> simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
The finite string defines one behaviour. This finite string, >>>>>>>>>> when given to an X86 processor shows halting behaviour. This >>>>>>>>>> finite string,when given to a world class simulator, shows >>>>>>>>>> halting behaviour. Only HHH fails to see this proven halting >>>>>>>>>> behaviour. So it proves the failure of HHH.
HHH aborts the simulation on unsound grounds one cycle before >>>>>>>>>> the simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping >>>>>>>>>>> from finite strings to behaviors.
Yes. And the behaviour of this finite string has been proven >>>>>>>>>> to show halting behaviour. Only Olcott's HHH fails to see it. >>>>>>>>>> His misunderstanding is that he thinks that the behaviour
defined by the finite string depends on the simulator.
When DD calls HHH(DD) in recursive simulation it is a
verified fact that DD cannot possibly halt.
Which proves the failure of HHH. It does not reach the end of a >>>>>>>> halting program. All other methods show that DD halts.
Your comment only proves that you lack sufficient
understanding of the C programming language.
This is a proof of lack of logical reasoning.
Verified fact 1: DD halts
Fallacy of equivocation error.
(a) All men are mortal
(b) No woman is a man
∴ No woman is mortal
Yes, the claim that DD does not halt is indeed such a fallacy:
(a) Direct execution and all simulators show that DD halts.
(b) My simulator is different
∴ DD does not halt.
The input to HHH(DD) cannot possibly terminate normally.
Referring to some other DD does not change this verfied fact.
That DD halts is a verified fact.
The input to HHH(DD) DOES NOT HALT !!!
It is a verified fact that the finite string describes a halting
program. Du to a bug, HHH does not see that, because it investigates
only the first few instructions of DD. HHH is unable to process the
call from DD to HHH correctly.
No sense talking to people that lack sufficient technical
skill to verify facts. There is no bug and you know it.
DD simulated by HHH cannot possibly terminate normally.
DD simulated by HHH does specify the behavioral basis
of the Boolean termination value of the DD input to HHH.
On 2/9/2025 10:43 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:37 schreef olcott:
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own >>>>>>>>>>> "if" statement.
Yes, it demonstrates the incapability of HHH to correctly
determine the halting behaviour of DD
The finite string DD specifies non-terminating recursive >>>>>>>>>>> simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
The finite string defines one behaviour. This finite string, >>>>>>>>>> when given to an X86 processor shows halting behaviour. This >>>>>>>>>> finite string,when given to a world class simulator, shows >>>>>>>>>> halting behaviour. Only HHH fails to see this proven halting >>>>>>>>>> behaviour. So it proves the failure of HHH.
HHH aborts the simulation on unsound grounds one cycle before >>>>>>>>>> the simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping >>>>>>>>>>> from finite strings to behaviors.
Yes. And the behaviour of this finite string has been proven >>>>>>>>>> to show halting behaviour. Only Olcott's HHH fails to see it. >>>>>>>>>> His misunderstanding is that he thinks that the behaviour
defined by the finite string depends on the simulator.
When DD calls HHH(DD) in recursive simulation it is a
verified fact that DD cannot possibly halt.
Which proves the failure of HHH. It does not reach the end of a >>>>>>>> halting program. All other methods show that DD halts.
Your comment only proves that you lack sufficient
understanding of the C programming language.
This is a proof of lack of logical reasoning.
Verified fact 1: DD halts
Fallacy of equivocation error.
(a) All men are mortal
(b) No woman is a man
∴ No woman is mortal
Yes, the claim that DD does not halt is indeed such a fallacy:
(a) Direct execution and all simulators show that DD halts.
(b) My simulator is different
∴ DD does not halt.
The input to HHH(DD) cannot possibly terminate normally.
Referring to some other DD does not change this verfied fact.
That DD halts is a verified fact.
The input to HHH(DD) DOES NOT HALT !!!
It is a verified fact that the finite string describes a halting
program. Du to a bug, HHH does not see that, because it investigates
only the first few instructions of DD. HHH is unable to process the
call from DD to HHH correctly.
No sense talking to people that lack sufficient technical
skill to verify facts. There is no bug and you know it.
DD simulated by HHH cannot possibly terminate normally.
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:DD is the input to HHH.
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
The input to HHH(DD) DOES NOT HALT !!!The input to HHH(DD) cannot possibly terminate normally. Referring toThat DD halts is a verified fact.
some other DD does not change this verfied fact.
On 2/9/2025 12:47 PM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:49 schreef olcott:
On 2/9/2025 10:43 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:37 schreef olcott:
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
Experts in the C programming language will know that DD >>>>>>>>>>>>> correctly simulated by HHH cannot possibly reach its own >>>>>>>>>>>>> "if" statement.
Yes, it demonstrates the incapability of HHH to correctly >>>>>>>>>>>> determine the halting behaviour of DD
The finite string DD specifies non-terminating recursive >>>>>>>>>>>>> simulation to simulating termination analyzer HHH. This >>>>>>>>>>>>> makes HHH necessarily correct to reject its input as >>>>>>>>>>>>> non-halting.
The finite string defines one behaviour. This finite string, >>>>>>>>>>>> when given to an X86 processor shows halting behaviour. This >>>>>>>>>>>> finite string,when given to a world class simulator, shows >>>>>>>>>>>> halting behaviour. Only HHH fails to see this proven halting >>>>>>>>>>>> behaviour. So it proves the failure of HHH.
HHH aborts the simulation on unsound grounds one cycle >>>>>>>>>>>> before the simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>> has fully operational HHH and DD
The halting problem has always been a mathematical mapping >>>>>>>>>>>>> from finite strings to behaviors.
Yes. And the behaviour of this finite string has been proven >>>>>>>>>>>> to show halting behaviour. Only Olcott's HHH fails to see it. >>>>>>>>>>>> His misunderstanding is that he thinks that the behaviour >>>>>>>>>>>> defined by the finite string depends on the simulator.
When DD calls HHH(DD) in recursive simulation it is a
verified fact that DD cannot possibly halt.
Which proves the failure of HHH. It does not reach the end of >>>>>>>>>> a halting program. All other methods show that DD halts.
Your comment only proves that you lack sufficient
understanding of the C programming language.
This is a proof of lack of logical reasoning.
Verified fact 1: DD halts
Fallacy of equivocation error.
(a) All men are mortal
(b) No woman is a man
∴ No woman is mortal
Yes, the claim that DD does not halt is indeed such a fallacy:
(a) Direct execution and all simulators show that DD halts.
(b) My simulator is different
∴ DD does not halt.
The input to HHH(DD) cannot possibly terminate normally.
Referring to some other DD does not change this verfied fact.
That DD halts is a verified fact.
The input to HHH(DD) DOES NOT HALT !!!
It is a verified fact that the finite string describes a halting
program. Du to a bug, HHH does not see that, because it investigates
only the first few instructions of DD. HHH is unable to process the
call from DD to HHH correctly.
No sense talking to people that lack sufficient technical
skill to verify facts. There is no bug and you know it.
No sense to talk to people denying verified facts.
DD simulated by HHH cannot possibly terminate normally.
Indeed, because HHH fails to simulate itself up to the end.
This is verified with:
int main() {
return HHH(main);
}
There is no simulating itself to the end with the above
example either.
On 2/9/2025 1:30 PM, Fred. Zwarts wrote:
Op 09.feb.2025 om 20:00 schreef olcott:
On 2/9/2025 12:47 PM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:49 schreef olcott:
On 2/9/2025 10:43 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:37 schreef olcott:
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:When DD calls HHH(DD) in recursive simulation it is a >>>>>>>>>>>>> verified fact that DD cannot possibly halt.
Experts in the C programming language will know that DD >>>>>>>>>>>>>>> correctly simulated by HHH cannot possibly reach its own >>>>>>>>>>>>>>> "if" statement.
Yes, it demonstrates the incapability of HHH to correctly >>>>>>>>>>>>>> determine the halting behaviour of DD
The finite string DD specifies non-terminating recursive >>>>>>>>>>>>>>> simulation to simulating termination analyzer HHH. This >>>>>>>>>>>>>>> makes HHH necessarily correct to reject its input as >>>>>>>>>>>>>>> non-halting.
The finite string defines one behaviour. This finite >>>>>>>>>>>>>> string, when given to an X86 processor shows halting >>>>>>>>>>>>>> behaviour. This finite string,when given to a world class >>>>>>>>>>>>>> simulator, shows halting behaviour. Only HHH fails to see >>>>>>>>>>>>>> this proven halting behaviour. So it proves the failure of >>>>>>>>>>>>>> HHH.
HHH aborts the simulation on unsound grounds one cycle >>>>>>>>>>>>>> before the simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>>> has fully operational HHH and DD
The halting problem has always been a mathematical mapping >>>>>>>>>>>>>>> from finite strings to behaviors.
Yes. And the behaviour of this finite string has been >>>>>>>>>>>>>> proven to show halting behaviour. Only Olcott's HHH fails >>>>>>>>>>>>>> to see it.
His misunderstanding is that he thinks that the behaviour >>>>>>>>>>>>>> defined by the finite string depends on the simulator. >>>>>>>>>>>>>
Which proves the failure of HHH. It does not reach the end >>>>>>>>>>>> of a halting program. All other methods show that DD halts. >>>>>>>>>>>>
Your comment only proves that you lack sufficient
understanding of the C programming language.
This is a proof of lack of logical reasoning.
Verified fact 1: DD halts
Fallacy of equivocation error.
(a) All men are mortal
(b) No woman is a man
∴ No woman is mortal
Yes, the claim that DD does not halt is indeed such a fallacy: >>>>>>>>
(a) Direct execution and all simulators show that DD halts.
(b) My simulator is different
∴ DD does not halt.
The input to HHH(DD) cannot possibly terminate normally.
Referring to some other DD does not change this verfied fact. >>>>>>>>>
That DD halts is a verified fact.
The input to HHH(DD) DOES NOT HALT !!!
It is a verified fact that the finite string describes a halting
program. Du to a bug, HHH does not see that, because it
investigates only the first few instructions of DD. HHH is unable
to process the call from DD to HHH correctly.
No sense talking to people that lack sufficient technical
skill to verify facts. There is no bug and you know it.
No sense to talk to people denying verified facts.
DD simulated by HHH cannot possibly terminate normally.
Indeed, because HHH fails to simulate itself up to the end.
This is verified with:
int main() {
return HHH(main);
}
There is no simulating itself to the end with the above
example either.
It seems Olcott misses trivial facts. HHH simulates main, which calls
HHH, so HHH needs to simulate HHH. HHH is unable to complet the
simulation up to the end, because it
specifies a computation that cannot possibly terminate normally.
On 2/9/2025 10:43 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:37 schreef olcott:
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
The input to HHH(DD) DOES NOT HALT !!!The input to HHH(DD) cannot possibly terminate normally. ReferringThat DD halts is a verified fact.
to some other DD does not change this verfied fact.
It is a verified fact that the finite string describes a halting
program. Du to a bug, HHH does not see that, because it investigates
only the first few instructions of DD. HHH is unable to process the
call from DD to HHH correctly.
DD simulated by HHH cannot possibly terminate normally. DD simulated by
HHH does specify the behavioral basis of the Boolean termination value
of the DD input to HHH.
On 2/9/2025 12:47 PM, Fred. Zwarts wrote:That’s the point. HHH doesn’t terminate.
Op 09.feb.2025 om 17:49 schreef olcott:
On 2/9/2025 10:43 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:37 schreef olcott:
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
There is no simulating itself to the end with the above example either. Apparently you do not understand the basic notion of recursion veryThe input to HHH(DD) DOES NOT HALT !!!The input to HHH(DD) cannot possibly terminate normally. Referring >>>>>>> to some other DD does not change this verfied fact.That DD halts is a verified fact.
It is a verified fact that the finite string describes a halting
program. Du to a bug, HHH does not see that, because it investigates
only the first few instructions of DD. HHH is unable to process the
call from DD to HHH correctly.
DD simulated by HHH cannot possibly terminate normally.
Indeed, because HHH fails to simulate itself up to the end.
This is verified with:
int main() {
return HHH(main);
}
well.
On 2/9/2025 1:39 PM, joes wrote:
Am Sun, 09 Feb 2025 10:49:51 -0600 schrieb olcott:
On 2/9/2025 10:43 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:37 schreef olcott:
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
The input to HHH(DD) DOES NOT HALT !!!The input to HHH(DD) cannot possibly terminate normally. Referring >>>>>>> to some other DD does not change this verfied fact.That DD halts is a verified fact.
It is a verified fact that the finite string describes a halting
program. Du to a bug, HHH does not see that, because it investigates
only the first few instructions of DD. HHH is unable to process the
call from DD to HHH correctly.
DD simulated by HHH cannot possibly terminate normally. DD simulated by
HHH does specify the behavioral basis of the Boolean termination value
of the DD input to HHH.
DD terminates, and HHH can’t simulate it normally.
That is not the same DD as the input to HHH(DD).
That DD has an entirely different execution trace.
On 2/9/2025 5:05 PM, Richard Damon wrote:
On 2/9/25 2:57 PM, olcott wrote:
On 2/9/2025 1:39 PM, joes wrote:
Am Sun, 09 Feb 2025 10:49:51 -0600 schrieb olcott:
On 2/9/2025 10:43 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:37 schreef olcott:
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
The input to HHH(DD) DOES NOT HALT !!!The input to HHH(DD) cannot possibly terminate normally. Referring >>>>>>>>> to some other DD does not change this verfied fact.That DD halts is a verified fact.
It is a verified fact that the finite string describes a halting
program. Du to a bug, HHH does not see that, because it investigates >>>>>> only the first few instructions of DD. HHH is unable to process the >>>>>> call from DD to HHH correctly.
DD simulated by HHH cannot possibly terminate normally. DD
simulated by
HHH does specify the behavioral basis of the Boolean termination value >>>>> of the DD input to HHH.
DD terminates, and HHH can’t simulate it normally.
That is not the same DD as the input to HHH(DD).
That DD has an entirely different execution trace.
What is different about it?
*That DD has an entirely different execution trace*
Do you know what an execution trace is?
On 2/9/2025 3:48 AM, Mikko wrote:
On 2025-02-08 14:43:53 +0000, olcott said:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
Yes, it demonstrates the incapability of HHH to correctly determine the >>>> halting behaviour of DD
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
The finite string defines one behaviour. This finite string, when given >>>> to an X86 processor shows halting behaviour. This finite string,when
given to a world class simulator, shows halting behaviour. Only HHH
fails to see this proven halting behaviour. So it proves the failure of >>>> HHH.
HHH aborts the simulation on unsound grounds one cycle before the
simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping
from finite strings to behaviors.
Yes. And the behaviour of this finite string has been proven to show
halting behaviour. Only Olcott's HHH fails to see it.
His misunderstanding is that he thinks that the behaviour defined by
the finite string depends on the simulator.
When DD calls HHH(DD) in recursive simulation it is a
verified fact that DD cannot possibly halt.
The word "cannot" is not compatible with the meaning of the word "fact".
That "DD cannot possibly halt" is not a fact. A fact may be that "DD has
not halted in any test so far".
Cannot possibly halt in the same way that an infinite
loop cannot possibly halt.
That you don't understand
the C programming language well enough to see this counts
as no rebuttal what-so-ever.
On 2/9/2025 1:30 PM, Fred. Zwarts wrote:
Op 09.feb.2025 om 20:00 schreef olcott:
On 2/9/2025 12:47 PM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:49 schreef olcott:
On 2/9/2025 10:43 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:37 schreef olcott:
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:When DD calls HHH(DD) in recursive simulation it is a >>>>>>>>>>>>> verified fact that DD cannot possibly halt.
Experts in the C programming language will know that DD >>>>>>>>>>>>>>> correctly simulated by HHH cannot possibly reach its own >>>>>>>>>>>>>>> "if" statement.
Yes, it demonstrates the incapability of HHH to correctly >>>>>>>>>>>>>> determine the halting behaviour of DD
The finite string DD specifies non-terminating recursive >>>>>>>>>>>>>>> simulation to simulating termination analyzer HHH. This >>>>>>>>>>>>>>> makes HHH necessarily correct to reject its input as >>>>>>>>>>>>>>> non-halting.
The finite string defines one behaviour. This finite >>>>>>>>>>>>>> string, when given to an X86 processor shows halting >>>>>>>>>>>>>> behaviour. This finite string,when given to a world class >>>>>>>>>>>>>> simulator, shows halting behaviour. Only HHH fails to see >>>>>>>>>>>>>> this proven halting behaviour. So it proves the failure of >>>>>>>>>>>>>> HHH.
HHH aborts the simulation on unsound grounds one cycle >>>>>>>>>>>>>> before the simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>>> has fully operational HHH and DD
The halting problem has always been a mathematical mapping >>>>>>>>>>>>>>> from finite strings to behaviors.
Yes. And the behaviour of this finite string has been >>>>>>>>>>>>>> proven to show halting behaviour. Only Olcott's HHH fails >>>>>>>>>>>>>> to see it.
His misunderstanding is that he thinks that the behaviour >>>>>>>>>>>>>> defined by the finite string depends on the simulator. >>>>>>>>>>>>>
Which proves the failure of HHH. It does not reach the end >>>>>>>>>>>> of a halting program. All other methods show that DD halts. >>>>>>>>>>>>
Your comment only proves that you lack sufficient
understanding of the C programming language.
This is a proof of lack of logical reasoning.
Verified fact 1: DD halts
Fallacy of equivocation error.
(a) All men are mortal
(b) No woman is a man
∴ No woman is mortal
Yes, the claim that DD does not halt is indeed such a fallacy: >>>>>>>>
(a) Direct execution and all simulators show that DD halts.
(b) My simulator is different
∴ DD does not halt.
The input to HHH(DD) cannot possibly terminate normally.
Referring to some other DD does not change this verfied fact. >>>>>>>>>
That DD halts is a verified fact.
The input to HHH(DD) DOES NOT HALT !!!
It is a verified fact that the finite string describes a halting
program. Du to a bug, HHH does not see that, because it
investigates only the first few instructions of DD. HHH is unable
to process the call from DD to HHH correctly.
No sense talking to people that lack sufficient technical
skill to verify facts. There is no bug and you know it.
No sense to talk to people denying verified facts.
DD simulated by HHH cannot possibly terminate normally.
Indeed, because HHH fails to simulate itself up to the end.
This is verified with:
int main() {
return HHH(main);
}
There is no simulating itself to the end with the above
example either.
It seems Olcott misses trivial facts. HHH simulates main, which calls
HHH, so HHH needs to simulate HHH. HHH is unable to complet the
simulation up to the end, because it
specifies a computation that cannot possibly terminate normally.
On 2/9/2025 4:08 AM, Mikko wrote:
On 2025-02-08 14:55:09 +0000, olcott said:
On 2/8/2025 4:25 AM, Mikko wrote:
On 2025-02-07 23:13:04 +0000, olcott said:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
Wrong, they understand that nothing below exludes the possibility that >>>> HHH is a program that can correctly simulate DD to its "if" statement.
Show the execution trace of that.
Your request does not make sense. Non-existence of a exclusion does not
have an execution trace.
The code of HHH might exlude that but that is not sohwn below.Requires HHH to simulate itself simulating DD recursively.
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH.
No, it does not. DD as quoted below pecifies nothing about the behaviour >>>> of HHH, only its argument types and return type.
; int Halt_Status = HHH(DD); // line 3 of DD
No, it does not. I only requires that the execution of HHH with a function >> pointer to DD must be started. OP does not show what happens next.
Within the context that HHH <is> a simulating termination
analyzer line 3 of DD proves that DD cannot possibly reach
its own "if" statement.
On 2/9/2025 1:30 PM, Fred. Zwarts wrote:Which is weird, considering that HHH is supposed to be a decider,
Op 09.feb.2025 om 20:00 schreef olcott:
On 2/9/2025 12:47 PM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:49 schreef olcott:
On 2/9/2025 10:43 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:37 schreef olcott:
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
That DD halts is a verified fact.
The input to HHH(DD) DOES NOT HALT !!!
It is a verified fact that the finite string describes a halting
program. Du to a bug, HHH does not see that, because it
investigates only the first few instructions of DD. HHH is unable
to process the call from DD to HHH correctly.
specifies a computation that cannot possibly terminate normally.It seems Olcott misses trivial facts. HHH simulates main, which callsThere is no simulating itself to the end with the above exampleDD simulated by HHH cannot possibly terminate normally.Indeed, because HHH fails to simulate itself up to the end.
This is verified with:
int main() {
return HHH(main);
}
either.
HHH, so HHH needs to simulate HHH. HHH is unable to complet the
simulation up to the end, because it
On 2/9/2025 1:39 PM, joes wrote:That is entirely due to how HHH chooses to missimulate it, namely by not calling itself, but a different version that doesn’t abort.
Am Sun, 09 Feb 2025 10:49:51 -0600 schrieb olcott:That is not the same DD as the input to HHH(DD). That DD has an entirely different execution trace.
On 2/9/2025 10:43 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:37 schreef olcott:
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
The input to HHH(DD) DOES NOT HALT !!!The input to HHH(DD) cannot possibly terminate normally. Referring >>>>>>> to some other DD does not change this verfied fact.That DD halts is a verified fact.
It is a verified fact that the finite string describes a halting
program. Du to a bug, HHH does not see that, because it investigates
only the first few instructions of DD. HHH is unable to process the
call from DD to HHH correctly.
DD simulated by HHH cannot possibly terminate normally. DD simulated
by HHH does specify the behavioral basis of the Boolean termination
value of the DD input to HHH.
DD terminates, and HHH can’t simulate it normally.
On 2/10/2025 5:18 AM, joes wrote:
Am Sun, 09 Feb 2025 13:57:03 -0600 schrieb olcott:
On 2/9/2025 1:39 PM, joes wrote:
Am Sun, 09 Feb 2025 10:49:51 -0600 schrieb olcott:That is not the same DD as the input to HHH(DD). That DD has an entirely >>> different execution trace.
On 2/9/2025 10:43 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:37 schreef olcott:
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
The input to HHH(DD) DOES NOT HALT !!!The input to HHH(DD) cannot possibly terminate normally. Referring >>>>>>>>> to some other DD does not change this verfied fact.That DD halts is a verified fact.
It is a verified fact that the finite string describes a halting
program. Du to a bug, HHH does not see that, because it investigates >>>>>> only the first few instructions of DD. HHH is unable to process the >>>>>> call from DD to HHH correctly.
DD simulated by HHH cannot possibly terminate normally. DD simulated >>>>> by HHH does specify the behavioral basis of the Boolean termination
value of the DD input to HHH.
DD terminates, and HHH can’t simulate it normally.
That is entirely due to how HHH chooses to missimulate it, namely by not
calling itself, but a different version that doesn’t abort.
Why do you not pass the same DD as an input to HHH?
The same machine address of DD is the only reference to DD that
any termination analyzer ever sees.
On 2/10/2025 5:18 AM, joes wrote:And the code at that address, and all code called from there,
Am Sun, 09 Feb 2025 13:57:03 -0600 schrieb olcott:The same machine address of DD is the only reference to DD that any termination analyzer ever sees.
On 2/9/2025 1:39 PM, joes wrote:That is entirely due to how HHH chooses to missimulate it, namely by
Am Sun, 09 Feb 2025 10:49:51 -0600 schrieb olcott:That is not the same DD as the input to HHH(DD). That DD has an
On 2/9/2025 10:43 AM, Fred. Zwarts wrote:DD terminates, and HHH can’t simulate it normally.
Op 09.feb.2025 om 17:37 schreef olcott:
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
DD simulated by HHH cannot possibly terminate normally. DD simulated >>>>> by HHH does specify the behavioral basis of the Boolean terminationIt is a verified fact that the finite string describes a haltingThe input to HHH(DD) DOES NOT HALT !!!The input to HHH(DD) cannot possibly terminate normally.
Referring to some other DD does not change this verfied fact. >>>>>>>> That DD halts is a verified fact.
program. Du to a bug, HHH does not see that, because it
investigates only the first few instructions of DD. HHH is unable
to process the call from DD to HHH correctly.
value of the DD input to HHH.
entirely different execution trace.
not calling itself, but a different version that doesn’t abort.
Why do you not pass the same DD as an input to HHH?
On 2/9/2025 1:42 PM, joes wrote:Then why does it report non-halting on itself?
Am Sun, 09 Feb 2025 13:00:05 -0600 schrieb olcott:
On 2/9/2025 12:47 PM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:49 schreef olcott:
On 2/9/2025 10:43 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 17:37 schreef olcott:
On 2/9/2025 9:53 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 16:15 schreef olcott:
On 2/9/2025 2:09 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:04 schreef olcott:
On 2/8/2025 3:49 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:43 schreef olcott:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
It is a verified fact that the finite string describes a haltingThe input to HHH(DD) DOES NOT HALT !!!The input to HHH(DD) cannot possibly terminate normally.
Referring to some other DD does not change this verfied fact. >>>>>>>> That DD halts is a verified fact.
program. Du to a bug, HHH does not see that, because it
investigates only the first few instructions of DD. HHH is unable
to process the call from DD to HHH correctly.
Counter-factual.That’s the point. HHH doesn’t terminate.Indeed, because HHH fails to simulate itself up to the end.There is no simulating itself to the end with the above example
This is verified with:
int main() {
return HHH(main);
}
either.
Apparently you do not understand the basic notion of recursion very
well.
On 2/10/2025 2:33 AM, Mikko wrote:
On 2025-02-09 15:21:57 +0000, olcott said:
On 2/9/2025 3:48 AM, Mikko wrote:
On 2025-02-08 14:43:53 +0000, olcott said:
On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 00:13 schreef olcott:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
Yes, it demonstrates the incapability of HHH to correctly determine the >>>>>> halting behaviour of DD
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH. This
makes HHH necessarily correct to reject its input as
non-halting.
The finite string defines one behaviour. This finite string, when given >>>>>> to an X86 processor shows halting behaviour. This finite string,when >>>>>> given to a world class simulator, shows halting behaviour. Only HHH >>>>>> fails to see this proven halting behaviour. So it proves the failure of >>>>>> HHH.
HHH aborts the simulation on unsound grounds one cycle before the
simulation would terminate normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has fully operational HHH and DD
The halting problem has always been a mathematical mapping
from finite strings to behaviors.
Yes. And the behaviour of this finite string has been proven to show >>>>>> halting behaviour. Only Olcott's HHH fails to see it.
His misunderstanding is that he thinks that the behaviour defined by >>>>>> the finite string depends on the simulator.
When DD calls HHH(DD) in recursive simulation it is a
verified fact that DD cannot possibly halt.
The word "cannot" is not compatible with the meaning of the word "fact". >>>> That "DD cannot possibly halt" is not a fact. A fact may be that "DD has >>>> not halted in any test so far".
Cannot possibly halt in the same way that an infinite
loop cannot possibly halt.
I.e., an inference, not a fact.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
It is more than a fact it is a truism.
That you don't understand
the C programming language well enough to see this counts
as no rebuttal what-so-ever.
It is a sin to present a false claim about another person.
Then quit doing it.
On 2/10/2025 2:35 AM, Mikko wrote:
On 2025-02-09 15:24:53 +0000, olcott said:
On 2/9/2025 4:08 AM, Mikko wrote:
On 2025-02-08 14:55:09 +0000, olcott said:
On 2/8/2025 4:25 AM, Mikko wrote:
On 2025-02-07 23:13:04 +0000, olcott said:Show the execution trace of that.
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
Wrong, they understand that nothing below exludes the possibility that >>>>>> HHH is a program that can correctly simulate DD to its "if" statement. >>>>>
Your request does not make sense. Non-existence of a exclusion does not >>>> have an execution trace.
The code of HHH might exlude that but that is not sohwn below.Requires HHH to simulate itself simulating DD recursively.
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH.
No, it does not. DD as quoted below pecifies nothing about the behaviour >>>>>> of HHH, only its argument types and return type.
; int Halt_Status = HHH(DD); // line 3 of DD
No, it does not. I only requires that the execution of HHH with a function >>>> pointer to DD must be started. OP does not show what happens next.
Within the context that HHH <is> a simulating termination
analyzer line 3 of DD proves that DD cannot possibly reach
its own "if" statement.
That is not the context of OP.
That you did not bother to look at my paper
does not entail that the correct full context has not been provided.
The
context has always been this paper for several years.
On 2/11/2025 3:27 AM, Mikko wrote:
On 2025-02-10 11:58:31 +0000, olcott said:
On 2/10/2025 2:35 AM, Mikko wrote:
On 2025-02-09 15:24:53 +0000, olcott said:
On 2/9/2025 4:08 AM, Mikko wrote:
On 2025-02-08 14:55:09 +0000, olcott said:
On 2/8/2025 4:25 AM, Mikko wrote:
On 2025-02-07 23:13:04 +0000, olcott said:
Experts in the C programming language will know that DD
correctly simulated by HHH cannot possibly reach its own
"if" statement.
Wrong, they understand that nothing below exludes the
possibility that
HHH is a program that can correctly simulate DD to its "if"
statement.
Show the execution trace of that.
Your request does not make sense. Non-existence of a exclusion
does not
have an execution trace.
The code of HHH might exlude that but that is not sohwn below. >>>>>>>>Requires HHH to simulate itself simulating DD recursively.
The finite string DD specifies non-terminating recursive
simulation to simulating termination analyzer HHH.
No, it does not. DD as quoted below pecifies nothing about the >>>>>>>> behaviour
of HHH, only its argument types and return type.
; int Halt_Status = HHH(DD); // line 3 of DD
No, it does not. I only requires that the execution of HHH with a
function
pointer to DD must be started. OP does not show what happens next.
Within the context that HHH <is> a simulating termination
analyzer line 3 of DD proves that DD cannot possibly reach
its own "if" statement.
That is not the context of OP.
That you did not bother to look at my paper
That is again a false claim about a person.
does not entail that the correct full context has not been provided.
Of course not. However, the fact that no reference to that article
before or when HHH
That paper and its code are the only thing that I have been talking
about in this forum for several years.
was introduced to the discussion and the fact
that the pointer to the article at the end of the discussion is not
linked to any specific point do entail exacltly that.
The
context has always been this paper for several years.
Irrelevant to OP.
Of course not. However, the fact that no reference to that article
before or when HHH
That paper and its code are the only thing that I have been talking
about in this forum for several years.
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that article
before or when HHH
That paper and its code are the only thing that I have been talking
about in this forum for several years.
Doesn't matter when you don't say that you are talking about that paper.
Anyway, that is irrelevant to the fact that the subject line contains
a false claim.
It is a truism and not one person on the face of the
Earth can possibly show otherwise.
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that article
before or when HHH
That paper and its code are the only thing that I have been talking
about in this forum for several years.
Doesn't matter when you don't say that you are talking about that paper.
Anyway, that is irrelevant to the fact that the subject line contains
a false claim.
It is a truism and not one person on the face of the
Earth can possibly show otherwise.
Since there is a 5% chance that the treatment I will
have next month will kill me and this treatment is
my only good chance I will totally ignore anything
that diverges from the point.
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that article >>>>>> before or when HHH
That paper and its code are the only thing that I have been talking
about in this forum for several years.
Doesn't matter when you don't say that you are talking about that
paper.
Anyway, that is irrelevant to the fact that the subject line contains
a false claim.
It is a truism and not one person on the face of the
Earth can possibly show otherwise.
The fact that the claim on subject line is false is not a truism.
In order to determine the claim is false one needs some knowledge
that is not obvious.
When you try to show the steps attempting to show that
it is false I will point out the error.
This is the only topic that I will discuss and any
reply not showing all of the steps of a rebuttal
will be ignored.
Even the stupidest bot that ever existed (Eliza)
can be a mere naysayer.
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that article >>>>>> before or when HHH
That paper and its code are the only thing that I have been talking
about in this forum for several years.
Doesn't matter when you don't say that you are talking about that paper. >>>>
Anyway, that is irrelevant to the fact that the subject line contains
a false claim.
It is a truism and not one person on the face of the
Earth can possibly show otherwise.
The fact that the claim on subject line is false is not a truism.
In order to determine the claim is false one needs some knowledge
that is not obvious.
When you try to show the steps attempting to show that
it is false I will point out the error.
This is the only topic that I will discuss and any
reply not showing all of the steps of a rebuttal
will be ignored.
Even the stupidest bot that ever existed (Eliza)
can be a mere naysayer.
On 2/13/2025 9:15 PM, Richard Damon wrote:
On 2/13/25 7:07 PM, olcott wrote:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:When you try to show the steps attempting to show that it is false I
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that
article before or when HHH
That paper and its code are the only thing that I have been
talking about in this forum for several years.
Doesn't matter when you don't say that you are talking about that
paper.
Anyway, that is irrelevant to the fact that the subject line
contains a false claim.
It is a truism and not one person on the face of the Earth can
possibly show otherwise.
The fact that the claim on subject line is false is not a truism.
In order to determine the claim is false one needs some knowledge
that is not obvious.
will point out the error.
We havm, but you are too stupid to understand it.
Since when DD run, it halts,
THAT IS A DIFFERENT INSTANCE
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that article >>>>>>>> before or when HHH
That paper and its code are the only thing that I have been
talking about in this forum for several years.
Doesn't matter when you don't say that you are talking about that
paper.
Anyway, that is irrelevant to the fact that the subject line contains >>>>>> a false claim.
It is a truism and not one person on the face of the
Earth can possibly show otherwise.
The fact that the claim on subject line is false is not a truism.
In order to determine the claim is false one needs some knowledge
that is not obvious.
When you try to show the steps attempting to show that
it is false I will point out the error.
Step 1: Find people who know C.
Step 2: Show them DD of OP and ask.
This is the only topic that I will discuss and any
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly simulated by HHH cannot possibly terminate normally.
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that article >>>>>>>> before or when HHH
That paper and its code are the only thing that I have been
talking about in this forum for several years.
Doesn't matter when you don't say that you are talking about that
paper.
Anyway, that is irrelevant to the fact that the subject line contains >>>>>> a false claim.
It is a truism and not one person on the face of the
Earth can possibly show otherwise.
The fact that the claim on subject line is false is not a truism.
In order to determine the claim is false one needs some knowledge
that is not obvious.
When you try to show the steps attempting to show that
it is false I will point out the error.
Step 1: Find people who know C.
Step 2: Show them DD of OP and ask.
This is the only topic that I will discuss and any
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly simulated by HHH cannot possibly terminate normally.
On 2/14/2025 6:54 AM, joes wrote:
Am Thu, 13 Feb 2025 22:21:59 -0600 schrieb olcott:
On 2/13/2025 9:15 PM, Richard Damon wrote:
On 2/13/25 7:07 PM, olcott wrote:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:When you try to show the steps attempting to show that it is false I >>>>> will point out the error.
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that >>>>>>>>>> article before or when HHH
That paper and its code are the only thing that I have been
talking about in this forum for several years.
Doesn't matter when you don't say that you are talking about that >>>>>>>> paper.
Anyway, that is irrelevant to the fact that the subject line
contains a false claim.
It is a truism and not one person on the face of the Earth can
possibly show otherwise.
The fact that the claim on subject line is false is not a truism.
In order to determine the claim is false one needs some knowledge
that is not obvious.
We havm, but you are too stupid to understand it.
Since when DD run, it halts,
THAT IS A DIFFERENT INSTANCE
Why are you passing the wrong input to HHH?
I will begin ignoring insincere replies.
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that article >>>>>>>> before or when HHH
That paper and its code are the only thing that I have been talking >>>>>>> about in this forum for several years.
Doesn't matter when you don't say that you are talking about that paper. >>>>>>
Anyway, that is irrelevant to the fact that the subject line contains >>>>>> a false claim.
It is a truism and not one person on the face of the
Earth can possibly show otherwise.
The fact that the claim on subject line is false is not a truism.
In order to determine the claim is false one needs some knowledge
that is not obvious.
When you try to show the steps attempting to show that
it is false I will point out the error.
Step 1: Find people who know C.
Step 2: Show them DD of OP and ask.
This is the only topic that I will discuss and any
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly simulated by HHH cannot possibly terminate normally.
On 2/14/2025 7:49 AM, Fred. Zwarts wrote:
Op 14.feb.2025 om 13:40 schreef olcott:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that >>>>>>>>>> article
before or when HHH
That paper and its code are the only thing that I have been
talking about in this forum for several years.
Doesn't matter when you don't say that you are talking about
that paper.
Anyway, that is irrelevant to the fact that the subject line
contains
a false claim.
It is a truism and not one person on the face of the
Earth can possibly show otherwise.
The fact that the claim on subject line is false is not a truism.
In order to determine the claim is false one needs some knowledge
that is not obvious.
When you try to show the steps attempting to show that
it is false I will point out the error.
Step 1: Find people who know C.
Step 2: Show them DD of OP and ask.
This is the only topic that I will discuss and any
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly simulated by HHH cannot possibly terminate normally.
Indeed. The simulation by HHH fails to reach the end of the halting DD.
different instance with provably different execution trace
On 2/14/2025 7:49 AM, Fred. Zwarts wrote:Come on. All instances of a deterministic program behave the same.
Op 14.feb.2025 om 13:40 schreef olcott:different instance with provably different execution trace
On 2/14/2025 2:58 AM, Mikko wrote:Indeed. The simulation by HHH fails to reach the end of the halting DD.
On 2025-02-14 00:07:23 +0000, olcott said:DD correctly simulated by HHH cannot possibly terminate normally.
On 2/13/2025 3:20 AM, Mikko wrote:Step 1: Find people who know C.
On 2025-02-13 04:21:34 +0000, olcott said:When you try to show the steps attempting to show that it is false I >>>>> will point out the error.
On 2/12/2025 4:04 AM, Mikko wrote:The fact that the claim on subject line is false is not a truism.
On 2025-02-11 14:41:38 +0000, olcott said:It is a truism and not one person on the face of the Earth can
Doesn't matter when you don't say that you are talking about that >>>>>>>> paper.Of course not. However, the fact that no reference to that >>>>>>>>>> article before or when HHHThat paper and its code are the only thing that I have been
talking about in this forum for several years.
Anyway, that is irrelevant to the fact that the subject line
contains a false claim.
possibly show otherwise.
In order to determine the claim is false one needs some knowledge
that is not obvious.
Step 2: Show them DD of OP and ask.
This is the only topic that I will discuss and any
--This shows that it is a bad idea to use a simulator to decide about
halting/non-halting behaviour.
On 2/14/2025 7:21 AM, Richard Damon wrote:Yes, HHH simulates DD counter to the fact that it halts.
On 2/13/25 11:21 PM, olcott wrote:counter-factual
On 2/13/2025 9:15 PM, Richard Damon wrote:But they all act the same.
On 2/13/25 7:07 PM, olcott wrote:THAT IS A DIFFERENT INSTANCE
On 2/13/2025 3:20 AM, Mikko wrote:We havm, but you are too stupid to understand it.
On 2025-02-13 04:21:34 +0000, olcott said:When you try to show the steps attempting to show that it is false I >>>>> will point out the error.
On 2/12/2025 4:04 AM, Mikko wrote:The fact that the claim on subject line is false is not a truism.
On 2025-02-11 14:41:38 +0000, olcott said:It is a truism and not one person on the face of the Earth can
Doesn't matter when you don't say that you are talking about that >>>>>>>> paper.Of course not. However, the fact that no reference to that >>>>>>>>>> article before or when HHHThat paper and its code are the only thing that I have been
talking about in this forum for several years.
Anyway, that is irrelevant to the fact that the subject line
contains a false claim.
possibly show otherwise.
In order to determine the claim is false one needs some knowledge
that is not obvious.
Since when DD run, it halts,
On 2/14/2025 6:54 AM, joes wrote:Yes, please shut up.
Am Thu, 13 Feb 2025 22:21:59 -0600 schrieb olcott:I will begin ignoring insincere replies.
On 2/13/2025 9:15 PM, Richard Damon wrote:Why are you passing the wrong input to HHH?
On 2/13/25 7:07 PM, olcott wrote:THAT IS A DIFFERENT INSTANCE
On 2/13/2025 3:20 AM, Mikko wrote:We havm, but you are too stupid to understand it.
On 2025-02-13 04:21:34 +0000, olcott said:When you try to show the steps attempting to show that it is false I >>>>> will point out the error.
On 2/12/2025 4:04 AM, Mikko wrote:The fact that the claim on subject line is false is not a truism.
On 2025-02-11 14:41:38 +0000, olcott said:It is a truism and not one person on the face of the Earth can
Doesn't matter when you don't say that you are talking about that >>>>>>>> paper.Of course not. However, the fact that no reference to that >>>>>>>>>> article before or when HHHThat paper and its code are the only thing that I have been
talking about in this forum for several years.
Anyway, that is irrelevant to the fact that the subject line
contains a false claim.
possibly show otherwise.
In order to determine the claim is false one needs some knowledge
that is not obvious.
Since when DD run, it halts,
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that >>>>>>>>>> article
before or when HHH
That paper and its code are the only thing that I have been
talking about in this forum for several years.
Doesn't matter when you don't say that you are talking about
that paper.
Anyway, that is irrelevant to the fact that the subject line
contains
a false claim.
It is a truism and not one person on the face of the
Earth can possibly show otherwise.
The fact that the claim on subject line is false is not a truism.
In order to determine the claim is false one needs some knowledge
that is not obvious.
When you try to show the steps attempting to show that
it is false I will point out the error.
Step 1: Find people who know C.
Step 2: Show them DD of OP and ask.
This is the only topic that I will discuss and any
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that
HHH does not return 0. If it does DD also returns 0.
When we know that DD is simulated by HHH we know that
HHH cannot possibly return to this DD as long as we
have at least a little competence in the C language.
On 2/15/2025 2:49 AM, Mikko wrote:If we also had a little competence in theory, we would know that
On 2025-02-14 12:40:04 +0000, olcott said:When we know that DD is simulated by HHH we know that HHH cannot
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that >>>>>>>>>> article before or when HHH
That paper and its code are the only thing that I have been
talking about in this forum for several years.
Doesn't matter when you don't say that you are talking about that >>>>>>>> paper.
Anyway, that is irrelevant to the fact that the subject line
contains a false claim.
It is a truism and not one person on the face of the Earth can
possibly show otherwise.
The fact that the claim on subject line is false is not a truism.
In order to determine the claim is false one needs some knowledge
that is not obvious.
When you try to show the steps attempting to show that it is false I >>>>> will point out the error.
Step 1: Find people who know C.
Step 2: Show them DD of OP and ask.
This is the only topic that I will discuss and any
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that HHH
does not return 0. If it does DD also returns 0.
possibly return to this DD as long as we have at least a little
competence in the C language.
On 2/15/2025 2:49 AM, Mikko wrote:such as one that calls a non-aborting version of HHH
On 2025-02-14 12:40:04 +0000, olcott said:When we are referring to the above DD simulated by HHH and not trying to
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that >>>>>>>>>> article before or when HHH
That paper and its code are the only thing that I have been
talking about in this forum for several years.
Doesn't matter when you don't say that you are talking about that >>>>>>>> paper.
Anyway, that is irrelevant to the fact that the subject line
contains a false claim.
It is a truism and not one person on the face of the Earth can
possibly show otherwise.
The fact that the claim on subject line is false is not a truism.
In order to determine the claim is false one needs some knowledge
that is not obvious.
When you try to show the steps attempting to show that it is false I >>>>> will point out the error.
Step 1: Find people who know C.
Step 2: Show them DD of OP and ask.
This is the only topic that I will discuss and any
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that HHH
does not return 0. If it does DD also returns 0.
get away with changing the subject to some other DD somewhere else
thenWell, then that corresponding (by what?) HHH isn’t a decider.
anyone with sufficient knowledge of C programming knows that no instance
of DD shown above simulated by any corresponding instance of HHH can
possibly terminate normally.
On 2/16/2025 6:53 AM, joes wrote:
Am Sat, 15 Feb 2025 21:16:30 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:If we also had a little competence in theory, we would know that
On 2025-02-14 12:40:04 +0000, olcott said:When we know that DD is simulated by HHH we know that HHH cannot
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that >>>>>>>>>>>> article before or when HHH
That paper and its code are the only thing that I have been >>>>>>>>>>> talking about in this forum for several years.
Doesn't matter when you don't say that you are talking about that >>>>>>>>>> paper.
Anyway, that is irrelevant to the fact that the subject line >>>>>>>>>> contains a false claim.
It is a truism and not one person on the face of the Earth can >>>>>>>>> possibly show otherwise.
The fact that the claim on subject line is false is not a truism. >>>>>>>> In order to determine the claim is false one needs some knowledge >>>>>>>> that is not obvious.
When you try to show the steps attempting to show that it is false I >>>>>>> will point out the error.
Step 1: Find people who know C.
Step 2: Show them DD of OP and ask.
This is the only topic that I will discuss and any
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that HHH >>>> does not return 0. If it does DD also returns 0.
possibly return to this DD as long as we have at least a little
competence in the C language.
HHH is not a decider if it doesn’t return.
HHH is a termination analyzer that way we can use software
engineering terms that more aptly refer to "normal termination"
rather than the somewhat more ambiguous term of "halting".
This also allows us to refer to the much more expressive
RASP architecture and not be limited by the tediousness
of Turing Machines.
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am focusing on the isomorphic notion of a termination analyzer.such as one that calls a non-aborting version of HHHWhen we are referring to the above DD simulated by HHH and not tryingtypedef void (*ptr)();This is the only topic that I will discuss and any
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that
HHH does not return 0. If it does DD also returns 0.
to get away with changing the subject to some other DD somewhere else
then anyone with sufficient knowledge of C programming knows that noWell, then that corresponding (by what?) HHH isn’t a decider.
instance of DD shown above simulated by any corresponding instance of
HHH can possibly terminate normally.
A simulating termination analyzer correctly rejects any input that mustYes, in particular itself is not such an input, because we *know* that
be aborted to prevent its own non-termination.
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:such as one that calls a non-aborting version of HHH
On 2025-02-14 12:40:04 +0000, olcott said:When we are referring to the above DD simulated by HHH and not trying to >>> get away with changing the subject to some other DD somewhere else
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that >>>>>>>>>>>> article before or when HHH
That paper and its code are the only thing that I have been >>>>>>>>>>> talking about in this forum for several years.
Doesn't matter when you don't say that you are talking about that >>>>>>>>>> paper.
Anyway, that is irrelevant to the fact that the subject line >>>>>>>>>> contains a false claim.
It is a truism and not one person on the face of the Earth can >>>>>>>>> possibly show otherwise.
The fact that the claim on subject line is false is not a truism. >>>>>>>> In order to determine the claim is false one needs some knowledge >>>>>>>> that is not obvious.
When you try to show the steps attempting to show that it is false I >>>>>>> will point out the error.
Step 1: Find people who know C.
Step 2: Show them DD of OP and ask.
This is the only topic that I will discuss and any
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that HHH >>>> does not return 0. If it does DD also returns 0.
then
anyone with sufficient knowledge of C programming knows that no instance >>> of DD shown above simulated by any corresponding instance of HHH can
possibly terminate normally.
Well, then that corresponding (by what?) HHH isn’t a decider.
Technically a decider is any TM that always stops running. https://en.wikipedia.org/wiki/Decider_(Turing_machine)
I am focusing on the isomorphic notion of a termination analyzer.
A simulating termination analyzer correctly rejects any input
that must be aborted to prevent its own non-termination.
On 2/16/2025 2:02 PM, joes wrote:What’s confusing about „halts”? I find it clearer as it does not imply
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".(There are other deciders that are not termination analysers.)I am focusing on the isomorphic notion of a termination analyzer.such as one that calls a non-aborting version of HHHWhen we are referring to the above DD simulated by HHH and notDD correctly simulated by HHH cannot possibly terminate normally. >>>>>>That claim has already shown to be false. Nothing above shows that >>>>>> HHH does not return 0. If it does DD also returns 0.
trying to get away with changing the subject to some other DD
somewhere else
then anyone with sufficient knowledge of C programming knows that no >>>>> instance of DD shown above simulated by any corresponding instanceWell, then that corresponding (by what?) HHH isn’t a decider.
of HHH can possibly terminate normally.
A simulating termination analyzer correctly rejects any input thatYes, in particular itself is not such an input, because we *know* that
must be aborted to prevent its own non-termination.
it halts, because it is a decider. You can’t have your cake and eat it
too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally.
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:such as one that calls a non-aborting version of HHH
On 2025-02-14 12:40:04 +0000, olcott said:When we are referring to the above DD simulated by HHH and not trying to >>> get away with changing the subject to some other DD somewhere else
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that >>>>>>>>>>>> article before or when HHH
That paper and its code are the only thing that I have been >>>>>>>>>>> talking about in this forum for several years.
Doesn't matter when you don't say that you are talking about that >>>>>>>>>> paper.
Anyway, that is irrelevant to the fact that the subject line >>>>>>>>>> contains a false claim.
It is a truism and not one person on the face of the Earth can >>>>>>>>> possibly show otherwise.
The fact that the claim on subject line is false is not a truism. >>>>>>>> In order to determine the claim is false one needs some knowledge >>>>>>>> that is not obvious.
When you try to show the steps attempting to show that it is false I >>>>>>> will point out the error.
Step 1: Find people who know C.
Step 2: Show them DD of OP and ask.
This is the only topic that I will discuss and any
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that HHH >>>> does not return 0. If it does DD also returns 0.
then
anyone with sufficient knowledge of C programming knows that no instance >>> of DD shown above simulated by any corresponding instance of HHH can
possibly terminate normally.
Well, then that corresponding (by what?) HHH isn’t a decider.
Technically a decider is any TM that always stops running. https://en.wikipedia.org/wiki/Decider_(Turing_machine)
I am focusing on the isomorphic notion of a termination analyzer.
A simulating termination analyzer correctly rejects any input
that must be aborted to prevent its own non-termination.
On 2/16/2025 4:30 PM, joes wrote:
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:What’s confusing about „halts”? I find it clearer as it does not imply >> an ambiguous „abnormal termination”. How does HHH simulate DD
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".(There are other deciders that are not termination analysers.)I am focusing on the isomorphic notion of a termination analyzer.such as one that calls a non-aborting version of HHHWhen we are referring to the above DD simulated by HHH and notDD correctly simulated by HHH cannot possibly terminate normally. >>>>>>>>That claim has already shown to be false. Nothing above shows that >>>>>>>> HHH does not return 0. If it does DD also returns 0.
trying to get away with changing the subject to some other DD
somewhere else
then anyone with sufficient knowledge of C programming knows that no >>>>>>> instance of DD shown above simulated by any corresponding instance >>>>>>> of HHH can possibly terminate normally.Well, then that corresponding (by what?) HHH isn’t a decider.
A simulating termination analyzer correctly rejects any input thatYes, in particular itself is not such an input, because we *know* that >>>> it halts, because it is a decider. You can’t have your cake and eat it >>>> too.
must be aborted to prevent its own non-termination.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally.
terminating abnormally, then? Why doesn’t it terminate abnormally
itself?
You can substitute the term: the input DD to HHH does not need to be
aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
On 2/16/2025 2:02 PM, joes wrote:
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am focusing on the isomorphic notion of a termination analyzer.Well, then that corresponding (by what?) HHH isn’t a decider.When we are referring to the above DD simulated by HHH and not trying >>>>> to get away with changing the subject to some other DD somewhere else >>>> such as one that calls a non-aborting version of HHHThat claim has already shown to be false. Nothing above shows that >>>>>> HHH does not return 0. If it does DD also returns 0.typedef void (*ptr)();This is the only topic that I will discuss and any
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly simulated by HHH cannot possibly terminate normally. >>>>>>
then anyone with sufficient knowledge of C programming knows that no >>>>> instance of DD shown above simulated by any corresponding instance of >>>>> HHH can possibly terminate normally.
(There are other deciders that are not termination analysers.)
A simulating termination analyzer correctly rejects any input that mustYes, in particular itself is not such an input, because we *know* that
be aborted to prevent its own non-termination.
it halts, because it is a decider. You can’t have your cake and eat it
too.
I am not even using the confusing term "halts".
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally.
On 2/16/2025 7:08 PM, Richard Damon wrote:
On 2/16/25 5:08 PM, olcott wrote:
On 2/16/2025 3:52 PM, Richard Damon wrote:
On 2/16/25 2:24 PM, olcott wrote:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:When we are referring to the above DD simulated by HHH and not
On 2/14/2025 2:58 AM, Mikko wrote:That claim has already shown to be false. Nothing above shows
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Of course not. However, the fact that no reference to that >>>>>>>>>>>>>>>> article before or when HHH
That paper and its code are the only thing that I have been >>>>>>>>>>>>>>> talking about in this forum for several years.
Doesn't matter when you don't say that you are talking >>>>>>>>>>>>>> about that
paper.
Anyway, that is irrelevant to the fact that the subject line >>>>>>>>>>>>>> contains a false claim.
It is a truism and not one person on the face of the Earth can >>>>>>>>>>>>> possibly show otherwise.
The fact that the claim on subject line is false is not a >>>>>>>>>>>> truism.
In order to determine the claim is false one needs some >>>>>>>>>>>> knowledge
that is not obvious.
When you try to show the steps attempting to show that it is >>>>>>>>>>> false I
will point out the error.
Step 1: Find people who know C.
Step 2: Show them DD of OP and ask.
This is the only topic that I will discuss and any
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly simulated by HHH cannot possibly terminate normally. >>>>>>>>
that HHH
does not return 0. If it does DD also returns 0.
trying to
get away with changing the subject to some other DD somewhere else >>>>>> such as one that calls a non-aborting version of HHH
then
anyone with sufficient knowledge of C programming knows that no
instance
of DD shown above simulated by any corresponding instance of HHH can >>>>>>> possibly terminate normally.
Well, then that corresponding (by what?) HHH isn’t a decider.
Technically a decider is any TM that always stops running.
https://en.wikipedia.org/wiki/Decider_(Turing_machine)
I am focusing on the isomorphic notion of a termination analyzer.
A simulating termination analyzer correctly rejects any input
that must be aborted to prevent its own non-termination.
Right, but the answer given by the decider must match the problem.
Any divergence from the above specification is stipulated
to be incorrect.
In other words, you are ADMITTING you have no idea of the actual
problem, and think people are interested in your strawman.
The WORLD will reject any divergence from the actual specification,
leaving you out in the dark just admitting you are a moron.
*This is the pathological input termination analyzer problem*
Some people might see this as isomorphic to other problems
and some people may not see this.
In other words, you are just now admitting you have been LYING for
decades, because you were too stupid to understand what you were
claiming you were working.
Glad you finally admitted it.
The POOP theory is admitted to be just a pile of shit that you made
up, and says NOTHING about the real Halting Problem that you are
admitting is too "complecated" for you to undetstand.
Sorry, that is the facts of what you just said.
I am stipulating that I have solved the simulating
termination analyzer pathological input problem.
Some people will see a remarkable similarity to the
halting problem proofs, and some will not.
On 2/17/2025 5:57 AM, Richard Damon wrote:
On 2/16/25 11:43 PM, olcott wrote:
On 2/16/2025 7:08 PM, Richard Damon wrote:
On 2/16/25 5:08 PM, olcott wrote:
On 2/16/2025 3:52 PM, Richard Damon wrote:
On 2/16/25 2:24 PM, olcott wrote:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:When we are referring to the above DD simulated by HHH and not >>>>>>>>> trying to
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
Doesn't matter when you don't say that you are talking >>>>>>>>>>>>>>>> about thatOf course not. However, the fact that no reference to >>>>>>>>>>>>>>>>>> that
article before or when HHH
That paper and its code are the only thing that I have >>>>>>>>>>>>>>>>> been
talking about in this forum for several years. >>>>>>>>>>>>>>>>
paper.
Anyway, that is irrelevant to the fact that the subject >>>>>>>>>>>>>>>> line
contains a false claim.
It is a truism and not one person on the face of the >>>>>>>>>>>>>>> Earth can
possibly show otherwise.
The fact that the claim on subject line is false is not a >>>>>>>>>>>>>> truism.
In order to determine the claim is false one needs some >>>>>>>>>>>>>> knowledge
that is not obvious.
When you try to show the steps attempting to show that it >>>>>>>>>>>>> is false I
will point out the error.
Step 1: Find people who know C.
Step 2: Show them DD of OP and ask.
This is the only topic that I will discuss and any
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>> normally.
That claim has already shown to be false. Nothing above shows >>>>>>>>>> that HHH
does not return 0. If it does DD also returns 0.
get away with changing the subject to some other DD somewhere else >>>>>>>> such as one that calls a non-aborting version of HHH
then
anyone with sufficient knowledge of C programming knows that no >>>>>>>>> instance
of DD shown above simulated by any corresponding instance of >>>>>>>>> HHH can
possibly terminate normally.
Well, then that corresponding (by what?) HHH isn’t a decider. >>>>>>>>
Technically a decider is any TM that always stops running.
https://en.wikipedia.org/wiki/Decider_(Turing_machine)
I am focusing on the isomorphic notion of a termination analyzer. >>>>>>> A simulating termination analyzer correctly rejects any input
that must be aborted to prevent its own non-termination.
Right, but the answer given by the decider must match the problem. >>>>>>
Any divergence from the above specification is stipulated
to be incorrect.
In other words, you are ADMITTING you have no idea of the actual
problem, and think people are interested in your strawman.
The WORLD will reject any divergence from the actual specification,
leaving you out in the dark just admitting you are a moron.
*This is the pathological input termination analyzer problem*
Some people might see this as isomorphic to other problems
and some people may not see this.
In other words, you are just now admitting you have been LYING for
decades, because you were too stupid to understand what you were
claiming you were working.
Glad you finally admitted it.
The POOP theory is admitted to be just a pile of shit that you made
up, and says NOTHING about the real Halting Problem that you are
admitting is too "complecated" for you to undetstand.
Sorry, that is the facts of what you just said.
I am stipulating that I have solved the simulating
termination analyzer pathological input problem.
Then stop saying your answer apply to the halting problem.
Some people may understand that the above problem seems isomorphic
to the conventional halting problem proofs and some will not.
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:What’s confusing about „halts”? I find it clearer as it does not imply
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".(There are other deciders that are not termination analysers.)I am focusing on the isomorphic notion of a termination analyzer.such as one that calls a non-aborting version of HHHWhen we are referring to the above DD simulated by HHH and not >>>>>>>> trying to get away with changing the subject to some other DDDD correctly simulated by HHH cannot possibly terminate normally. >>>>>>>>>That claim has already shown to be false. Nothing above shows that >>>>>>>>> HHH does not return 0. If it does DD also returns 0.
somewhere else
then anyone with sufficient knowledge of C programming knows that no >>>>>>>> instance of DD shown above simulated by any corresponding instance >>>>>>>> of HHH can possibly terminate normally.Well, then that corresponding (by what?) HHH isn’t a decider.
A simulating termination analyzer correctly rejects any input that >>>>>> must be aborted to prevent its own non-termination.Yes, in particular itself is not such an input, because we *know* that >>>>> it halts, because it is a decider. You can’t have your cake and eat it >>>>> too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally.
an ambiguous „abnormal termination”. How does HHH simulate DD
terminating abnormally, then? Why doesn’t it terminate abnormally
itself?
You can substitute the term: the input DD to HHH does not need to be
aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:What’s confusing about „halts”? I find it clearer as it does not imply
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".Yes, in particular itself is not such an input, because we *know* >>>>>>> thatsuch as one that calls a non-aborting version of HHHWhen we are referring to the above DD simulated by HHH and not >>>>>>>>>> trying to get away with changing the subject to some other DD >>>>>>>>>> somewhere elseDD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>>> normally.
That claim has already shown to be false. Nothing above shows >>>>>>>>>>> that
HHH does not return 0. If it does DD also returns 0.
then anyone with sufficient knowledge of C programming knows >>>>>>>>>> that noWell, then that corresponding (by what?) HHH isn’t a decider. >>>>>>>> I am focusing on the isomorphic notion of a termination analyzer. >>>>>>> (There are other deciders that are not termination analysers.)
instance of DD shown above simulated by any corresponding
instance
of HHH can possibly terminate normally.
A simulating termination analyzer correctly rejects any input that >>>>>>>> must be aborted to prevent its own non-termination.
it halts, because it is a decider. You can’t have your cake and >>>>>>> eat it
too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally.
an ambiguous „abnormal termination”. How does HHH simulate DD
terminating abnormally, then? Why doesn’t it terminate abnormally
itself?
You can substitute the term: the input DD to HHH does not need to be >>>>> aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
It merely means that the words do not have their ordinary meaning.
Unless HHH(DD) aborts its simulation of DD itself cannot possibly
terminate normally. Every expert in the C programming language
can see this. People that are not experts get confused by the loop
after the "if" statement.
On 2/18/2025 6:25 AM, Richard Damon wrote:I mean, this is a deterministic program without any static variables,
On 2/18/25 6:26 AM, olcott wrote:Not at all.
On 2/18/2025 3:24 AM, Mikko wrote:So? Since it does that, it needs to presume that the copy of itself it
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:Unless HHH(DD) aborts its simulation of DD itself cannot possibly
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:Every simulated input that must be aborted to prevent the
On 2/16/2025 2:02 PM, joes wrote:abnormally itself?
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".(There are other deciders that are not termination analysers.) >>>>>>>>>analyzer.such as one that calls a non-aborting version of HHHWhen we are referring to the above DD simulated by HHH and >>>>>>>>>>>> not trying to get away with changing the subject to some >>>>>>>>>>>> other DD somewhere elseDD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>>>>> normally.
That claim has already shown to be false. Nothing above >>>>>>>>>>>>> shows that HHH does not return 0. If it does DD also returns >>>>>>>>>>>>> 0.
then anyone with sufficient knowledge of C programming knows >>>>>>>>>>>> that no instance of DD shown above simulated by anyWell, then that corresponding (by what?) HHH isn’t a decider. >>>>>>>>>> I am focusing on the isomorphic notion of a termination
corresponding instance of HHH can possibly terminate
normally.
A simulating termination analyzer correctly rejects any input >>>>>>>>>> that must be aborted to prevent its own non-termination.Yes, in particular itself is not such an input, because we
*know* that it halts, because it is a decider. You can’t have >>>>>>>>> your cake and eat it too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally. >>>>>>> What’s confusing about „halts”? I find it clearer as it does not >>>>>>> imply an ambiguous „abnormal termination”. How does HHH simulate >>>>>>> DD terminating abnormally, then? Why doesn’t it terminate
You can substitute the term: the input DD to HHH does not need to >>>>>>> be aborted, because the simulated decider terminates.
non-termination of HHH is stipulated to be correctly rejected by
HHH as non-terminating.
It merely means that the words do not have their ordinary meaning.
terminate normally. Every expert in the C programming language can see
this. People that are not experts get confused by the loop after the
"if" statement.
sees called does that.
Here is the point that you just missed Unless the first HHH that sees--
the non-terminating pattern aborts its simulation none of them do
because they all have the exact same code.
On 2/18/2025 6:25 AM, Richard Damon wrote:
On 2/18/25 6:26 AM, olcott wrote:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:an ambiguous „abnormal termination”. How does HHH simulate DD >>>>>>> terminating abnormally, then? Why doesn’t it terminate abnormally >>>>>>> itself?
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".Yes, in particular itself is not such an input, because weA simulating termination analyzer correctly rejects any input >>>>>>>>>> thatsuch as one that calls a non-aborting version of HHHWhen we are referring to the above DD simulated by HHH and not >>>>>>>>>>>> trying to get away with changing the subject to some other DD >>>>>>>>>>>> somewhere elseDD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>>>>> normally.
That claim has already shown to be false. Nothing above >>>>>>>>>>>>> shows that
HHH does not return 0. If it does DD also returns 0.
then anyone with sufficient knowledge of C programming knows >>>>>>>>>>>> that noWell, then that corresponding (by what?) HHH isn’t a decider. >>>>>>>>>> I am focusing on the isomorphic notion of a termination analyzer. >>>>>>>>> (There are other deciders that are not termination analysers.) >>>>>>>>>
instance of DD shown above simulated by any corresponding >>>>>>>>>>>> instance
of HHH can possibly terminate normally.
must be aborted to prevent its own non-termination.
*know* that
it halts, because it is a decider. You can’t have your cake and >>>>>>>>> eat it
too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally. >>>>>>> What’s confusing about „halts”? I find it clearer as it does not >>>>>>> imply
You can substitute the term: the input DD to HHH does not need to be >>>>>>> aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
It merely means that the words do not have their ordinary meaning.
Unless HHH(DD) aborts its simulation of DD itself cannot possibly
terminate normally. Every expert in the C programming language
can see this. People that are not experts get confused by the loop
after the "if" statement.
So? Since it does that, it needs to presume that the copy of itself it
sees called does that.
Not at all. Perhaps your technical skill is much more woefully
deficient than I ever imagined.
Here is the point that you just missed Unless the first HHH
that sees the non-terminating pattern aborts its simulation
none of them do because they all have the exact same code.
On 2/18/2025 6:25 AM, Richard Damon wrote:
On 2/18/25 6:26 AM, olcott wrote:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:an ambiguous „abnormal termination”. How does HHH simulate DD >>>>>>> terminating abnormally, then? Why doesn’t it terminate abnormally >>>>>>> itself?
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".Yes, in particular itself is not such an input, because weA simulating termination analyzer correctly rejects any input >>>>>>>>>> thatsuch as one that calls a non-aborting version of HHHWhen we are referring to the above DD simulated by HHH and not >>>>>>>>>>>> trying to get away with changing the subject to some other DD >>>>>>>>>>>> somewhere elseDD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>>>>> normally.
That claim has already shown to be false. Nothing above >>>>>>>>>>>>> shows that
HHH does not return 0. If it does DD also returns 0.
then anyone with sufficient knowledge of C programming knows >>>>>>>>>>>> that noWell, then that corresponding (by what?) HHH isn’t a decider. >>>>>>>>>> I am focusing on the isomorphic notion of a termination analyzer. >>>>>>>>> (There are other deciders that are not termination analysers.) >>>>>>>>>
instance of DD shown above simulated by any corresponding >>>>>>>>>>>> instance
of HHH can possibly terminate normally.
must be aborted to prevent its own non-termination.
*know* that
it halts, because it is a decider. You can’t have your cake and >>>>>>>>> eat it
too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally. >>>>>>> What’s confusing about „halts”? I find it clearer as it does not >>>>>>> imply
You can substitute the term: the input DD to HHH does not need to be >>>>>>> aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
It merely means that the words do not have their ordinary meaning.
Unless HHH(DD) aborts its simulation of DD itself cannot possibly
terminate normally. Every expert in the C programming language
can see this. People that are not experts get confused by the loop
after the "if" statement.
So? Since it does that, it needs to presume that the copy of itself it
sees called does that.
Not at all. Perhaps your technical skill is much more woefully
deficient than I ever imagined.
Here is the point that you just missed Unless the first HHH
that sees the non-terminating pattern aborts its simulation
none of them do because they all have the exact same code.
On 2/18/2025 5:32 PM, Richard Damon wrote:That’s what he said.
On 2/18/25 8:37 AM, olcott wrote:Unless THE FIRST ONE THAT SEES IT DOES IT NONE OF THEM DO
On 2/18/2025 6:25 AM, Richard Damon wrote:And you miss, that since the first does it, all of them do it,
On 2/18/25 6:26 AM, olcott wrote:Not at all. Perhaps your technical skill is much more woefully
On 2/18/2025 3:24 AM, Mikko wrote:So? Since it does that, it needs to presume that the copy of itself
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:Unless HHH(DD) aborts its simulation of DD itself cannot possibly
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:Every simulated input that must be aborted to prevent the
On 2/16/2025 2:02 PM, joes wrote:What’s confusing about „halts”? I find it clearer as it does not
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".(There are other deciders that are not termination analysers.) >>>>>>>>>>>I am focusing on the isomorphic notion of a termination >>>>>>>>>>>> analyzer.such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>When we are referring to the above DD simulated by HHH and >>>>>>>>>>>>>> not trying to get away with changing the subject to some >>>>>>>>>>>>>> other DD somewhere elseDD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>>>>>>> normally.
That claim has already shown to be false. Nothing above >>>>>>>>>>>>>>> shows that HHH does not return 0. If it does DD also >>>>>>>>>>>>>>> returns 0.
then anyone with sufficient knowledge of C programming >>>>>>>>>>>>>> knows that no instance of DD shown above simulated by any >>>>>>>>>>>>>> corresponding instance of HHH can possibly terminate >>>>>>>>>>>>>> normally.Well, then that corresponding (by what?) HHH isn’t a >>>>>>>>>>>>> decider.
A simulating termination analyzer correctly rejects any input >>>>>>>>>>>> that must be aborted to prevent its own non-termination. >>>>>>>>>>> Yes, in particular itself is not such an input, because we >>>>>>>>>>> *know* that it halts, because it is a decider. You can’t have >>>>>>>>>>> your cake and eat it too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate
normally.
imply an ambiguous „abnormal termination”. How does HHH simulate >>>>>>>>> DD terminating abnormally, then? Why doesn’t it terminate
abnormally itself?
You can substitute the term: the input DD to HHH does not need >>>>>>>>> to be aborted, because the simulated decider terminates.
non-termination of HHH is stipulated to be correctly rejected by >>>>>>>> HHH as non-terminating.
It merely means that the words do not have their ordinary meaning. >>>>>>
terminate normally. Every expert in the C programming language can
see this. People that are not experts get confused by the loop after >>>>> the "if" statement.
it sees called does that.
deficient than I ever imagined.
Here is the point that you just missed Unless the first HHH that sees
the non-terminating pattern aborts its simulation none of them do
because they all have the exact same code.
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:What’s confusing about „halts”? I find it clearer as it does not imply
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".Yes, in particular itself is not such an input, because we *know* that >>>>>>> it halts, because it is a decider. You can’t have your cake and eat itsuch as one that calls a non-aborting version of HHHWhen we are referring to the above DD simulated by HHH and not >>>>>>>>>> trying to get away with changing the subject to some other DD >>>>>>>>>> somewhere elseDD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that >>>>>>>>>>> HHH does not return 0. If it does DD also returns 0.
then anyone with sufficient knowledge of C programming knows that no >>>>>>>>>> instance of DD shown above simulated by any corresponding instance >>>>>>>>>> of HHH can possibly terminate normally.Well, then that corresponding (by what?) HHH isn’t a decider. >>>>>>>> I am focusing on the isomorphic notion of a termination analyzer. >>>>>>> (There are other deciders that are not termination analysers.)
A simulating termination analyzer correctly rejects any input that >>>>>>>> must be aborted to prevent its own non-termination.
too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally.
an ambiguous „abnormal termination”. How does HHH simulate DD
terminating abnormally, then? Why doesn’t it terminate abnormally
itself?
You can substitute the term: the input DD to HHH does not need to be >>>>> aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
It merely means that the words do not have their ordinary meaning.
Unless HHH(DD) aborts its simulation of DD itself cannot possibly
terminate normally.
Every expert in the C programming language can see this.
On 2/18/2025 5:32 PM, Richard Damon wrote:
On 2/18/25 8:37 AM, olcott wrote:Unless THE FIRST ONE THAT SEES IT DOES IT NONE OF THEM DO
On 2/18/2025 6:25 AM, Richard Damon wrote:
On 2/18/25 6:26 AM, olcott wrote:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:an ambiguous „abnormal termination”. How does HHH simulate DD >>>>>>>>> terminating abnormally, then? Why doesn’t it terminate abnormally >>>>>>>>> itself?
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".(There are other deciders that are not termination analysers.) >>>>>>>>>>>such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>trying to get away with changing the subject to some other DD >>>>>>>>>>>>>> somewhere elseDD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>>>>>>> normally.
That claim has already shown to be false. Nothing above >>>>>>>>>>>>>>> shows that
HHH does not return 0. If it does DD also returns 0. >>>>>>>>>>>>>> When we are referring to the above DD simulated by HHH and >>>>>>>>>>>>>> not
then anyone with sufficient knowledge of C programming >>>>>>>>>>>>>> knows that noWell, then that corresponding (by what?) HHH isn’t a decider. >>>>>>>>>>>> I am focusing on the isomorphic notion of a termination >>>>>>>>>>>> analyzer.
instance of DD shown above simulated by any corresponding >>>>>>>>>>>>>> instance
of HHH can possibly terminate normally.
A simulating termination analyzer correctly rejects any >>>>>>>>>>>> input thatYes, in particular itself is not such an input, because we >>>>>>>>>>> *know* that
must be aborted to prevent its own non-termination.
it halts, because it is a decider. You can’t have your cake >>>>>>>>>>> and eat it
too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally. >>>>>>>>> What’s confusing about „halts”? I find it clearer as it does >>>>>>>>> not imply
You can substitute the term: the input DD to HHH does not need >>>>>>>>> to be
aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
It merely means that the words do not have their ordinary meaning. >>>>>>
Unless HHH(DD) aborts its simulation of DD itself cannot possibly
terminate normally. Every expert in the C programming language
can see this. People that are not experts get confused by the loop
after the "if" statement.
So? Since it does that, it needs to presume that the copy of itself
it sees called does that.
Not at all. Perhaps your technical skill is much more woefully
deficient than I ever imagined.
Here is the point that you just missed Unless the first HHH
that sees the non-terminating pattern aborts its simulation
none of them do because they all have the exact same code.
And you miss, that since the first does it, all of them do it,
On 2/19/2025 3:01 AM, Mikko wrote:
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:an ambiguous „abnormal termination”. How does HHH simulate DD >>>>>>> terminating abnormally, then? Why doesn’t it terminate abnormally >>>>>>> itself?
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".Yes, in particular itself is not such an input, because weA simulating termination analyzer correctly rejects any input >>>>>>>>>> thatsuch as one that calls a non-aborting version of HHHWhen we are referring to the above DD simulated by HHH and not >>>>>>>>>>>> trying to get away with changing the subject to some other DD >>>>>>>>>>>> somewhere elseDD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>>>>> normally.
That claim has already shown to be false. Nothing above >>>>>>>>>>>>> shows that
HHH does not return 0. If it does DD also returns 0.
then anyone with sufficient knowledge of C programming knows >>>>>>>>>>>> that noWell, then that corresponding (by what?) HHH isn’t a decider. >>>>>>>>>> I am focusing on the isomorphic notion of a termination analyzer. >>>>>>>>> (There are other deciders that are not termination analysers.) >>>>>>>>>
instance of DD shown above simulated by any corresponding >>>>>>>>>>>> instance
of HHH can possibly terminate normally.
must be aborted to prevent its own non-termination.
*know* that
it halts, because it is a decider. You can’t have your cake and >>>>>>>>> eat it
too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally. >>>>>>> What’s confusing about „halts”? I find it clearer as it does not >>>>>>> imply
You can substitute the term: the input DD to HHH does not need to be >>>>>>> aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
It merely means that the words do not have their ordinary meaning.
Unless HHH(DD) aborts its simulation of DD itself cannot possibly
terminate normally.
That cannot be determined without examination of HHH, which is not in the
scope of OP.
I have given everyone here all of the complete source
code for a few years
918-1156 // All of the lines of termination analyzer HHH
1355-1370 // DD() through main()
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Every expert in the C programming language can see this.
They can't when they can't see HHH and even then it is not obvious,
so the claim on the subject line is false.
On 2/19/2025 3:01 AM, Mikko wrote:
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:an ambiguous „abnormal termination”. How does HHH simulate DD >>>>>>> terminating abnormally, then? Why doesn’t it terminate abnormally >>>>>>> itself?
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".Yes, in particular itself is not such an input, because we *know* thatA simulating termination analyzer correctly rejects any input that >>>>>>>>>> must be aborted to prevent its own non-termination.such as one that calls a non-aborting version of HHHWhen we are referring to the above DD simulated by HHH and not >>>>>>>>>>>> trying to get away with changing the subject to some other DD >>>>>>>>>>>> somewhere elseDD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that
HHH does not return 0. If it does DD also returns 0.
then anyone with sufficient knowledge of C programming knows that noWell, then that corresponding (by what?) HHH isn’t a decider. >>>>>>>>>> I am focusing on the isomorphic notion of a termination analyzer. >>>>>>>>> (There are other deciders that are not termination analysers.) >>>>>>>>>
instance of DD shown above simulated by any corresponding instance >>>>>>>>>>>> of HHH can possibly terminate normally.
it halts, because it is a decider. You can’t have your cake and eat it
too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally. >>>>>>> What’s confusing about „halts”? I find it clearer as it does not imply
You can substitute the term: the input DD to HHH does not need to be >>>>>>> aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
It merely means that the words do not have their ordinary meaning.
Unless HHH(DD) aborts its simulation of DD itself cannot possibly
terminate normally.
That cannot be determined without examination of HHH, which is not in the
scope of OP.
I have given everyone here all of the complete source
code for a few years
On 2/19/2025 3:01 AM, Mikko wrote:
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:an ambiguous „abnormal termination”. How does HHH simulate DD >>>>>>> terminating abnormally, then? Why doesn’t it terminate abnormally >>>>>>> itself?
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".Yes, in particular itself is not such an input, because we *know* thatA simulating termination analyzer correctly rejects any input that >>>>>>>>>> must be aborted to prevent its own non-termination.such as one that calls a non-aborting version of HHHWhen we are referring to the above DD simulated by HHH and not >>>>>>>>>>>> trying to get away with changing the subject to some other DD >>>>>>>>>>>> somewhere elseDD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that
HHH does not return 0. If it does DD also returns 0.
then anyone with sufficient knowledge of C programming knows that noWell, then that corresponding (by what?) HHH isn’t a decider. >>>>>>>>>> I am focusing on the isomorphic notion of a termination analyzer. >>>>>>>>> (There are other deciders that are not termination analysers.) >>>>>>>>>
instance of DD shown above simulated by any corresponding instance >>>>>>>>>>>> of HHH can possibly terminate normally.
it halts, because it is a decider. You can’t have your cake and eat it
too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally. >>>>>>> What’s confusing about „halts”? I find it clearer as it does not imply
You can substitute the term: the input DD to HHH does not need to be >>>>>>> aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
It merely means that the words do not have their ordinary meaning.
Unless HHH(DD) aborts its simulation of DD itself cannot possibly
terminate normally.
That cannot be determined without examination of HHH, which is not in the
scope of OP.
I have given everyone here all of the complete source
code for a few years
On 2/19/2025 3:01 AM, Mikko wrote:Why won’t you talk about what line 1059 does? https://github.com/plolcott/x86utm/blob/ 48b4cbfeb3f486507276a5fc4e9b10875ab24dbf/Halt7.c#L1059
On 2025-02-18 11:26:25 +0000, olcott said:I have given everyone here all of the complete source code for a few
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:Unless HHH(DD) aborts its simulation of DD itself cannot possibly
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:Every simulated input that must be aborted to prevent the
On 2/16/2025 2:02 PM, joes wrote:abnormally itself?
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said:
On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".(There are other deciders that are not termination analysers.) >>>>>>>>>analyzer.such as one that calls a non-aborting version of HHHWhen we are referring to the above DD simulated by HHH and >>>>>>>>>>>> not trying to get away with changing the subject to some >>>>>>>>>>>> other DD somewhere elseDD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>>>>> normally.
That claim has already shown to be false. Nothing above >>>>>>>>>>>>> shows that HHH does not return 0. If it does DD also returns >>>>>>>>>>>>> 0.
then anyone with sufficient knowledge of C programming knows >>>>>>>>>>>> that no instance of DD shown above simulated by anyWell, then that corresponding (by what?) HHH isn’t a decider. >>>>>>>>>> I am focusing on the isomorphic notion of a termination
corresponding instance of HHH can possibly terminate
normally.
A simulating termination analyzer correctly rejects any input >>>>>>>>>> that must be aborted to prevent its own non-termination.Yes, in particular itself is not such an input, because we
*know* that it halts, because it is a decider. You can’t have >>>>>>>>> your cake and eat it too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally. >>>>>>> What’s confusing about „halts”? I find it clearer as it does not >>>>>>> imply an ambiguous „abnormal termination”. How does HHH simulate >>>>>>> DD terminating abnormally, then? Why doesn’t it terminate
You can substitute the term: the input DD to HHH does not need to >>>>>>> be aborted, because the simulated decider terminates.
non-termination of HHH is stipulated to be correctly rejected by
HHH as non-terminating.
It merely means that the words do not have their ordinary meaning.
terminate normally.
That cannot be determined without examination of HHH, which is not in
the scope of OP.
years
918-1156 // All of the lines of termination analyzer HHH https://github.com/plolcott/x86utm/blob/master/Halt7.c
--Every expert in the C programming language can see this.They can't when they can't see HHH and even then it is not obvious,
so the claim on the subject line is false.
On 2/20/2025 2:38 AM, Mikko wrote:
On 2025-02-20 00:31:33 +0000, olcott said:
I have given everyone here all of the complete source code for a few
years
True but irrelevant. OP did not specify that HHH means that particular
code.
Every post that I have been talking about for two or
more years has referred to variations of that same code.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 2/20/2025 2:38 AM, Mikko wrote:
On 2025-02-20 00:31:33 +0000, olcott said:
On 2/19/2025 3:01 AM, Mikko wrote:
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:an ambiguous „abnormal termination”. How does HHH simulate DD >>>>>>>>> terminating abnormally, then? Why doesn’t it terminate abnormally >>>>>>>>> itself?
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".(There are other deciders that are not termination analysers.) >>>>>>>>>>>such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>trying to get away with changing the subject to some other DD >>>>>>>>>>>>>> somewhere elseDD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>>>>>>> normally.
That claim has already shown to be false. Nothing above >>>>>>>>>>>>>>> shows that
HHH does not return 0. If it does DD also returns 0. >>>>>>>>>>>>>> When we are referring to the above DD simulated by HHH and >>>>>>>>>>>>>> not
then anyone with sufficient knowledge of C programming >>>>>>>>>>>>>> knows that noWell, then that corresponding (by what?) HHH isn’t a decider. >>>>>>>>>>>> I am focusing on the isomorphic notion of a termination >>>>>>>>>>>> analyzer.
instance of DD shown above simulated by any corresponding >>>>>>>>>>>>>> instance
of HHH can possibly terminate normally.
A simulating termination analyzer correctly rejects any >>>>>>>>>>>> input thatYes, in particular itself is not such an input, because we >>>>>>>>>>> *know* that
must be aborted to prevent its own non-termination.
it halts, because it is a decider. You can’t have your cake >>>>>>>>>>> and eat it
too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally. >>>>>>>>> What’s confusing about „halts”? I find it clearer as it does >>>>>>>>> not imply
You can substitute the term: the input DD to HHH does not need >>>>>>>>> to be
aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
It merely means that the words do not have their ordinary meaning.
Those two comments are not discussed below.
Unless HHH(DD) aborts its simulation of DD itself cannot possibly
terminate normally.
That cannot be determined without examination of HHH, which is not
in the
scope of OP.
I have given everyone here all of the complete source
code for a few years
True but irrelevant. OP did not specify that HHH means that particular
code.
Every post that I have been talking about for two or
more years has referred to variations of that same code.
On 2/20/2025 2:38 AM, Mikko wrote:
On 2025-02-20 00:31:33 +0000, olcott said:
On 2/19/2025 3:01 AM, Mikko wrote:
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:an ambiguous „abnormal termination”. How does HHH simulate DD >>>>>>>>> terminating abnormally, then? Why doesn’t it terminate abnormally >>>>>>>>> itself?
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".Yes, in particular itself is not such an input, because we *know* thatA simulating termination analyzer correctly rejects any input that >>>>>>>>>>>> must be aborted to prevent its own non-termination.such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>DD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that
HHH does not return 0. If it does DD also returns 0. >>>>>>>>>>>>>> When we are referring to the above DD simulated by HHH and not >>>>>>>>>>>>>> trying to get away with changing the subject to some other DD >>>>>>>>>>>>>> somewhere else
then anyone with sufficient knowledge of C programming knows that noWell, then that corresponding (by what?) HHH isn’t a decider. >>>>>>>>>>>> I am focusing on the isomorphic notion of a termination analyzer. >>>>>>>>>>> (There are other deciders that are not termination analysers.) >>>>>>>>>>>
instance of DD shown above simulated by any corresponding instance
of HHH can possibly terminate normally.
it halts, because it is a decider. You can’t have your cake and eat it
too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally. >>>>>>>>> What’s confusing about „halts”? I find it clearer as it does not imply
You can substitute the term: the input DD to HHH does not need to be >>>>>>>>> aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
It merely means that the words do not have their ordinary meaning.
Those two comments are not discussed below.
Unless HHH(DD) aborts its simulation of DD itself cannot possibly
terminate normally.
That cannot be determined without examination of HHH, which is not in the >>>> scope of OP.
I have given everyone here all of the complete source
code for a few years
True but irrelevant. OP did not specify that HHH means that particular
code.
Every post that I have been talking about for two or
more years has referred to variations of that same code.
On 2/21/2025 2:18 AM, Mikko wrote:
On 2025-02-20 21:31:44 +0000, olcott said:
On 2/20/2025 2:38 AM, Mikko wrote:
On 2025-02-20 00:31:33 +0000, olcott said:
On 2/19/2025 3:01 AM, Mikko wrote:Those two comments are not discussed below.
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:What’s confusing about „halts”? I find it clearer as it does >>>>>>>>>>> not imply
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott: >>>>>>>>>>>>>>>> On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said: >>>>>>>>>>>>>>>>>>>> On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".(There are other deciders that are not termination analysers.) >>>>>>>>>>>>>I am focusing on the isomorphic notion of a termination >>>>>>>>>>>>>> analyzer.such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>>>trying to get away with changing the subject to some >>>>>>>>>>>>>>>> other DDDD correctly simulated by HHH cannot possibly >>>>>>>>>>>>>>>>>> terminate normally.
That claim has already shown to be false. Nothing above >>>>>>>>>>>>>>>>> shows that
HHH does not return 0. If it does DD also returns 0. >>>>>>>>>>>>>>>> When we are referring to the above DD simulated by HHH >>>>>>>>>>>>>>>> and not
somewhere else
then anyone with sufficient knowledge of C programming >>>>>>>>>>>>>>>> knows that noWell, then that corresponding (by what?) HHH isn’t a >>>>>>>>>>>>>>> decider.
instance of DD shown above simulated by any
corresponding instance
of HHH can possibly terminate normally.
A simulating termination analyzer correctly rejects any >>>>>>>>>>>>>> input thatit halts, because it is a decider. You can’t have your cake >>>>>>>>>>>>> and eat it
must be aborted to prevent its own non-termination. >>>>>>>>>>>>> Yes, in particular itself is not such an input, because we >>>>>>>>>>>>> *know* that
too.
Instead I am using in its place "terminates normally". >>>>>>>>>>>> DD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>>> normally.
an ambiguous „abnormal termination”. How does HHH simulate DD >>>>>>>>>>> terminating abnormally, then? Why doesn’t it terminate >>>>>>>>>>> abnormally
itself?
You can substitute the term: the input DD to HHH does not >>>>>>>>>>> need to be
aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
It merely means that the words do not have their ordinary meaning. >>>>
Unless HHH(DD) aborts its simulation of DD itself cannot possibly >>>>>>> terminate normally.
That cannot be determined without examination of HHH, which is not >>>>>> in the
scope of OP.
I have given everyone here all of the complete source
code for a few years
True but irrelevant. OP did not specify that HHH means that particular >>>> code.
Every post that I have been talking about for two or
more years has referred to variations of that same code.
OP had a pointer of that code but didn's state that that code is a part
of the problem. OP did not spacify any range for variation.
I have only been talking about variations of the same code
as HHH(DD) for two years. Do you understand that one sentence?
On 2/21/2025 2:18 AM, Mikko wrote:
On 2025-02-20 21:31:44 +0000, olcott said:
On 2/20/2025 2:38 AM, Mikko wrote:
On 2025-02-20 00:31:33 +0000, olcott said:
On 2/19/2025 3:01 AM, Mikko wrote:Those two comments are not discussed below.
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:an ambiguous „abnormal termination”. How does HHH simulate DD >>>>>>>>>>> terminating abnormally, then? Why doesn’t it terminate abnormally >>>>>>>>>>> itself?
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott: >>>>>>>>>>>>>>>> On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said: >>>>>>>>>>>>>>>>>>>> On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".(There are other deciders that are not termination analysers.) >>>>>>>>>>>>>such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>>>DD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that
HHH does not return 0. If it does DD also returns 0. >>>>>>>>>>>>>>>> When we are referring to the above DD simulated by HHH and not >>>>>>>>>>>>>>>> trying to get away with changing the subject to some other DD >>>>>>>>>>>>>>>> somewhere else
then anyone with sufficient knowledge of C programming knows that noWell, then that corresponding (by what?) HHH isn’t a decider. >>>>>>>>>>>>>> I am focusing on the isomorphic notion of a termination analyzer.
instance of DD shown above simulated by any corresponding instance
of HHH can possibly terminate normally.
A simulating termination analyzer correctly rejects any input thatit halts, because it is a decider. You can’t have your cake and eat it
must be aborted to prevent its own non-termination. >>>>>>>>>>>>> Yes, in particular itself is not such an input, because we *know* that
too.
Instead I am using in its place "terminates normally". >>>>>>>>>>>> DD correctly simulated by HHH cannot possibly terminate normally. >>>>>>>>>>> What’s confusing about „halts”? I find it clearer as it does not imply
You can substitute the term: the input DD to HHH does not need to be
aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
It merely means that the words do not have their ordinary meaning. >>>>
Unless HHH(DD) aborts its simulation of DD itself cannot possibly >>>>>>> terminate normally.
That cannot be determined without examination of HHH, which is not in the
scope of OP.
I have given everyone here all of the complete source
code for a few years
True but irrelevant. OP did not specify that HHH means that particular >>>> code.
Every post that I have been talking about for two or
more years has referred to variations of that same code.
OP had a pointer of that code but didn's state that that code is a part
of the problem. OP did not spacify any range for variation.
I have only been talking about variations of the same code
as HHH(DD) for two years. Do you understand that one sentence?
On 2/20/2025 5:54 AM, joes wrote:Will you talk about it in a month or is that a deflection?
Am Wed, 19 Feb 2025 18:31:33 -0600 schrieb olcott:I may be dead in a month thus must proceed with the essence before
On 2/19/2025 3:01 AM, Mikko wrote:Why won’t you talk about what line 1059 does?
On 2025-02-18 11:26:25 +0000, olcott said:I have given everyone here all of the complete source code for a few
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:Unless HHH(DD) aborts its simulation of DD itself cannot possibly
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:Every simulated input that must be aborted to prevent the
On 2/16/2025 2:02 PM, joes wrote:What’s confusing about „halts”? I find it clearer as it does not
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:
On 2/16/2025 10:35 AM, joes wrote:
Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:
On 2/15/2025 2:49 AM, Mikko wrote:
On 2025-02-14 12:40:04 +0000, olcott said:
On 2/14/2025 2:58 AM, Mikko wrote:
On 2025-02-14 00:07:23 +0000, olcott said:
On 2/13/2025 3:20 AM, Mikko wrote:
On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote:
On 2025-02-11 14:41:38 +0000, olcott said:
I am not even using the confusing term "halts".(There are other deciders that are not termination analysers.) >>>>>>>>>>>I am focusing on the isomorphic notion of a termination >>>>>>>>>>>> analyzer.such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>When we are referring to the above DD simulated by HHH and >>>>>>>>>>>>>> not trying to get away with changing the subject to some >>>>>>>>>>>>>> other DD somewhere elseDD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>>>>>>> normally.
That claim has already shown to be false. Nothing above >>>>>>>>>>>>>>> shows that HHH does not return 0. If it does DD also >>>>>>>>>>>>>>> returns 0.
then anyone with sufficient knowledge of C programming >>>>>>>>>>>>>> knows that no instance of DD shown above simulated by any >>>>>>>>>>>>>> corresponding instance of HHH can possibly terminate >>>>>>>>>>>>>> normally.Well, then that corresponding (by what?) HHH isn’t a >>>>>>>>>>>>> decider.
A simulating termination analyzer correctly rejects any input >>>>>>>>>>>> that must be aborted to prevent its own non-termination. >>>>>>>>>>> Yes, in particular itself is not such an input, because we >>>>>>>>>>> *know* that it halts, because it is a decider. You can’t have >>>>>>>>>>> your cake and eat it too.
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate
normally.
imply an ambiguous „abnormal termination”. How does HHH simulate >>>>>>>>> DD terminating abnormally, then? Why doesn’t it terminate
abnormally itself?
You can substitute the term: the input DD to HHH does not need >>>>>>>>> to be aborted, because the simulated decider terminates.
non-termination of HHH is stipulated to be correctly rejected by >>>>>>>> HHH as non-terminating.
It merely means that the words do not have their ordinary meaning. >>>>>>
terminate normally.
That cannot be determined without examination of HHH, which is not in
the scope of OP.
years 918-1156 // All of the lines of termination analyzer HHH
https://github.com/plolcott/x86utm/blob/master/Halt7.c
getting into the details.
--https://github.com/plolcott/x86utm/blob/
48b4cbfeb3f486507276a5fc4e9b10875ab24dbf/Halt7.c#L1059
On 2/22/2025 3:04 AM, Mikko wrote:
On 2025-02-21 22:35:16 +0000, olcott said:
On 2/21/2025 2:18 AM, Mikko wrote:
On 2025-02-20 21:31:44 +0000, olcott said:
On 2/20/2025 2:38 AM, Mikko wrote:
On 2025-02-20 00:31:33 +0000, olcott said:
On 2/19/2025 3:01 AM, Mikko wrote:
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:What’s confusing about „halts”? I find it clearer as it >>>>>>>>>>>>> does not imply
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>> On 2/16/2025 10:35 AM, joes wrote:I am not even using the confusing term "halts".
(There are other deciders that are not termination >>>>>>>>>>>>>>> analysers.)Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>> On 2/15/2025 2:49 AM, Mikko wrote:I am focusing on the isomorphic notion of a termination >>>>>>>>>>>>>>>> analyzer.
such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>>>>>On 2025-02-14 12:40:04 +0000, olcott said: >>>>>>>>>>>>>>>>>>>> On 2/14/2025 2:58 AM, Mikko wrote:trying to get away with changing the subject to some >>>>>>>>>>>>>>>>>> other DD
On 2025-02-14 00:07:23 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>> On 2/13/2025 3:20 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-11 14:41:38 +0000, olcott said: >>>>>>>>>>>>>DD correctly simulated by HHH cannot possibly >>>>>>>>>>>>>>>>>>>> terminate normally.
That claim has already shown to be false. Nothing >>>>>>>>>>>>>>>>>>> above shows that
HHH does not return 0. If it does DD also returns 0. >>>>>>>>>>>>>>>>>> When we are referring to the above DD simulated by HHH >>>>>>>>>>>>>>>>>> and not
somewhere else
then anyone with sufficient knowledge of C programming >>>>>>>>>>>>>>>>>> knows that noWell, then that corresponding (by what?) HHH isn’t a >>>>>>>>>>>>>>>>> decider.
instance of DD shown above simulated by any >>>>>>>>>>>>>>>>>> corresponding instance
of HHH can possibly terminate normally.
A simulating termination analyzer correctly rejects any >>>>>>>>>>>>>>>> input thatit halts, because it is a decider. You can’t have your >>>>>>>>>>>>>>> cake and eat it
must be aborted to prevent its own non-termination. >>>>>>>>>>>>>>> Yes, in particular itself is not such an input, because >>>>>>>>>>>>>>> we *know* that
too.
Instead I am using in its place "terminates normally". >>>>>>>>>>>>>> DD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>>>>> normally.
an ambiguous „abnormal termination”. How does HHH simulate DD >>>>>>>>>>>>> terminating abnormally, then? Why doesn’t it terminate >>>>>>>>>>>>> abnormally
itself?
You can substitute the term: the input DD to HHH does not >>>>>>>>>>>>> need to be
aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
It merely means that the words do not have their ordinary
meaning.
Those two comments are not discussed below.
Unless HHH(DD) aborts its simulation of DD itself cannot
possibly terminate normally.
That cannot be determined without examination of HHH, which is >>>>>>>> not in the
scope of OP.
I have given everyone here all of the complete source
code for a few years
True but irrelevant. OP did not specify that HHH means that
particular
code.
Every post that I have been talking about for two or
more years has referred to variations of that same code.
OP had a pointer of that code but didn's state that that code is a part >>>> of the problem. OP did not spacify any range for variation.
I have only been talking about variations of the same code
as HHH(DD) for two years. Do you understand that one sentence?
I understnd the sentence except the word "variations". What is the
range of "variations"?
Good you are being completely reasonable.
There are at least two algorithms the current
one that was also the original one is easiest to
understand. This algorithm essentially spots the
equivalent of infinite recursion. The code provides
all of the details.
Anyway OP did not specify that HHH is restricted to those "variations".
Another undefined word of OP is "cannot". About a person it may mean
that one does not do what one wants to do but a program does not want.
HHH is exactly as specified. Assuming otherwise is silly.
On 2/22/2025 3:04 AM, Mikko wrote:
On 2025-02-21 22:35:16 +0000, olcott said:
On 2/21/2025 2:18 AM, Mikko wrote:
On 2025-02-20 21:31:44 +0000, olcott said:
On 2/20/2025 2:38 AM, Mikko wrote:
On 2025-02-20 00:31:33 +0000, olcott said:
On 2/19/2025 3:01 AM, Mikko wrote:Those two comments are not discussed below.
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:
On 2/16/2025 2:02 PM, joes wrote:What’s confusing about „halts”? I find it clearer as it does not imply
Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>> On 2/16/2025 10:35 AM, joes wrote:I am not even using the confusing term "halts".
(There are other deciders that are not termination analysers.) >>>>>>>>>>>>>>>Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>> On 2/15/2025 2:49 AM, Mikko wrote:I am focusing on the isomorphic notion of a termination analyzer.
such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>>>>>On 2025-02-14 12:40:04 +0000, olcott said: >>>>>>>>>>>>>>>>>>>> On 2/14/2025 2:58 AM, Mikko wrote:trying to get away with changing the subject to some other DD
On 2025-02-14 00:07:23 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>> On 2/13/2025 3:20 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-11 14:41:38 +0000, olcott said: >>>>>>>>>>>>>DD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that
HHH does not return 0. If it does DD also returns 0. >>>>>>>>>>>>>>>>>> When we are referring to the above DD simulated by HHH and not
somewhere else
then anyone with sufficient knowledge of C programming knows that noWell, then that corresponding (by what?) HHH isn’t a decider.
instance of DD shown above simulated by any corresponding instance
of HHH can possibly terminate normally.
A simulating termination analyzer correctly rejects any input thatit halts, because it is a decider. You can’t have your cake and eat it
must be aborted to prevent its own non-termination. >>>>>>>>>>>>>>> Yes, in particular itself is not such an input, because we *know* that
too.
Instead I am using in its place "terminates normally". >>>>>>>>>>>>>> DD correctly simulated by HHH cannot possibly terminate normally.
an ambiguous „abnormal termination”. How does HHH simulate DD >>>>>>>>>>>>> terminating abnormally, then? Why doesn’t it terminate abnormally
itself?
You can substitute the term: the input DD to HHH does not need to be
aborted, because the simulated decider terminates.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
It merely means that the words do not have their ordinary meaning. >>>>>>
Unless HHH(DD) aborts its simulation of DD itself cannot possibly >>>>>>>>> terminate normally.
That cannot be determined without examination of HHH, which is not in the
scope of OP.
I have given everyone here all of the complete source
code for a few years
True but irrelevant. OP did not specify that HHH means that particular >>>>>> code.
Every post that I have been talking about for two or
more years has referred to variations of that same code.
OP had a pointer of that code but didn's state that that code is a part >>>> of the problem. OP did not spacify any range for variation.
I have only been talking about variations of the same code
as HHH(DD) for two years. Do you understand that one sentence?
I understnd the sentence except the word "variations". What is the
range of "variations"?
Good you are being completely reasonable.
There are at least two algorithms the current
one that was also the original one is easiest to
understand. This algorithm essentially spots the
equivalent of infinite recursion. The code provides
all of the details.
Anyway OP did not specify that HHH is restricted to those "variations".
Another undefined word of OP is "cannot". About a person it may mean
that one does not do what one wants to do but a program does not want.
HHH is exactly as specified. Assuming otherwise is silly.
On 2/23/2025 4:59 AM, Mikko wrote:
On 2025-02-22 16:11:31 +0000, olcott said:
On 2/22/2025 3:04 AM, Mikko wrote:
On 2025-02-21 22:35:16 +0000, olcott said:
On 2/21/2025 2:18 AM, Mikko wrote:
On 2025-02-20 21:31:44 +0000, olcott said:
On 2/20/2025 2:38 AM, Mikko wrote:
On 2025-02-20 00:31:33 +0000, olcott said:
On 2/19/2025 3:01 AM, Mikko wrote:
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>> On 2/16/2025 2:02 PM, joes wrote:
What’s confusing about „halts”? I find it clearer as it >>>>>>>>>>>>>>> does not implyAm Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>> On 2/16/2025 10:35 AM, joes wrote:I am not even using the confusing term "halts". >>>>>>>>>>>>>>>> Instead I am using in its place "terminates normally". >>>>>>>>>>>>>>>> DD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>>>>>>> normally.
(There are other deciders that are not termination >>>>>>>>>>>>>>>>> analysers.)Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>> On 2/15/2025 2:49 AM, Mikko wrote:I am focusing on the isomorphic notion of a >>>>>>>>>>>>>>>>>> termination analyzer.
such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>>>>>>>On 2025-02-14 12:40:04 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>> On 2/14/2025 2:58 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-02-14 00:07:23 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>> On 2/13/2025 3:20 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-11 14:41:38 +0000, olcott said: >>>>>>>>>>>>>>>trying to get away with changing the subject to some >>>>>>>>>>>>>>>>>>>> other DD
DD correctly simulated by HHH cannot possibly >>>>>>>>>>>>>>>>>>>>>> terminate normally.
That claim has already shown to be false. Nothing >>>>>>>>>>>>>>>>>>>>> above shows that
HHH does not return 0. If it does DD also returns 0. >>>>>>>>>>>>>>>>>>>> When we are referring to the above DD simulated by >>>>>>>>>>>>>>>>>>>> HHH and not
somewhere else
then anyone with sufficient knowledge of C >>>>>>>>>>>>>>>>>>>> programming knows that no
instance of DD shown above simulated by any >>>>>>>>>>>>>>>>>>>> corresponding instance
of HHH can possibly terminate normally. >>>>>>>>>>>>>>>>>>> Well, then that corresponding (by what?) HHH isn’t a >>>>>>>>>>>>>>>>>>> decider.
A simulating termination analyzer correctly rejects >>>>>>>>>>>>>>>>>> any input thatit halts, because it is a decider. You can’t have your >>>>>>>>>>>>>>>>> cake and eat it
must be aborted to prevent its own non-termination. >>>>>>>>>>>>>>>>> Yes, in particular itself is not such an input, because >>>>>>>>>>>>>>>>> we *know* that
too.
an ambiguous „abnormal termination”. How does HHH >>>>>>>>>>>>>>> simulate DD
terminating abnormally, then? Why doesn’t it terminate >>>>>>>>>>>>>>> abnormally
itself?
You can substitute the term: the input DD to HHH does not >>>>>>>>>>>>>>> need to be
aborted, because the simulated decider terminates. >>>>>>>>>>>>>>>
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating. >>>>>>>>>>>>>>
It merely means that the words do not have their ordinary >>>>>>>>>>>> meaning.
Those two comments are not discussed below.
Unless HHH(DD) aborts its simulation of DD itself cannot >>>>>>>>>>> possibly terminate normally.
That cannot be determined without examination of HHH, which is >>>>>>>>>> not in the
scope of OP.
I have given everyone here all of the complete source
code for a few years
True but irrelevant. OP did not specify that HHH means that
particular
code.
Every post that I have been talking about for two or
more years has referred to variations of that same code.
OP had a pointer of that code but didn's state that that code is a >>>>>> part
of the problem. OP did not spacify any range for variation.
I have only been talking about variations of the same code
as HHH(DD) for two years. Do you understand that one sentence?
I understnd the sentence except the word "variations". What is the
range of "variations"?
Good you are being completely reasonable.
There are at least two algorithms the current
one that was also the original one is easiest to
understand. This algorithm essentially spots the
equivalent of infinite recursion. The code provides
all of the details.
Anyway OP did not specify that HHH is restricted to those "variations". >>>> Another undefined word of OP is "cannot". About a person it may mean
that one does not do what one wants to do but a program does not want. >>>>
HHH is exactly as specified. Assuming otherwise is silly.
The words "as specified" when nothing is specified are not a good use
of the language.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When DD is correctly simulated by HHH according to the behavior
that the above machine code specifies then the call from DD
to HHH(DD) cannot possibly return making it impossible for DD
emulated by HHH to terminate normally.
and this correctly simulated
DD cannot possibly terminate normally by reaching its own machine
address 00002155.
On 2/23/2025 4:59 AM, Mikko wrote:
On 2025-02-22 16:11:31 +0000, olcott said:
On 2/22/2025 3:04 AM, Mikko wrote:
On 2025-02-21 22:35:16 +0000, olcott said:
On 2/21/2025 2:18 AM, Mikko wrote:
On 2025-02-20 21:31:44 +0000, olcott said:
On 2/20/2025 2:38 AM, Mikko wrote:
On 2025-02-20 00:31:33 +0000, olcott said:
On 2/19/2025 3:01 AM, Mikko wrote:Those two comments are not discussed below.
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>> On 2/16/2025 2:02 PM, joes wrote:
What’s confusing about „halts”? I find it clearer as it does not implyAm Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>> On 2/16/2025 10:35 AM, joes wrote:I am not even using the confusing term "halts". >>>>>>>>>>>>>>>> Instead I am using in its place "terminates normally". >>>>>>>>>>>>>>>> DD correctly simulated by HHH cannot possibly terminate normally.
(There are other deciders that are not termination analysers.)Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>> On 2/15/2025 2:49 AM, Mikko wrote:I am focusing on the isomorphic notion of a termination analyzer.
such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>>>>>>>On 2025-02-14 12:40:04 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>> On 2/14/2025 2:58 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-02-14 00:07:23 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>> On 2/13/2025 3:20 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-11 14:41:38 +0000, olcott said: >>>>>>>>>>>>>>>trying to get away with changing the subject to some other DD
DD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that
HHH does not return 0. If it does DD also returns 0. >>>>>>>>>>>>>>>>>>>> When we are referring to the above DD simulated by HHH and not
somewhere else
then anyone with sufficient knowledge of C programming knows that no
instance of DD shown above simulated by any corresponding instance
of HHH can possibly terminate normally. >>>>>>>>>>>>>>>>>>> Well, then that corresponding (by what?) HHH isn’t a decider.
A simulating termination analyzer correctly rejects any input thatit halts, because it is a decider. You can’t have your cake and eat it
must be aborted to prevent its own non-termination. >>>>>>>>>>>>>>>>> Yes, in particular itself is not such an input, because we *know* that
too.
an ambiguous „abnormal termination”. How does HHH simulate DD
terminating abnormally, then? Why doesn’t it terminate abnormally
itself?
You can substitute the term: the input DD to HHH does not need to be
aborted, because the simulated decider terminates. >>>>>>>>>>>>>>>
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating. >>>>>>>>>>>>>>
It merely means that the words do not have their ordinary meaning. >>>>>>>>
Unless HHH(DD) aborts its simulation of DD itself cannot possibly >>>>>>>>>>> terminate normally.
That cannot be determined without examination of HHH, which is not in the
scope of OP.
I have given everyone here all of the complete source
code for a few years
True but irrelevant. OP did not specify that HHH means that particular >>>>>>>> code.
Every post that I have been talking about for two or
more years has referred to variations of that same code.
OP had a pointer of that code but didn's state that that code is a part >>>>>> of the problem. OP did not spacify any range for variation.
I have only been talking about variations of the same code
as HHH(DD) for two years. Do you understand that one sentence?
I understnd the sentence except the word "variations". What is the
range of "variations"?
Good you are being completely reasonable.
There are at least two algorithms the current
one that was also the original one is easiest to
understand. This algorithm essentially spots the
equivalent of infinite recursion. The code provides
all of the details.
Anyway OP did not specify that HHH is restricted to those "variations". >>>> Another undefined word of OP is "cannot". About a person it may mean
that one does not do what one wants to do but a program does not want. >>>>
HHH is exactly as specified. Assuming otherwise is silly.
The words "as specified" when nothing is specified are not a good use
of the language.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When DD is correctly simulated by HHH according to the behavior
that the above machine code specifies then the call from DD
to HHH(DD) cannot possibly return making it impossible for DD
emulated by HHH to terminate normally.
On 2/24/2025 2:47 AM, Mikko wrote:
On 2025-02-23 17:44:25 +0000, olcott said:
On 2/23/2025 4:59 AM, Mikko wrote:
On 2025-02-22 16:11:31 +0000, olcott said:
On 2/22/2025 3:04 AM, Mikko wrote:
On 2025-02-21 22:35:16 +0000, olcott said:
On 2/21/2025 2:18 AM, Mikko wrote:
On 2025-02-20 21:31:44 +0000, olcott said:
On 2/20/2025 2:38 AM, Mikko wrote:
On 2025-02-20 00:31:33 +0000, olcott said:
On 2/19/2025 3:01 AM, Mikko wrote:
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>> On 2/16/2025 2:02 PM, joes wrote:
What’s confusing about „halts”? I find it clearer as it >>>>>>>>>>>>>>>>> does not implyAm Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>> On 2/16/2025 10:35 AM, joes wrote:I am not even using the confusing term "halts". >>>>>>>>>>>>>>>>>> Instead I am using in its place "terminates normally". >>>>>>>>>>>>>>>>>> DD correctly simulated by HHH cannot possibly >>>>>>>>>>>>>>>>>> terminate normally.
(There are other deciders that are not termination >>>>>>>>>>>>>>>>>>> analysers.)Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>> On 2/15/2025 2:49 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-02-14 12:40:04 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>> On 2/14/2025 2:58 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-14 00:07:23 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2/13/2025 3:20 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-11 14:41:38 +0000, olcott said: >>>>>>>>>>>>>>>>>I am focusing on the isomorphic notion of a >>>>>>>>>>>>>>>>>>>> termination analyzer.
such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>>>>>>>>>trying to get away with changing the subject to >>>>>>>>>>>>>>>>>>>>>> some other DDDD correctly simulated by HHH cannot possibly >>>>>>>>>>>>>>>>>>>>>>>> terminate normally.
That claim has already shown to be false. Nothing >>>>>>>>>>>>>>>>>>>>>>> above shows that
HHH does not return 0. If it does DD also returns 0. >>>>>>>>>>>>>>>>>>>>>> When we are referring to the above DD simulated by >>>>>>>>>>>>>>>>>>>>>> HHH and not
somewhere else
then anyone with sufficient knowledge of C >>>>>>>>>>>>>>>>>>>>>> programming knows that no
instance of DD shown above simulated by any >>>>>>>>>>>>>>>>>>>>>> corresponding instance
of HHH can possibly terminate normally. >>>>>>>>>>>>>>>>>>>>> Well, then that corresponding (by what?) HHH isn’t >>>>>>>>>>>>>>>>>>>>> a decider.
A simulating termination analyzer correctly rejects >>>>>>>>>>>>>>>>>>>> any input thatit halts, because it is a decider. You can’t have >>>>>>>>>>>>>>>>>>> your cake and eat it
must be aborted to prevent its own non-termination. >>>>>>>>>>>>>>>>>>> Yes, in particular itself is not such an input, >>>>>>>>>>>>>>>>>>> because we *know* that
too.
an ambiguous „abnormal termination”. How does HHH >>>>>>>>>>>>>>>>> simulate DD
terminating abnormally, then? Why doesn’t it terminate >>>>>>>>>>>>>>>>> abnormally
itself?
You can substitute the term: the input DD to HHH does >>>>>>>>>>>>>>>>> not need to be
aborted, because the simulated decider terminates. >>>>>>>>>>>>>>>>>
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated >>>>>>>>>>>>>>>> to be correctly rejected by HHH as non-terminating. >>>>>>>>>>>>>>>>
It merely means that the words do not have their ordinary >>>>>>>>>>>>>> meaning.
Those two comments are not discussed below.
Unless HHH(DD) aborts its simulation of DD itself cannot >>>>>>>>>>>>> possibly terminate normally.
That cannot be determined without examination of HHH, which >>>>>>>>>>>> is not in the
scope of OP.
I have given everyone here all of the complete source
code for a few years
True but irrelevant. OP did not specify that HHH means that >>>>>>>>>> particular
code.
Every post that I have been talking about for two or
more years has referred to variations of that same code.
OP had a pointer of that code but didn's state that that code is >>>>>>>> a part
of the problem. OP did not spacify any range for variation.
I have only been talking about variations of the same code
as HHH(DD) for two years. Do you understand that one sentence?
I understnd the sentence except the word "variations". What is the >>>>>> range of "variations"?
Good you are being completely reasonable.
There are at least two algorithms the current
one that was also the original one is easiest to
understand. This algorithm essentially spots the
equivalent of infinite recursion. The code provides
all of the details.
Anyway OP did not specify that HHH is restricted to those
"variations".
Another undefined word of OP is "cannot". About a person it may mean >>>>>> that one does not do what one wants to do but a program does not
want.
HHH is exactly as specified. Assuming otherwise is silly.
The words "as specified" when nothing is specified are not a good use
of the language.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When DD is correctly simulated by HHH according to the behavior
that the above machine code specifies then the call from DD
to HHH(DD) cannot possibly return making it impossible for DD
emulated by HHH to terminate normally.
That code does not specify whether HHH ever returns or what value
HHH returns if it does.
When HHH is known to emulate the above code with an x86
emulator THEN
the above machine code specifies then the call from DD
to HHH(DD) cannot possibly return making it impossible for DD
emulated by HHH to terminate normally.
Trying to show that there is an error in an argument
by ignoring a premise to this argument seems to be
a quite dumb thing to do.
Your HHH does not simulate correctly the call to HHH in the sense
that it does not interprete HHH as a function that returns 0 but
your HHH is a function that does return 0 when called as above.
On 2/24/2025 2:47 AM, Mikko wrote:
On 2025-02-23 17:44:25 +0000, olcott said:
On 2/23/2025 4:59 AM, Mikko wrote:
On 2025-02-22 16:11:31 +0000, olcott said:
On 2/22/2025 3:04 AM, Mikko wrote:
On 2025-02-21 22:35:16 +0000, olcott said:
On 2/21/2025 2:18 AM, Mikko wrote:
On 2025-02-20 21:31:44 +0000, olcott said:
On 2/20/2025 2:38 AM, Mikko wrote:
On 2025-02-20 00:31:33 +0000, olcott said:
On 2/19/2025 3:01 AM, Mikko wrote:
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>> On 2/16/2025 2:02 PM, joes wrote:
What’s confusing about „halts”? I find it clearer as it >>>>>>>>>>>>>>>>> does not implyAm Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>> On 2/16/2025 10:35 AM, joes wrote:I am not even using the confusing term "halts". >>>>>>>>>>>>>>>>>> Instead I am using in its place "terminates normally". >>>>>>>>>>>>>>>>>> DD correctly simulated by HHH cannot possibly >>>>>>>>>>>>>>>>>> terminate normally.
(There are other deciders that are not termination >>>>>>>>>>>>>>>>>>> analysers.)Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>> On 2/15/2025 2:49 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-02-14 12:40:04 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>> On 2/14/2025 2:58 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-14 00:07:23 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2/13/2025 3:20 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-11 14:41:38 +0000, olcott said: >>>>>>>>>>>>>>>>>I am focusing on the isomorphic notion of a >>>>>>>>>>>>>>>>>>>> termination analyzer.
such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>>>>>>>>>trying to get away with changing the subject to >>>>>>>>>>>>>>>>>>>>>> some other DDDD correctly simulated by HHH cannot possibly >>>>>>>>>>>>>>>>>>>>>>>> terminate normally.
That claim has already shown to be false. Nothing >>>>>>>>>>>>>>>>>>>>>>> above shows that
HHH does not return 0. If it does DD also returns 0. >>>>>>>>>>>>>>>>>>>>>> When we are referring to the above DD simulated by >>>>>>>>>>>>>>>>>>>>>> HHH and not
somewhere else
then anyone with sufficient knowledge of C >>>>>>>>>>>>>>>>>>>>>> programming knows that no
instance of DD shown above simulated by any >>>>>>>>>>>>>>>>>>>>>> corresponding instance
of HHH can possibly terminate normally. >>>>>>>>>>>>>>>>>>>>> Well, then that corresponding (by what?) HHH isn’t >>>>>>>>>>>>>>>>>>>>> a decider.
A simulating termination analyzer correctly rejects >>>>>>>>>>>>>>>>>>>> any input thatit halts, because it is a decider. You can’t have >>>>>>>>>>>>>>>>>>> your cake and eat it
must be aborted to prevent its own non-termination. >>>>>>>>>>>>>>>>>>> Yes, in particular itself is not such an input, >>>>>>>>>>>>>>>>>>> because we *know* that
too.
an ambiguous „abnormal termination”. How does HHH >>>>>>>>>>>>>>>>> simulate DD
terminating abnormally, then? Why doesn’t it terminate >>>>>>>>>>>>>>>>> abnormally
itself?
You can substitute the term: the input DD to HHH does >>>>>>>>>>>>>>>>> not need to be
aborted, because the simulated decider terminates. >>>>>>>>>>>>>>>>>
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated >>>>>>>>>>>>>>>> to be correctly rejected by HHH as non-terminating. >>>>>>>>>>>>>>>>
It merely means that the words do not have their ordinary >>>>>>>>>>>>>> meaning.
Those two comments are not discussed below.
Unless HHH(DD) aborts its simulation of DD itself cannot >>>>>>>>>>>>> possibly terminate normally.
That cannot be determined without examination of HHH, which >>>>>>>>>>>> is not in the
scope of OP.
I have given everyone here all of the complete source
code for a few years
True but irrelevant. OP did not specify that HHH means that >>>>>>>>>> particular
code.
Every post that I have been talking about for two or
more years has referred to variations of that same code.
OP had a pointer of that code but didn's state that that code is >>>>>>>> a part
of the problem. OP did not spacify any range for variation.
I have only been talking about variations of the same code
as HHH(DD) for two years. Do you understand that one sentence?
I understnd the sentence except the word "variations". What is the >>>>>> range of "variations"?
Good you are being completely reasonable.
There are at least two algorithms the current
one that was also the original one is easiest to
understand. This algorithm essentially spots the
equivalent of infinite recursion. The code provides
all of the details.
Anyway OP did not specify that HHH is restricted to those
"variations".
Another undefined word of OP is "cannot". About a person it may mean >>>>>> that one does not do what one wants to do but a program does not
want.
HHH is exactly as specified. Assuming otherwise is silly.
The words "as specified" when nothing is specified are not a good use
of the language.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When DD is correctly simulated by HHH according to the behavior
that the above machine code specifies then the call from DD
to HHH(DD) cannot possibly return making it impossible for DD
emulated by HHH to terminate normally.
That code does not specify whether HHH ever returns or what value
HHH returns if it does.
When HHH is known to emulate the above code with an x86
emulator THEN
the above machine code specifies then the call from DD
to HHH(DD) cannot possibly return making it impossible for DD
emulated by HHH to terminate normally.
On 2/24/2025 2:47 AM, Mikko wrote:
On 2025-02-23 17:44:25 +0000, olcott said:
On 2/23/2025 4:59 AM, Mikko wrote:
On 2025-02-22 16:11:31 +0000, olcott said:
On 2/22/2025 3:04 AM, Mikko wrote:
On 2025-02-21 22:35:16 +0000, olcott said:
On 2/21/2025 2:18 AM, Mikko wrote:
On 2025-02-20 21:31:44 +0000, olcott said:
On 2/20/2025 2:38 AM, Mikko wrote:
On 2025-02-20 00:31:33 +0000, olcott said:
On 2/19/2025 3:01 AM, Mikko wrote:
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>> On 2/16/2025 2:02 PM, joes wrote:
What’s confusing about „halts”? I find it clearer as it does not implyAm Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>> On 2/16/2025 10:35 AM, joes wrote:I am not even using the confusing term "halts". >>>>>>>>>>>>>>>>>> Instead I am using in its place "terminates normally". >>>>>>>>>>>>>>>>>> DD correctly simulated by HHH cannot possibly terminate normally.
(There are other deciders that are not termination analysers.)Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>> On 2/15/2025 2:49 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-02-14 12:40:04 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>> On 2/14/2025 2:58 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-14 00:07:23 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2/13/2025 3:20 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-11 14:41:38 +0000, olcott said: >>>>>>>>>>>>>>>>>I am focusing on the isomorphic notion of a termination analyzer.
such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>>>>>>>>>trying to get away with changing the subject to some other DDDD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that
HHH does not return 0. If it does DD also returns 0. >>>>>>>>>>>>>>>>>>>>>> When we are referring to the above DD simulated by HHH and not
somewhere else
then anyone with sufficient knowledge of C programming knows that no
instance of DD shown above simulated by any corresponding instance
of HHH can possibly terminate normally. >>>>>>>>>>>>>>>>>>>>> Well, then that corresponding (by what?) HHH isn’t a decider.
A simulating termination analyzer correctly rejects any input thatit halts, because it is a decider. You can’t have your cake and eat it
must be aborted to prevent its own non-termination. >>>>>>>>>>>>>>>>>>> Yes, in particular itself is not such an input, because we *know* that
too.
an ambiguous „abnormal termination”. How does HHH simulate DD
terminating abnormally, then? Why doesn’t it terminate abnormally
itself?
You can substitute the term: the input DD to HHH does not need to be
aborted, because the simulated decider terminates. >>>>>>>>>>>>>>>>>
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated >>>>>>>>>>>>>>>> to be correctly rejected by HHH as non-terminating. >>>>>>>>>>>>>>>>
It merely means that the words do not have their ordinary meaning.
Those two comments are not discussed below.
Unless HHH(DD) aborts its simulation of DD itself cannot possibly >>>>>>>>>>>>> terminate normally.
That cannot be determined without examination of HHH, which is not in the
scope of OP.
I have given everyone here all of the complete source
code for a few years
True but irrelevant. OP did not specify that HHH means that particular
code.
Every post that I have been talking about for two or
more years has referred to variations of that same code.
OP had a pointer of that code but didn's state that that code is a part
of the problem. OP did not spacify any range for variation.
I have only been talking about variations of the same code
as HHH(DD) for two years. Do you understand that one sentence?
I understnd the sentence except the word "variations". What is the >>>>>> range of "variations"?
Good you are being completely reasonable.
There are at least two algorithms the current
one that was also the original one is easiest to
understand. This algorithm essentially spots the
equivalent of infinite recursion. The code provides
all of the details.
Anyway OP did not specify that HHH is restricted to those "variations". >>>>>> Another undefined word of OP is "cannot". About a person it may mean >>>>>> that one does not do what one wants to do but a program does not want. >>>>>>
HHH is exactly as specified. Assuming otherwise is silly.
The words "as specified" when nothing is specified are not a good use
of the language.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When DD is correctly simulated by HHH according to the behavior
that the above machine code specifies then the call from DD
to HHH(DD) cannot possibly return making it impossible for DD
emulated by HHH to terminate normally.
That code does not specify whether HHH ever returns or what value
HHH returns if it does.
When HHH is known to emulate the above code with an x86
emulator THEN
the above machine code specifies then the call from DD
to HHH(DD) cannot possibly return making it impossible for DD
emulated by HHH to terminate normally.
On 2/25/2025 8:59 AM, Mikko wrote:
On 2025-02-24 23:36:04 +0000, olcott said:
On 2/24/2025 2:47 AM, Mikko wrote:
On 2025-02-23 17:44:25 +0000, olcott said:
On 2/23/2025 4:59 AM, Mikko wrote:
On 2025-02-22 16:11:31 +0000, olcott said:
On 2/22/2025 3:04 AM, Mikko wrote:
On 2025-02-21 22:35:16 +0000, olcott said:
On 2/21/2025 2:18 AM, Mikko wrote:I understnd the sentence except the word "variations". What is the >>>>>>>> range of "variations"?
On 2025-02-20 21:31:44 +0000, olcott said:
On 2/20/2025 2:38 AM, Mikko wrote:
On 2025-02-20 00:31:33 +0000, olcott said:
On 2/19/2025 3:01 AM, Mikko wrote:
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said: >>>>>>>>>>>>>>>>
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>> On 2/16/2025 2:02 PM, joes wrote:
What’s confusing about „halts”? I find it clearer as >>>>>>>>>>>>>>>>>>> it does not implyAm Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>> On 2/16/2025 10:35 AM, joes wrote: >>>>>>>>>>>>>>>>>>>>>>> Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>>>> On 2/15/2025 2:49 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-14 12:40:04 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2/14/2025 2:58 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-14 00:07:23 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/13/2025 3:20 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-11 14:41:38 +0000, olcott said: >>>>>>>>>>>>>>>>>>>I am not even using the confusing term "halts". >>>>>>>>>>>>>>>>>>>> Instead I am using in its place "terminates normally". >>>>>>>>>>>>>>>>>>>> DD correctly simulated by HHH cannot possibly >>>>>>>>>>>>>>>>>>>> terminate normally.
(There are other deciders that are not termination >>>>>>>>>>>>>>>>>>>>> analysers.)I am focusing on the isomorphic notion of a >>>>>>>>>>>>>>>>>>>>>> termination analyzer.such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>>>>>>>>>>>When we are referring to the above DD simulated >>>>>>>>>>>>>>>>>>>>>>>> by HHH and notDD correctly simulated by HHH cannot possibly >>>>>>>>>>>>>>>>>>>>>>>>>> terminate normally.
That claim has already shown to be false. >>>>>>>>>>>>>>>>>>>>>>>>> Nothing above shows that
HHH does not return 0. If it does DD also >>>>>>>>>>>>>>>>>>>>>>>>> returns 0.
trying to get away with changing the subject to >>>>>>>>>>>>>>>>>>>>>>>> some other DD
somewhere else
then anyone with sufficient knowledge of C >>>>>>>>>>>>>>>>>>>>>>>> programming knows that no
instance of DD shown above simulated by any >>>>>>>>>>>>>>>>>>>>>>>> corresponding instance
of HHH can possibly terminate normally. >>>>>>>>>>>>>>>>>>>>>>> Well, then that corresponding (by what?) HHH >>>>>>>>>>>>>>>>>>>>>>> isn’t a decider.
A simulating termination analyzer correctly >>>>>>>>>>>>>>>>>>>>>> rejects any input thatit halts, because it is a decider. You can’t have >>>>>>>>>>>>>>>>>>>>> your cake and eat it
must be aborted to prevent its own non-termination. >>>>>>>>>>>>>>>>>>>>> Yes, in particular itself is not such an input, >>>>>>>>>>>>>>>>>>>>> because we *know* that
too.
an ambiguous „abnormal termination”. How does HHH >>>>>>>>>>>>>>>>>>> simulate DD
terminating abnormally, then? Why doesn’t it >>>>>>>>>>>>>>>>>>> terminate abnormally
itself?
You can substitute the term: the input DD to HHH does >>>>>>>>>>>>>>>>>>> not need to be
aborted, because the simulated decider terminates. >>>>>>>>>>>>>>>>>>>
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to >>>>>>>>>>>>>>>>>> prevent the non-termination of HHH is stipulated >>>>>>>>>>>>>>>>>> to be correctly rejected by HHH as non-terminating. >>>>>>>>>>>>>>>>>>
It merely means that the words do not have their >>>>>>>>>>>>>>>> ordinary meaning.
Those two comments are not discussed below.
Unless HHH(DD) aborts its simulation of DD itself cannot >>>>>>>>>>>>>>> possibly terminate normally.
That cannot be determined without examination of HHH, >>>>>>>>>>>>>> which is not in the
scope of OP.
I have given everyone here all of the complete source >>>>>>>>>>>>> code for a few years
True but irrelevant. OP did not specify that HHH means that >>>>>>>>>>>> particular
code.
Every post that I have been talking about for two or
more years has referred to variations of that same code.
OP had a pointer of that code but didn's state that that code >>>>>>>>>> is a part
of the problem. OP did not spacify any range for variation. >>>>>>>>>>
I have only been talking about variations of the same code
as HHH(DD) for two years. Do you understand that one sentence? >>>>>>>>
Good you are being completely reasonable.
There are at least two algorithms the current
one that was also the original one is easiest to
understand. This algorithm essentially spots the
equivalent of infinite recursion. The code provides
all of the details.
Anyway OP did not specify that HHH is restricted to those
"variations".
Another undefined word of OP is "cannot". About a person it may >>>>>>>> mean
that one does not do what one wants to do but a program does not >>>>>>>> want.
HHH is exactly as specified. Assuming otherwise is silly.
The words "as specified" when nothing is specified are not a good use >>>>>> of the language.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local >>>>> [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When DD is correctly simulated by HHH according to the behavior
that the above machine code specifies then the call from DD
to HHH(DD) cannot possibly return making it impossible for DD
emulated by HHH to terminate normally.
That code does not specify whether HHH ever returns or what value
HHH returns if it does.
When HHH is known to emulate the above code with an x86
emulator THEN
Although OP says that HHH simulates it does not specify what is
simulated.
the above code
the above code
the above code
the above code
the above code
the above code
On 2/25/2025 5:41 PM, Richard Damon wrote:
On 2/25/25 4:12 PM, olcott wrote:
On 2/25/2025 8:59 AM, Mikko wrote:
On 2025-02-24 23:36:04 +0000, olcott said:
On 2/24/2025 2:47 AM, Mikko wrote:
On 2025-02-23 17:44:25 +0000, olcott said:
On 2/23/2025 4:59 AM, Mikko wrote:
On 2025-02-22 16:11:31 +0000, olcott said:
On 2/22/2025 3:04 AM, Mikko wrote:
On 2025-02-21 22:35:16 +0000, olcott said:
On 2/21/2025 2:18 AM, Mikko wrote:I understnd the sentence except the word "variations". What is >>>>>>>>>> the
On 2025-02-20 21:31:44 +0000, olcott said:
On 2/20/2025 2:38 AM, Mikko wrote:OP had a pointer of that code but didn's state that that >>>>>>>>>>>> code is a part
On 2025-02-20 00:31:33 +0000, olcott said:
On 2/19/2025 3:01 AM, Mikko wrote:
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said: >>>>>>>>>>>>>>>>>>
Op 16.feb.2025 om 23:51 schreef olcott: >>>>>>>>>>>>>>>>>>>> On 2/16/2025 4:30 PM, joes wrote:
A very strange and invalid stipulation.Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>> On 2/16/2025 2:02 PM, joes wrote: >>>>>>>>>>>>>>>>>>>>>>> Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>>>> On 2/16/2025 10:35 AM, joes wrote: >>>>>>>>>>>>>>>>>>>>>>>>> Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2/15/2025 2:49 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-14 12:40:04 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/14/2025 2:58 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-14 00:07:23 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/13/2025 3:20 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-11 14:41:38 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>
What’s confusing about „halts”? I find it clearer >>>>>>>>>>>>>>>>>>>>> as it does not implyI am not even using the confusing term "halts". >>>>>>>>>>>>>>>>>>>>>> Instead I am using in its place "terminates >>>>>>>>>>>>>>>>>>>>>> normally".(There are other deciders that are not >>>>>>>>>>>>>>>>>>>>>>> termination analysers.)I am focusing on the isomorphic notion of a >>>>>>>>>>>>>>>>>>>>>>>> termination analyzer.such as one that calls a non-aborting version >>>>>>>>>>>>>>>>>>>>>>>>> of HHHWhen we are referring to the above DD >>>>>>>>>>>>>>>>>>>>>>>>>> simulated by HHH and notDD correctly simulated by HHH cannot >>>>>>>>>>>>>>>>>>>>>>>>>>>> possibly terminate normally. >>>>>>>>>>>>>>>>>>>>>>>>>>>That claim has already shown to be false. >>>>>>>>>>>>>>>>>>>>>>>>>>> Nothing above shows that >>>>>>>>>>>>>>>>>>>>>>>>>>> HHH does not return 0. If it does DD also >>>>>>>>>>>>>>>>>>>>>>>>>>> returns 0.
trying to get away with changing the subject >>>>>>>>>>>>>>>>>>>>>>>>>> to some other DD
somewhere else
then anyone with sufficient knowledge of C >>>>>>>>>>>>>>>>>>>>>>>>>> programming knows that no
instance of DD shown above simulated by any >>>>>>>>>>>>>>>>>>>>>>>>>> corresponding instance
of HHH can possibly terminate normally. >>>>>>>>>>>>>>>>>>>>>>>>> Well, then that corresponding (by what?) HHH >>>>>>>>>>>>>>>>>>>>>>>>> isn’t a decider.
A simulating termination analyzer correctly >>>>>>>>>>>>>>>>>>>>>>>> rejects any input thatit halts, because it is a decider. You can’t have >>>>>>>>>>>>>>>>>>>>>>> your cake and eat it
must be aborted to prevent its own non-termination. >>>>>>>>>>>>>>>>>>>>>>> Yes, in particular itself is not such an input, >>>>>>>>>>>>>>>>>>>>>>> because we *know* that
too.
DD correctly simulated by HHH cannot possibly >>>>>>>>>>>>>>>>>>>>>> terminate normally.
an ambiguous „abnormal termination”. How does HHH >>>>>>>>>>>>>>>>>>>>> simulate DD
terminating abnormally, then? Why doesn’t it >>>>>>>>>>>>>>>>>>>>> terminate abnormally
itself?
You can substitute the term: the input DD to HHH >>>>>>>>>>>>>>>>>>>>> does not need to be
aborted, because the simulated decider terminates. >>>>>>>>>>>>>>>>>>>>>
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to >>>>>>>>>>>>>>>>>>>> prevent the non-termination of HHH is stipulated >>>>>>>>>>>>>>>>>>>> to be correctly rejected by HHH as non-terminating. >>>>>>>>>>>>>>>>>>>>
It merely means that the words do not have their >>>>>>>>>>>>>>>>>> ordinary meaning.
Those two comments are not discussed below.
Unless HHH(DD) aborts its simulation of DD itself >>>>>>>>>>>>>>>>> cannot possibly terminate normally.
That cannot be determined without examination of HHH, >>>>>>>>>>>>>>>> which is not in the
scope of OP.
I have given everyone here all of the complete source >>>>>>>>>>>>>>> code for a few years
True but irrelevant. OP did not specify that HHH means >>>>>>>>>>>>>> that particular
code.
Every post that I have been talking about for two or >>>>>>>>>>>>> more years has referred to variations of that same code. >>>>>>>>>>>>
of the problem. OP did not spacify any range for variation. >>>>>>>>>>>>
I have only been talking about variations of the same code >>>>>>>>>>> as HHH(DD) for two years. Do you understand that one sentence? >>>>>>>>>>
range of "variations"?
Good you are being completely reasonable.
There are at least two algorithms the current
one that was also the original one is easiest to
understand. This algorithm essentially spots the
equivalent of infinite recursion. The code provides
all of the details.
Anyway OP did not specify that HHH is restricted to those
"variations".
Another undefined word of OP is "cannot". About a person it >>>>>>>>>> may mean
that one does not do what one wants to do but a program does >>>>>>>>>> not want.
HHH is exactly as specified. Assuming otherwise is silly.
The words "as specified" when nothing is specified are not a
good use
of the language.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local >>>>>>> [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When DD is correctly simulated by HHH according to the behavior
that the above machine code specifies then the call from DD
to HHH(DD) cannot possibly return making it impossible for DD
emulated by HHH to terminate normally.
That code does not specify whether HHH ever returns or what value
HHH returns if it does.
When HHH is known to emulate the above code with an x86
emulator THEN
Although OP says that HHH simulates it does not specify what is
simulated.
the above code
the above code
the above code
the above code
the above code
the above code
Which isn't all of the program.
The behavior of DD emulated by HHH only refers to DD
and the fact that HHH emulates this DD.
It must be your ADD that prevents you from ever staying
focused on this one simple point.
On 2/25/2025 8:59 AM, Mikko wrote:
On 2025-02-24 23:36:04 +0000, olcott said:
On 2/24/2025 2:47 AM, Mikko wrote:
On 2025-02-23 17:44:25 +0000, olcott said:
On 2/23/2025 4:59 AM, Mikko wrote:
On 2025-02-22 16:11:31 +0000, olcott said:
On 2/22/2025 3:04 AM, Mikko wrote:
On 2025-02-21 22:35:16 +0000, olcott said:
On 2/21/2025 2:18 AM, Mikko wrote:I understnd the sentence except the word "variations". What is the >>>>>>>> range of "variations"?
On 2025-02-20 21:31:44 +0000, olcott said:
On 2/20/2025 2:38 AM, Mikko wrote:
On 2025-02-20 00:31:33 +0000, olcott said:
On 2/19/2025 3:01 AM, Mikko wrote:
On 2025-02-18 11:26:25 +0000, olcott said:
On 2/18/2025 3:24 AM, Mikko wrote:
On 2025-02-17 09:05:42 +0000, Fred. Zwarts said: >>>>>>>>>>>>>>>>
Op 16.feb.2025 om 23:51 schreef olcott:
On 2/16/2025 4:30 PM, joes wrote:A very strange and invalid stipulation.
Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>> On 2/16/2025 2:02 PM, joes wrote:
What’s confusing about „halts”? I find it clearer as it does not implyAm Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>> On 2/16/2025 10:35 AM, joes wrote: >>>>>>>>>>>>>>>>>>>>>>> Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>>>> On 2/15/2025 2:49 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-14 12:40:04 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2/14/2025 2:58 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-14 00:07:23 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/13/2025 3:20 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-13 04:21:34 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/12/2025 4:04 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-02-11 14:41:38 +0000, olcott said: >>>>>>>>>>>>>>>>>>>I am not even using the confusing term "halts". >>>>>>>>>>>>>>>>>>>> Instead I am using in its place "terminates normally". >>>>>>>>>>>>>>>>>>>> DD correctly simulated by HHH cannot possibly terminate normally.
(There are other deciders that are not termination analysers.)I am focusing on the isomorphic notion of a termination analyzer.such as one that calls a non-aborting version of HHH >>>>>>>>>>>>>>>>>>>>>>>trying to get away with changing the subject to some other DDDD correctly simulated by HHH cannot possibly terminate normally.
That claim has already shown to be false. Nothing above shows that
HHH does not return 0. If it does DD also returns 0. >>>>>>>>>>>>>>>>>>>>>>>> When we are referring to the above DD simulated by HHH and not
somewhere else
then anyone with sufficient knowledge of C programming knows that no
instance of DD shown above simulated by any corresponding instance
of HHH can possibly terminate normally. >>>>>>>>>>>>>>>>>>>>>>> Well, then that corresponding (by what?) HHH isn’t a decider.
A simulating termination analyzer correctly rejects any input thatit halts, because it is a decider. You can’t have your cake and eat it
must be aborted to prevent its own non-termination. >>>>>>>>>>>>>>>>>>>>> Yes, in particular itself is not such an input, because we *know* that
too.
an ambiguous „abnormal termination”. How does HHH simulate DD
terminating abnormally, then? Why doesn’t it terminate abnormally
itself?
You can substitute the term: the input DD to HHH does not need to be
aborted, because the simulated decider terminates. >>>>>>>>>>>>>>>>>>>
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
Every simulated input that must be aborted to >>>>>>>>>>>>>>>>>> prevent the non-termination of HHH is stipulated >>>>>>>>>>>>>>>>>> to be correctly rejected by HHH as non-terminating. >>>>>>>>>>>>>>>>>>
It merely means that the words do not have their ordinary meaning.
Those two comments are not discussed below.
Unless HHH(DD) aborts its simulation of DD itself cannot possibly
terminate normally.
That cannot be determined without examination of HHH, which is not in the
scope of OP.
I have given everyone here all of the complete source >>>>>>>>>>>>> code for a few years
True but irrelevant. OP did not specify that HHH means that particular
code.
Every post that I have been talking about for two or
more years has referred to variations of that same code.
OP had a pointer of that code but didn's state that that code is a part
of the problem. OP did not spacify any range for variation. >>>>>>>>>>
I have only been talking about variations of the same code
as HHH(DD) for two years. Do you understand that one sentence? >>>>>>>>
Good you are being completely reasonable.
There are at least two algorithms the current
one that was also the original one is easiest to
understand. This algorithm essentially spots the
equivalent of infinite recursion. The code provides
all of the details.
Anyway OP did not specify that HHH is restricted to those "variations".
Another undefined word of OP is "cannot". About a person it may mean >>>>>>>> that one does not do what one wants to do but a program does not want. >>>>>>>>
HHH is exactly as specified. Assuming otherwise is silly.
The words "as specified" when nothing is specified are not a good use >>>>>> of the language.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local >>>>> [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When DD is correctly simulated by HHH according to the behavior
that the above machine code specifies then the call from DD
to HHH(DD) cannot possibly return making it impossible for DD
emulated by HHH to terminate normally.
That code does not specify whether HHH ever returns or what value
HHH returns if it does.
When HHH is known to emulate the above code with an x86
emulator THEN
Although OP says that HHH simulates it does not specify what is
simulated.
the above code
On 2/27/2025 3:36 AM, Fred. Zwarts wrote:
Op 27.feb.2025 om 05:40 schreef olcott:
On 2/26/2025 9:52 AM, joes wrote:
Am Wed, 26 Feb 2025 08:49:42 -0600 schrieb olcott:
On 2/26/2025 3:48 AM, Fred. Zwarts wrote:
Op 26.feb.2025 om 05:50 schreef olcott:
On 2/25/2025 10:21 PM, Richard Damon wrote:
You already know that you are stupidly wrong about the emulation >>>>>>> being
incorrect or you would have provided the correct emulation sequence >>>>>>> long ago.
What are the correct first 15 lines of DD emulated by HHH.What are the first 15 lines of DD correctly emulated by HHH?The error in the simulation occurs already at the 5th instruction, >>>>>> the
'call 000015c3'. Instead of simulating this instruction,
There can be no correct continuation.
I say what the correct simulation is.
You say that I am wrong.
If I am wrong then a correct simulation must exist.
HHH1 did a correct simulation, so, there it is.
That dishonestly dodged the original question:
What are the first 15 *lines of DD* correctly emulated by HHH?
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
On 2/27/2025 7:00 PM, Richard Damon wrote:Hahaha no. HHH is *required* to simulate exactly DD and nothing else.
On 2/27/25 3:18 PM, olcott wrote:
On 2/27/2025 3:58 AM, Fred. Zwarts wrote:
Op 27.feb.2025 om 05:49 schreef olcott:
On 2/26/2025 10:12 AM, Fred. Zwarts wrote:
Op 26.feb.2025 om 15:45 schreef olcott:
On 2/26/2025 3:29 AM, joes wrote:
Am Tue, 25 Feb 2025 20:13:43 -0600 schrieb olcott:
On 2/25/2025 5:41 PM, Richard Damon wrote:
DD emulated by HHH explicitly excludes directly executed DD that has a different execution trace.That claim is just flat out dishonest, and proves you don't understandWhen I say that DD emulated by HHH cannot terminate normally it isChange of subject to avoid a honest discussion.does not change it into non- halting. It is childish to claimYou can't even keep track of what we are talking about.
that when you close your eyes, things do not happen.
It is childish to claim that things do not happen when you close your
eyes.
flat out dishonest to say that I am wrong based on another different
DD that has different behavior.
the meaning of the words you are using.
It has always been ridiculously stupid for anyone to expect HHH toYeah, exactly. Why does HHH not produce the execution trace of DD?
report on any behavior besides the behavior that its finite string input specifies.
On 2/27/2025 7:00 PM, Richard Damon wrote:Let's naively assume it doesn't produce any side effects. Then it depends
On 2/27/25 2:06 PM, olcott wrote:When you are told that this address specifies an x86 emulator then disagreement is incorrect.
On 2/27/2025 3:36 AM, Fred. Zwarts wrote:PROBLEM BLOWS UP as the value of memory 000015c3 isn't specified as
Op 27.feb.2025 om 05:40 schreef olcott:That dishonestly dodged the original question:
On 2/26/2025 9:52 AM, joes wrote:HHH1 did a correct simulation, so, there it is.
Am Wed, 26 Feb 2025 08:49:42 -0600 schrieb olcott:I say what the correct simulation is.
On 2/26/2025 3:48 AM, Fred. Zwarts wrote:There can be no correct continuation.
Op 26.feb.2025 om 05:50 schreef olcott:What are the correct first 15 lines of DD emulated by HHH.
On 2/25/2025 10:21 PM, Richard Damon wrote:
You already know that you are stupidly wrong about the emulation >>>>>>>>> being incorrect or you would have provided the correct emulation >>>>>>>>> sequence long ago.The error in the simulation occurs already at the 5th
What are the first 15 lines of DD correctly emulated by HHH?
instruction, the 'call 000015c3'. Instead of simulating this
instruction,
You say that I am wrong.
If I am wrong then a correct simulation must exist.
What are the first 15 *lines of DD* correctly emulated by HHH?
part
On 2/27/2025 3:00 PM, joes wrote:You only asked for the trace of DD.
Am Thu, 27 Feb 2025 13:06:41 -0600 schrieb olcott:
On 2/27/2025 3:36 AM, Fred. Zwarts wrote:Look at what HHH1 does.
Op 27.feb.2025 om 05:40 schreef olcott:That dishonestly dodged the original question:
On 2/26/2025 9:52 AM, joes wrote:HHH1 did a correct simulation, so, there it is.
Am Wed, 26 Feb 2025 08:49:42 -0600 schrieb olcott:If I am wrong then a correct simulation must exist.
On 2/26/2025 3:48 AM, Fred. Zwarts wrote:There can be no correct continuation.
Op 26.feb.2025 om 05:50 schreef olcott:What are the correct first 15 lines of DD emulated by HHH.
On 2/25/2025 10:21 PM, Richard Damon wrote:
You already know that you are stupidly wrong about the emulation >>>>>>>>> being incorrect or you would have provided the correct emulation >>>>>>>>> sequence long ago.The error in the simulation occurs already at the 5th
What are the first 15 lines of DD correctly emulated by HHH?
instruction,
the 'call 000015c3'. Instead of simulating this instruction,
What are the first 15 *lines of DD* correctly emulated by HHH?
Anyway: ignoring the call to HHH,Is stupidly wrong.
--because it doesn't call DD in turn,
we continue with 2141 until the conditional jump, whereupon we either
enter an infinite loop (which is more than 15 instructions)
or proceed to return (which is 13 instructions), depending on the
return value of HHH.
On 2/27/2025 3:58 AM, Fred. Zwarts wrote:
Op 27.feb.2025 om 05:49 schreef olcott:
On 2/26/2025 10:12 AM, Fred. Zwarts wrote:
Op 26.feb.2025 om 15:45 schreef olcott:
On 2/26/2025 3:29 AM, joes wrote:
Am Tue, 25 Feb 2025 20:13:43 -0600 schrieb olcott:
On 2/25/2025 5:41 PM, Richard Damon wrote:
The behavior of DD emulated by HHH only refers to DD and the fact >>>>>>> thatOn on hand, the simulator can have no influence on the execution.
HHH emulates this DD.
On the other, that same simulator is part of the program.
You don't understand this simple entanglement.
Unless having no influence causes itself to
never terminate then the one influence that
it must have is stopping the emulation of this input.
If the influence is that it does not complete the simulation, but
aborts it, then the programmer should understand that the simulated
simulation has the same behaviour, causing halting behaviour.
We have only been talking abort normal termination of a
C function for several weeks. Perhaps you have no
idea what "normal termination" means.
It seems that Olcott does not understand the terminology. It has been
proven by direct execution that the finite string given to HHH
describes a program that terminates normally.
That HHH is unable to reach this normally termination is a failure of
HHH. This failure of HHH does not change the behaviour described by
this finite string.
Aborting a program with halting behaviour
We have not been talking about halting for a long
time. This term has proven to be far too vague.
Normal termination of a C function means reaching
its "return" instruction. Zero vagueness.
Introducing the concept of aborting a program before it can reach its
return instruction to prove its 'non-termination' makes it even more
vague.
does not change it into non- halting. It is childish to claim that
when you close your eyes, things do not happen.
You can't even keep track of what we are talking about.
Change of subject to avoid a honest discussion.
It is childish to claim that things do not happen when you close your
eyes.
When I say that DD emulated by HHH cannot terminate
normally it is flat out dishonest to say that I am
wrong based on another different DD that has different behavior.
On 2/27/2025 7:00 PM, Richard Damon wrote:
On 2/27/25 3:18 PM, olcott wrote:
On 2/27/2025 3:58 AM, Fred. Zwarts wrote:
Op 27.feb.2025 om 05:49 schreef olcott:
On 2/26/2025 10:12 AM, Fred. Zwarts wrote:
Op 26.feb.2025 om 15:45 schreef olcott:
On 2/26/2025 3:29 AM, joes wrote:
Am Tue, 25 Feb 2025 20:13:43 -0600 schrieb olcott:
On 2/25/2025 5:41 PM, Richard Damon wrote:
The behavior of DD emulated by HHH only refers to DD and the >>>>>>>>> fact thatOn on hand, the simulator can have no influence on the execution. >>>>>>>
HHH emulates this DD.
On the other, that same simulator is part of the program.
You don't understand this simple entanglement.
Unless having no influence causes itself to
never terminate then the one influence that
it must have is stopping the emulation of this input.
If the influence is that it does not complete the simulation, but
aborts it, then the programmer should understand that the
simulated simulation has the same behaviour, causing halting
behaviour.
We have only been talking abort normal termination of a
C function for several weeks. Perhaps you have no
idea what "normal termination" means.
It seems that Olcott does not understand the terminology. It has
been proven by direct execution that the finite string given to HHH
describes a program that terminates normally.
That HHH is unable to reach this normally termination is a failure
of HHH. This failure of HHH does not change the behaviour described
by this finite string.
Aborting a program with halting behaviour
We have not been talking about halting for a long
time. This term has proven to be far too vague.
Normal termination of a C function means reaching
its "return" instruction. Zero vagueness.
Introducing the concept of aborting a program before it can reach
its return instruction to prove its 'non-termination' makes it even
more vague.
does not change it into non- halting. It is childish to claim
that when you close your eyes, things do not happen.
You can't even keep track of what we are talking about.
Change of subject to avoid a honest discussion.
It is childish to claim that things do not happen when you close
your eyes.
When I say that DD emulated by HHH cannot terminate
normally it is flat out dishonest to say that I am
wrong based on another different DD that has different behavior.
That claim is just flat out dishonest, and proves you don't understand
the meaning of the words you are using.
DD emulated by HHH explicitly excludes directly executed DD
that has a different execution trace.
On 2/27/2025 1:20 PM, Fred. Zwarts wrote:
Op 27.feb.2025 om 20:06 schreef olcott:
On 2/27/2025 3:36 AM, Fred. Zwarts wrote:That ignores again the answer to the question.
Op 27.feb.2025 om 05:40 schreef olcott:
On 2/26/2025 9:52 AM, joes wrote:
Am Wed, 26 Feb 2025 08:49:42 -0600 schrieb olcott:
On 2/26/2025 3:48 AM, Fred. Zwarts wrote:
Op 26.feb.2025 om 05:50 schreef olcott:
On 2/25/2025 10:21 PM, Richard Damon wrote:
You already know that you are stupidly wrong about the
emulation being
incorrect or you would have provided the correct emulation
sequence
long ago.
What are the correct first 15 lines of DD emulated by HHH.What are the first 15 lines of DD correctly emulated by HHH?The error in the simulation occurs already at the 5th
instruction, the
'call 000015c3'. Instead of simulating this instruction,
There can be no correct continuation.
I say what the correct simulation is.
You say that I am wrong.
If I am wrong then a correct simulation must exist.
HHH1 did a correct simulation, so, there it is.
That dishonestly dodged the original question:
What are the first 15 *lines of DD* correctly emulated by HHH?
Anything besides a sequence of 15 machine addresses is a WRONG ANSWER
You know this and DISHONESTY DODGE.
On 2/27/2025 2:45 PM, joes wrote:Well, it doesn't *call* D.
Am Thu, 27 Feb 2025 14:13:13 -0600 schrieb olcott:
On 2/27/2025 3:50 AM, Fred. Zwarts wrote:
Op 27.feb.2025 om 06:00 schreef olcott:
On 2/26/2025 5:50 PM, Richard Damon wrote:
On 2/26/25 9:49 AM, olcott wrote:
On 2/26/2025 3:48 AM, Fred. Zwarts wrote:
Op 26.feb.2025 om 05:50 schreef olcott:
On 2/25/2025 10:21 PM, Richard Damon wrote:
You already know that you are stupidly wrong about the emulation >>>>>>>>> being incorrect or you would have provided the correct emulation >>>>>>>>> sequence long ago.
If we assume that HHH emulates the above machine code then there isAnd you are missing the point that HHH can not correctly emulate 15 >>>>>> line of this DD, as it is missing information and thus the task is >>>>>> improperly defined.You dodged the actual question.What are the first 15 lines of DD correctly emulated by HHH?The error in the simulation occurs already at the 5th
instruction,
the 'call 000015c3'. Instead of simulating this instruction,
What are the correct first 15 lines of DD emulated by HHH.
NO MORE relevant information needed and we know that machine address >>>>> 0000213c of DD is followed by machine address 00002133 of DD.
No. Relevant information includes the code at address 0x213c andTHE ONLY FREAKING THING THAT NEED BE KNOWN ABOUT THE CODE AT THAT
everything it points to.
ADDRESS (TO DETERMINE THE SEQUENCE OF MACHINE INSTRUCTIONS OF DD) IS
THAT IT EMULATES THE MACHINE INSTRUCTIONS OF DD.
From this base assumption we know that the firstNo, there is no loop. The repetition only happens in the simulation.
five instructions of DD are repeated three times when the first 15 instructions of DD are emulated.
^Easy. It calls a program that returns *by definition* .If assuming that following the call would lead to infinite recursionIf it was true that the above instance of DD reaches its "ret"
(which is not true, because DD has been proven to halt),
instruction then you could show how it does this.
On 2/27/2025 3:00 PM, joes wrote:It is not wrong, because HHH and its return value are not given in the instructions above.
Am Thu, 27 Feb 2025 13:06:41 -0600 schrieb olcott:
On 2/27/2025 3:36 AM, Fred. Zwarts wrote:Look at what HHH1 does.
Op 27.feb.2025 om 05:40 schreef olcott:That dishonestly dodged the original question:
On 2/26/2025 9:52 AM, joes wrote:HHH1 did a correct simulation, so, there it is.
Am Wed, 26 Feb 2025 08:49:42 -0600 schrieb olcott:If I am wrong then a correct simulation must exist.
On 2/26/2025 3:48 AM, Fred. Zwarts wrote:There can be no correct continuation.
Op 26.feb.2025 om 05:50 schreef olcott:What are the correct first 15 lines of DD emulated by HHH.
On 2/25/2025 10:21 PM, Richard Damon wrote:
You already know that you are stupidly wrong about the emulation >>>>>>>>> being incorrect or you would have provided the correct emulation >>>>>>>>> sequence long ago.The error in the simulation occurs already at the 5th instruction, >>>>>>>> the 'call 000015c3'. Instead of simulating this instruction,
What are the first 15 lines of DD correctly emulated by HHH?
What are the first 15 *lines of DD* correctly emulated by HHH?
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret Size in bytes:(0035) [00002155]
Anyway: ignoring the call to HHH,Is stupidly wrong.
On 2/27/2025 2:45 PM, joes wrote:
Am Thu, 27 Feb 2025 14:13:13 -0600 schrieb olcott:
On 2/27/2025 3:50 AM, Fred. Zwarts wrote:
Op 27.feb.2025 om 06:00 schreef olcott:
On 2/26/2025 5:50 PM, Richard Damon wrote:
On 2/26/25 9:49 AM, olcott wrote:
On 2/26/2025 3:48 AM, Fred. Zwarts wrote:
Op 26.feb.2025 om 05:50 schreef olcott:
On 2/25/2025 10:21 PM, Richard Damon wrote:
You already know that you are stupidly wrong about the emulation >>>>>>>>> being incorrect or you would have provided the correct emulation >>>>>>>>> sequence long ago.
If we assume that HHH emulates the above machine code then there isAnd you are missing the point that HHH can not correctly emulate 15 >>>>>> line of this DD, as it is missing information and thus the task is >>>>>> improperly defined.You dodged the actual question.What are the first 15 lines of DD correctly emulated by HHH?The error in the simulation occurs already at the 5th instruction, >>>>>>>> the 'call 000015c3'. Instead of simulating this instruction,
What are the correct first 15 lines of DD emulated by HHH.
NO MORE relevant information needed and we know that machine address >>>>> 0000213c of DD is followed by machine address 00002133 of DD.
No. Relevant information includes the code at address 0x213c and
everything it points to.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
THE ONLY FREAKING THING THAT NEED BE KNOWN
ABOUT THE CODE AT THAT ADDRESS
(TO DETERMINE THE SEQUENCE OF MACHINE INSTRUCTIONS OF DD)
IS THAT IT EMULATES THE MACHINE INSTRUCTIONS OF DD.
From this base assumption we know that the first
five instructions of DD are repeated three times
when the first 15 instructions of DD are emulated.
On 2/27/2025 7:00 PM, Richard Damon wrote:
On 2/27/25 2:06 PM, olcott wrote:
On 2/27/2025 3:36 AM, Fred. Zwarts wrote:
Op 27.feb.2025 om 05:40 schreef olcott:
On 2/26/2025 9:52 AM, joes wrote:
Am Wed, 26 Feb 2025 08:49:42 -0600 schrieb olcott:
On 2/26/2025 3:48 AM, Fred. Zwarts wrote:
Op 26.feb.2025 om 05:50 schreef olcott:
On 2/25/2025 10:21 PM, Richard Damon wrote:
You already know that you are stupidly wrong about the
emulation being
incorrect or you would have provided the correct emulation
sequence
long ago.
What are the correct first 15 lines of DD emulated by HHH.What are the first 15 lines of DD correctly emulated by HHH?The error in the simulation occurs already at the 5th
instruction, the
'call 000015c3'. Instead of simulating this instruction,
There can be no correct continuation.
I say what the correct simulation is.
You say that I am wrong.
If I am wrong then a correct simulation must exist.
HHH1 did a correct simulation, so, there it is.
That dishonestly dodged the original question:
What are the first 15 *lines of DD* correctly emulated by HHH?
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
PROBLEM BLOWS UP as the value of memory 000015c3 isn't specified as part
When you are told that this address specifies an
x86 emulator then disagreement is incorrect.
100 let x = 5
If you say that you don't believe that x = 5 then you are wrong.
On 2/28/2025 3:01 AM, Fred. Zwarts wrote:
Op 28.feb.2025 om 01:04 schreef olcott:
On 2/27/2025 3:00 PM, joes wrote:It is not wrong, because HHH and its return value are not given in the
Am Thu, 27 Feb 2025 13:06:41 -0600 schrieb olcott:Is stupidly wrong.
On 2/27/2025 3:36 AM, Fred. Zwarts wrote:Look at what HHH1 does.
Op 27.feb.2025 om 05:40 schreef olcott:That dishonestly dodged the original question:
On 2/26/2025 9:52 AM, joes wrote:HHH1 did a correct simulation, so, there it is.
Am Wed, 26 Feb 2025 08:49:42 -0600 schrieb olcott:If I am wrong then a correct simulation must exist.
On 2/26/2025 3:48 AM, Fred. Zwarts wrote:There can be no correct continuation.
Op 26.feb.2025 om 05:50 schreef olcott:
On 2/25/2025 10:21 PM, Richard Damon wrote:
You already know that you are stupidly wrong about the emulation >>>>>>>>>>> being incorrect or you would have provided the correct emulation >>>>>>>>>>> sequence long ago.
What are the first 15 lines of DD correctly emulated by HHH? >>>>>>>>>> The error in the simulation occurs already at the 5th instruction, >>>>>>>>>> the 'call 000015c3'. Instead of simulating this instruction, >>>>>>>>> What are the correct first 15 lines of DD emulated by HHH.
What are the first 15 *lines of DD* correctly emulated by HHH?
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local >>>>> [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret Size in bytes:(0035) [00002155]
Anyway: ignoring the call to HHH,
instructions above.
But if we assume that it is Olcotts's HHH that returns 0, we can
continue with 2141 and then continue up to 2155.
I am no longer going reply to each individual.
I will reply to each point only once.
On 2/28/2025 2:46 AM, joes wrote:Huh? Makes no sense.
Am Thu, 27 Feb 2025 18:04:48 -0600 schrieb olcott:Within the context of the title of this thread knucklehead.
On 2/27/2025 3:00 PM, joes wrote:You only asked for the trace of DD.
Am Thu, 27 Feb 2025 13:06:41 -0600 schrieb olcott:
On 2/27/2025 3:36 AM, Fred. Zwarts wrote:Look at what HHH1 does.
Op 27.feb.2025 om 05:40 schreef olcott:That dishonestly dodged the original question:
On 2/26/2025 9:52 AM, joes wrote:HHH1 did a correct simulation, so, there it is.
Am Wed, 26 Feb 2025 08:49:42 -0600 schrieb olcott:If I am wrong then a correct simulation must exist.
On 2/26/2025 3:48 AM, Fred. Zwarts wrote:There can be no correct continuation.
Op 26.feb.2025 om 05:50 schreef olcott:
On 2/25/2025 10:21 PM, Richard Damon wrote:
You already know that you are stupidly wrong about theinstruction,
emulation being incorrect or you would have provided the >>>>>>>>>>> correct emulation sequence long ago.
What are the first 15 lines of DD correctly emulated by HHH? >>>>>>>>>> The error in the simulation occurs already at the 5th
the 'call 000015c3'. Instead of simulating this instruction, >>>>>>>>> What are the correct first 15 lines of DD emulated by HHH.
What are the first 15 *lines of DD* correctly emulated by HHH?
Anyway: ignoring the call to HHH,Is stupidly wrong.
There are your lines of DD.because it doesn't call DD in turn,
we continue with 2141 until the conditional jump, whereupon we either
enter an infinite loop (which is more than 15 instructions)
or proceed to return (which is 13 instructions), depending on the
return value of HHH.
On 2/28/2025 2:54 AM, joes wrote:Oops, right (unless we run DD, which then calls HHH).
Am Thu, 27 Feb 2025 17:28:58 -0600 schrieb olcott:
On 2/27/2025 2:45 PM, joes wrote:Well, it doesn't *call* D.
Am Thu, 27 Feb 2025 14:13:13 -0600 schrieb olcott:THE ONLY FREAKING THING THAT NEED BE KNOWN ABOUT THE CODE AT THAT
On 2/27/2025 3:50 AM, Fred. Zwarts wrote:No. Relevant information includes the code at address 0x213c and
Op 27.feb.2025 om 06:00 schreef olcott:
On 2/26/2025 5:50 PM, Richard Damon wrote:
On 2/26/25 9:49 AM, olcott wrote:
On 2/26/2025 3:48 AM, Fred. Zwarts wrote:
Op 26.feb.2025 om 05:50 schreef olcott:
On 2/25/2025 10:21 PM, Richard Damon wrote:
You already know that you are stupidly wrong about the
emulation being incorrect or you would have provided the >>>>>>>>>>> correct emulation sequence long ago.
If we assume that HHH emulates the above machine code then there >>>>>>> is NO MORE relevant information needed and we know that machine >>>>>>> address 0000213c of DD is followed by machine address 00002133 of >>>>>>> DD.And you are missing the point that HHH can not correctly emulate >>>>>>>> 15 line of this DD, as it is missing information and thus theWhat are the correct first 15 lines of DD emulated by HHH.What are the first 15 lines of DD correctly emulated by HHH? >>>>>>>>>> The error in the simulation occurs already at the 5thinstruction,
the 'call 000015c3'. Instead of simulating this instruction, >>>>>>>>> You dodged the actual question.
task is improperly defined.
everything it points to.
ADDRESS (TO DETERMINE THE SEQUENCE OF MACHINE INSTRUCTIONS OF DD) IS
THAT IT EMULATES THE MACHINE INSTRUCTIONS OF DD.
Wrong, only HHH is actually running.From this base assumption we know that the firstNo, there is no loop. The repetition only happens in the simulation.
five instructions of DD are repeated three times when the first 15
instructions of DD are emulated.
There are only a single instance of HHH and DD actually running,
HHH maps its input finite string to the behavior that THIS INPUT FINITE STRING SPECIFIES.And DD is a halting program.
That you think it should map this finite string to behavior THAT IT DOESThat's you.
NOT SPECIFY has now become very stupid on your part.
On 2/28/2025 2:53 AM, Fred. Zwarts wrote:
Op 28.feb.2025 om 00:18 schreef olcott:
On 2/27/2025 1:20 PM, Fred. Zwarts wrote:Olcott knows that HHH1
Op 27.feb.2025 om 20:06 schreef olcott:
On 2/27/2025 3:36 AM, Fred. Zwarts wrote:That ignores again the answer to the question.
Op 27.feb.2025 om 05:40 schreef olcott:
On 2/26/2025 9:52 AM, joes wrote:
Am Wed, 26 Feb 2025 08:49:42 -0600 schrieb olcott:
On 2/26/2025 3:48 AM, Fred. Zwarts wrote:
Op 26.feb.2025 om 05:50 schreef olcott:
On 2/25/2025 10:21 PM, Richard Damon wrote:
You already know that you are stupidly wrong about the
emulation being
incorrect or you would have provided the correct emulation >>>>>>>>>>> sequence
long ago.
What are the correct first 15 lines of DD emulated by HHH.What are the first 15 lines of DD correctly emulated by HHH? >>>>>>>>>> The error in the simulation occurs already at the 5thinstruction, the
'call 000015c3'. Instead of simulating this instruction,
There can be no correct continuation.
I say what the correct simulation is.
You say that I am wrong.
If I am wrong then a correct simulation must exist.
HHH1 did a correct simulation, so, there it is.
That dishonestly dodged the original question:
What are the first 15 *lines of DD* correctly emulated by HHH?
Anything besides a sequence of 15 machine addresses is a WRONG ANSWER
You know this and DISHONESTY DODGE.
Does the title of this thread refer to HHH1?
Quit screwing around I may be dead soon.
My cancer treatment is screwing up.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 495 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 43:19:42 |
| Calls: | 9,745 |
| Calls today: | 5 |
| Files: | 13,742 |
| Messages: | 6,183,985 |