On 7/26/2025 1:30 PM, Alan Mackenzie wrote:
In comp.theory olcott <[email protected]> wrote:It only seems to you that I lack understanding because you are so sure
The error of all of the halting problem proofs is that they require a
Turing machine halt decider to report on the behavior of a directly
executed Turing machine.
It is common knowledge that no Turing machine decider can take another
directly executing Turing machine as an input, thus the above
requirement is not precisely correct.
When we correct the error of this incorrect requirement it becomes a
Turing machine decider indirectly reports on the behavior of a
directly executing Turing machine through the proxy of a finite string
description of this machine.
Now I have proven and corrected the error of all of the halting
problem proofs.
No you haven't, the subject matter is too far beyond your intellectual
capacity.
that I must be wrong that you make sure to totally ignore the subtle
nuances of meaning that proves I am correct.
No Turing machine based (at least partial) halt decider can possibly *directly* report on the behavior of any directly executing Turing
machine. The best that any of them can possibly do is indirectly report
on this behavior through the proxy of a finite string machine
description.
On 7/26/2025 2:52 PM, Mr Flibble wrote:
On Sat, 26 Jul 2025 14:26:27 -0500, olcott wrote:
On 7/26/2025 1:30 PM, Alan Mackenzie wrote:
In comp.theory olcott <[email protected]> wrote:It only seems to you that I lack understanding because you are so sure
The error of all of the halting problem proofs is that they require a >>>>> Turing machine halt decider to report on the behavior of a directly
executed Turing machine.
It is common knowledge that no Turing machine decider can take another >>>>> directly executing Turing machine as an input, thus the above
requirement is not precisely correct.
When we correct the error of this incorrect requirement it becomes a >>>>> Turing machine decider indirectly reports on the behavior of a
directly executing Turing machine through the proxy of a finite string >>>>> description of this machine.
Now I have proven and corrected the error of all of the halting
problem proofs.
No you haven't, the subject matter is too far beyond your intellectual >>>> capacity.
that I must be wrong that you make sure to totally ignore the subtle
nuances of meaning that proves I am correct.
No Turing machine based (at least partial) halt decider can possibly
*directly* report on the behavior of any directly executing Turing
machine. The best that any of them can possibly do is indirectly report >>> on this behavior through the proxy of a finite string machine
description.
Partial decidability is not a hard problem.
/Flibble
My point is that all of the halting problem proofs
are wrong when they require a Turing machine decider
H to report on the behavior of machine M on input i
because machine M is not in the domain of any Turing
machine decider. Only finite strings such as ⟨M⟩ the
Turing machine description of machine M are its
domain.
On 7/26/2025 5:49 PM, olcott wrote:
On 7/26/2025 2:58 PM, olcott wrote:
On 7/26/2025 2:52 PM, Mr Flibble wrote:
On Sat, 26 Jul 2025 14:26:27 -0500, olcott wrote:
On 7/26/2025 1:30 PM, Alan Mackenzie wrote:
In comp.theory olcott <[email protected]> wrote:It only seems to you that I lack understanding because you are so sure >>>>> that I must be wrong that you make sure to totally ignore the subtle >>>>> nuances of meaning that proves I am correct.
The error of all of the halting problem proofs is that they
require a
Turing machine halt decider to report on the behavior of a directly >>>>>>> executed Turing machine.
It is common knowledge that no Turing machine decider can take
another
directly executing Turing machine as an input, thus the above
requirement is not precisely correct.
When we correct the error of this incorrect requirement it becomes a >>>>>>> Turing machine decider indirectly reports on the behavior of a
directly executing Turing machine through the proxy of a finite
string
description of this machine.
Now I have proven and corrected the error of all of the halting
problem proofs.
No you haven't, the subject matter is too far beyond your
intellectual
capacity.
No Turing machine based (at least partial) halt decider can possibly >>>>> *directly* report on the behavior of any directly executing Turing
machine. The best that any of them can possibly do is indirectly
report
on this behavior through the proxy of a finite string machine
description.
Partial decidability is not a hard problem.
/Flibble
My point is that all of the halting problem proofs
are wrong when they require a Turing machine decider
H to report on the behavior of machine M on input i
because machine M is not in the domain of any Turing
machine decider. Only finite strings such as ⟨M⟩ the
Turing machine description of machine M are its
domain.
Definition of Turing Machine Ĥ
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and // incorrect requirement
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt. // incorrect requirement >>
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
The fact that the correctly simulated input
specifies recursive simulation prevents the
simulated ⟨Ĥ⟩ from ever reaching its simulated
final halt state of ⟨Ĥ.qn⟩, thus specifies non-termination.
This is not contradicted by the fact that
Ĥ applied to ⟨Ĥ⟩ halts because Ĥ is outside of
the domain of every Turing machine computed function.
In the atypical case where the behavior of the simulation
of an input to a potential halt decider disagrees with the
behavior of the direct execution of the underlying machine
(because this input calls this same simulating decider) it
is the behavior of the input that rules because deciders
compute the mapping for their inputs.
On 7/26/2025 6:18 PM, Richard Damon wrote:
On 7/26/25 3:58 PM, olcott wrote:
On 7/26/2025 2:52 PM, Mr Flibble wrote:
On Sat, 26 Jul 2025 14:26:27 -0500, olcott wrote:
On 7/26/2025 1:30 PM, Alan Mackenzie wrote:
In comp.theory olcott <[email protected]> wrote:It only seems to you that I lack understanding because you are so sure >>>>> that I must be wrong that you make sure to totally ignore the subtle >>>>> nuances of meaning that proves I am correct.
The error of all of the halting problem proofs is that they
require a
Turing machine halt decider to report on the behavior of a directly >>>>>>> executed Turing machine.
It is common knowledge that no Turing machine decider can take
another
directly executing Turing machine as an input, thus the above
requirement is not precisely correct.
When we correct the error of this incorrect requirement it becomes a >>>>>>> Turing machine decider indirectly reports on the behavior of a
directly executing Turing machine through the proxy of a finite
string
description of this machine.
Now I have proven and corrected the error of all of the halting
problem proofs.
No you haven't, the subject matter is too far beyond your
intellectual
capacity.
No Turing machine based (at least partial) halt decider can possibly >>>>> *directly* report on the behavior of any directly executing Turing
machine. The best that any of them can possibly do is indirectly
report
on this behavior through the proxy of a finite string machine
description.
Partial decidability is not a hard problem.
/Flibble
My point is that all of the halting problem proofs
are wrong when they require a Turing machine decider
H to report on the behavior of machine M on input i
because machine M is not in the domain of any Turing
machine decider. Only finite strings such as ⟨M⟩ the
Turing machine description of machine M are its
domain.
No, you just prove that you are too stupid to understand how
representations work.
No is it that you are too stupid to understand WHY
they don't always work.
On 7/26/2025 6:35 PM, Richard Damon wrote:
On 7/26/25 7:08 PM, olcott wrote:
On 7/26/2025 5:49 PM, olcott wrote:
On 7/26/2025 2:58 PM, olcott wrote:
On 7/26/2025 2:52 PM, Mr Flibble wrote:
On Sat, 26 Jul 2025 14:26:27 -0500, olcott wrote:
On 7/26/2025 1:30 PM, Alan Mackenzie wrote:
In comp.theory olcott <[email protected]> wrote:It only seems to you that I lack understanding because you are so >>>>>>> sure
The error of all of the halting problem proofs is that they
require a
Turing machine halt decider to report on the behavior of a
directly
executed Turing machine.
It is common knowledge that no Turing machine decider can take >>>>>>>>> another
directly executing Turing machine as an input, thus the above >>>>>>>>> requirement is not precisely correct.
When we correct the error of this incorrect requirement it
becomes a
Turing machine decider indirectly reports on the behavior of a >>>>>>>>> directly executing Turing machine through the proxy of a finite >>>>>>>>> string
description of this machine.
Now I have proven and corrected the error of all of the halting >>>>>>>>> problem proofs.
No you haven't, the subject matter is too far beyond your
intellectual
capacity.
that I must be wrong that you make sure to totally ignore the subtle >>>>>>> nuances of meaning that proves I am correct.
No Turing machine based (at least partial) halt decider can possibly >>>>>>> *directly* report on the behavior of any directly executing Turing >>>>>>> machine. The best that any of them can possibly do is indirectly >>>>>>> report
on this behavior through the proxy of a finite string machine
description.
Partial decidability is not a hard problem.
/Flibble
My point is that all of the halting problem proofs
are wrong when they require a Turing machine decider
H to report on the behavior of machine M on input i
because machine M is not in the domain of any Turing
machine decider. Only finite strings such as ⟨M⟩ the
Turing machine description of machine M are its
domain.
Definition of Turing Machine Ĥ
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and // incorrect requirement
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt. // incorrect requirement
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
The fact that the correctly simulated input
specifies recursive simulation prevents the
simulated ⟨Ĥ⟩ from ever reaching its simulated
final halt state of ⟨Ĥ.qn⟩, thus specifies non-termination.
This is not contradicted by the fact that
Ĥ applied to ⟨Ĥ⟩ halts because Ĥ is outside of
the domain of every Turing machine computed function.
In the atypical case where the behavior of the simulation
of an input to a potential halt decider disagrees with the
behavior of the direct execution of the underlying machine
(because this input calls this same simulating decider) it
is the behavior of the input that rules because deciders
compute the mapping for their inputs.
Nope, just more of your lies.
The behavior of an input to a halt decider is DEFINED in all cases to
be the behavior of the machine the input represents,
Yet I have conclusively proven otherwise and
you are too stupid to understand the proof.
You are so stupid that you think you can get
away with disagreeing with the x86 language.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD simulated by HHH according to the rules of the
x86 language does not fucking halt you fucking moron.
If any definition says otherwise then this definition
is fucked up.
On 7/26/2025 8:30 PM, Richard Damon wrote:
On 7/26/25 7:43 PM, olcott wrote:
On 7/26/2025 6:35 PM, Richard Damon wrote:
On 7/26/25 7:08 PM, olcott wrote:
On 7/26/2025 5:49 PM, olcott wrote:
On 7/26/2025 2:58 PM, olcott wrote:
On 7/26/2025 2:52 PM, Mr Flibble wrote:
On Sat, 26 Jul 2025 14:26:27 -0500, olcott wrote:
On 7/26/2025 1:30 PM, Alan Mackenzie wrote:
In comp.theory olcott <[email protected]> wrote:It only seems to you that I lack understanding because you are >>>>>>>>> so sure
The error of all of the halting problem proofs is that they >>>>>>>>>>> require a
Turing machine halt decider to report on the behavior of a >>>>>>>>>>> directly
executed Turing machine.
It is common knowledge that no Turing machine decider can >>>>>>>>>>> take another
directly executing Turing machine as an input, thus the above >>>>>>>>>>> requirement is not precisely correct.
When we correct the error of this incorrect requirement it >>>>>>>>>>> becomes a
Turing machine decider indirectly reports on the behavior of a >>>>>>>>>>> directly executing Turing machine through the proxy of a >>>>>>>>>>> finite string
description of this machine.
Now I have proven and corrected the error of all of the halting >>>>>>>>>>> problem proofs.
No you haven't, the subject matter is too far beyond your
intellectual
capacity.
that I must be wrong that you make sure to totally ignore the >>>>>>>>> subtle
nuances of meaning that proves I am correct.
No Turing machine based (at least partial) halt decider can
possibly
*directly* report on the behavior of any directly executing Turing >>>>>>>>> machine. The best that any of them can possibly do is
indirectly report
on this behavior through the proxy of a finite string machine >>>>>>>>> description.
Partial decidability is not a hard problem.
/Flibble
My point is that all of the halting problem proofs
are wrong when they require a Turing machine decider
H to report on the behavior of machine M on input i
because machine M is not in the domain of any Turing
machine decider. Only finite strings such as ⟨M⟩ the
Turing machine description of machine M are its
domain.
Definition of Turing Machine Ĥ
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and // incorrect requirement
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt. // incorrect requirement
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
The fact that the correctly simulated input
specifies recursive simulation prevents the
simulated ⟨Ĥ⟩ from ever reaching its simulated
final halt state of ⟨Ĥ.qn⟩, thus specifies non-termination.
This is not contradicted by the fact that
Ĥ applied to ⟨Ĥ⟩ halts because Ĥ is outside of
the domain of every Turing machine computed function.
In the atypical case where the behavior of the simulation
of an input to a potential halt decider disagrees with the
behavior of the direct execution of the underlying machine
(because this input calls this same simulating decider) it
is the behavior of the input that rules because deciders
compute the mapping for their inputs.
Nope, just more of your lies.
The behavior of an input to a halt decider is DEFINED in all cases
to be the behavior of the machine the input represents,
Yet I have conclusively proven otherwise and
you are too stupid to understand the proof.
No, because you proof needs to call different inputs the same or
partial simulaiton to be correct.
When HHH(DDD) simulates DDD it also simulates itself
simulating DDD because DDD calls HHH(DDD).
When HHH1(DDD) simulates DDD DOES NOT simulate itself
simulating DDD because DDD DOES NOT CALL HHH1(DDD).
For three fucking years everyone here pretended that
they could NOT fucking see that.
On 7/27/2025 6:11 AM, Richard Damon wrote:
On 7/26/25 10:43 PM, olcott wrote:>>
When HHH(DDD) simulates DDD it also simulates itself
simulating DDD because DDD calls HHH(DDD).
But can only do that if HHH is part of its input, or it is not
simulating its input.
And, it FAILS at simulating itself, as it concludes that HHH(DDD) will
never return, when it does.
This ChatGPT analysis of its input below
correctly derives both of our views. I did
not bias this analysis by telling ChatGPT
what I expect to see.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
DDD();
}
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It detects a non-terminating behavior pattern then it aborts its simulation and returns 0,
(b) Its simulated input reaches its simulated "return" statement then it returns 1.
https://chatgpt.com/share/688521d8-e5fc-8011-9d7c-0d77ac83706c
On 7/27/2025 2:58 PM, Richard Damon wrote:
On 7/27/25 9:50 AM, olcott wrote:
On 7/27/2025 6:11 AM, Richard Damon wrote:
On 7/26/25 10:43 PM, olcott wrote:>>
When HHH(DDD) simulates DDD it also simulates itself
simulating DDD because DDD calls HHH(DDD).
But can only do that if HHH is part of its input, or it is not
simulating its input.
And, it FAILS at simulating itself, as it concludes that HHH(DDD)
will never return, when it does.
This ChatGPT analysis of its input below
correctly derives both of our views. I did
not bias this analysis by telling ChatGPT
what I expect to see.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
DDD();
}
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) It detects a non-terminating behavior pattern then it aborts its
simulation and returns 0,
(b) Its simulated input reaches its simulated "return" statement then
it returns 1.
https://chatgpt.com/share/688521d8-e5fc-8011-9d7c-0d77ac83706c
Just proves that you have contaminated the learning with false idea
about programs.
I made sure that ChatGPT isolates this conversation
from everything else that I ever said. Besides telling
ChatGPT about the possibility of a simulating termination
analyzer (that I have proved does work on some inputs)
it figured out all the rest on its own without any
prompting from me.
On 7/27/2025 4:31 PM, Richard Damon wrote:
On 7/27/25 4:28 PM, olcott wrote:
On 7/27/2025 2:58 PM, Richard Damon wrote:
On 7/27/25 9:50 AM, olcott wrote:
On 7/27/2025 6:11 AM, Richard Damon wrote:
On 7/26/25 10:43 PM, olcott wrote:>>
When HHH(DDD) simulates DDD it also simulates itself
simulating DDD because DDD calls HHH(DDD).
But can only do that if HHH is part of its input, or it is not
simulating its input.
And, it FAILS at simulating itself, as it concludes that HHH(DDD)
will never return, when it does.
This ChatGPT analysis of its input below
correctly derives both of our views. I did
not bias this analysis by telling ChatGPT
what I expect to see.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
DDD();
}
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) It detects a non-terminating behavior pattern then it aborts
its simulation and returns 0,
(b) Its simulated input reaches its simulated "return" statement
then it returns 1.
https://chatgpt.com/share/688521d8-e5fc-8011-9d7c-0d77ac83706c
Just proves that you have contaminated the learning with false idea
about programs.
I made sure that ChatGPT isolates this conversation
from everything else that I ever said. Besides telling
ChatGPT about the possibility of a simulating termination
analyzer (that I have proved does work on some inputs)
it figured out all the rest on its own without any
prompting from me.
You CAN'T totally isolate it. You can tell it to not use what you have
told it previously (which you did not do),
ChatGPT remember prior conversations
is turned off
My Account
Settings
Personalization
Memory
Reference saved memories
This is important because I need to know the
minimum basis that it needs to understand what
I said so that I can know that I have no gaps
in my reasoning.
but anything said to the AI, has a chance of being recorded and used
for future training.
During periodic updates.
Just think, you might be the one responsible for providing the lies
that future AIs have decided to accept ruining the chance of some
future breakthrough.
The above input that I provided has zero falsehoods.
ChatGPT figured out all of the reasoning from that
basis.
On 7/27/2025 7:07 PM, Richard Damon wrote:
On 7/27/25 5:46 PM, olcott wrote:
On 7/27/2025 4:31 PM, Richard Damon wrote:
On 7/27/25 4:28 PM, olcott wrote:
On 7/27/2025 2:58 PM, Richard Damon wrote:
On 7/27/25 9:50 AM, olcott wrote:
On 7/27/2025 6:11 AM, Richard Damon wrote:
On 7/26/25 10:43 PM, olcott wrote:>>
When HHH(DDD) simulates DDD it also simulates itself
simulating DDD because DDD calls HHH(DDD).
But can only do that if HHH is part of its input, or it is not >>>>>>>> simulating its input.
And, it FAILS at simulating itself, as it concludes that
HHH(DDD) will never return, when it does.
This ChatGPT analysis of its input below
correctly derives both of our views. I did
not bias this analysis by telling ChatGPT
what I expect to see.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
DDD();
}
Simulating Termination Analyzer HHH correctly simulates its input >>>>>>> until:
(a) It detects a non-terminating behavior pattern then it aborts >>>>>>> its simulation and returns 0,
(b) Its simulated input reaches its simulated "return" statement >>>>>>> then it returns 1.
https://chatgpt.com/share/688521d8-e5fc-8011-9d7c-0d77ac83706c
Just proves that you have contaminated the learning with false
idea about programs.
I made sure that ChatGPT isolates this conversation
from everything else that I ever said. Besides telling
ChatGPT about the possibility of a simulating termination
analyzer (that I have proved does work on some inputs)
it figured out all the rest on its own without any
prompting from me.
You CAN'T totally isolate it. You can tell it to not use what you
have told it previously (which you did not do),
ChatGPT remember prior conversations
is turned off
My Account
Settings
Personalization
Memory
Reference saved memories
This is important because I need to know the
minimum basis that it needs to understand what
I said so that I can know that I have no gaps
in my reasoning.
But that setting isn't perfect.
but anything said to the AI, has a chance of being recorded and used
for future training.
During periodic updates.
And you have been posting your lies on usenet, which is a source of
training, for awhile.
Just think, you might be the one responsible for providing the lies
that future AIs have decided to accept ruining the chance of some
future breakthrough.
The above input that I provided has zero falsehoods.
ChatGPT figured out all of the reasoning from that
basis.
But. not full definitions, like the fact that a given program on a
given input will always do the same thing.
When DDD is emulated by HHH it must emulate
DDD calling itself in recursive emulation.
When DDD is emulated by HHH1 it need not emulate
itself at all.
Everyone here has pretended to be to fucking stupid
to see that for three fucking years thus providing
sufficient evidence that they are all damned liars.
On 7/26/2025 6:35 PM, Richard Damon wrote:
On 7/26/25 7:08 PM, olcott wrote:
On 7/26/2025 5:49 PM, olcott wrote:
On 7/26/2025 2:58 PM, olcott wrote:
On 7/26/2025 2:52 PM, Mr Flibble wrote:
On Sat, 26 Jul 2025 14:26:27 -0500, olcott wrote:
On 7/26/2025 1:30 PM, Alan Mackenzie wrote:
In comp.theory olcott <[email protected]> wrote:It only seems to you that I lack understanding because you are so >>>>>>> sure
The error of all of the halting problem proofs is that they
require a
Turing machine halt decider to report on the behavior of a
directly
executed Turing machine.
It is common knowledge that no Turing machine decider can take >>>>>>>>> another
directly executing Turing machine as an input, thus the above >>>>>>>>> requirement is not precisely correct.
When we correct the error of this incorrect requirement it
becomes a
Turing machine decider indirectly reports on the behavior of a >>>>>>>>> directly executing Turing machine through the proxy of a finite >>>>>>>>> string
description of this machine.
Now I have proven and corrected the error of all of the halting >>>>>>>>> problem proofs.
No you haven't, the subject matter is too far beyond your
intellectual
capacity.
that I must be wrong that you make sure to totally ignore the subtle >>>>>>> nuances of meaning that proves I am correct.
No Turing machine based (at least partial) halt decider can possibly >>>>>>> *directly* report on the behavior of any directly executing Turing >>>>>>> machine. The best that any of them can possibly do is indirectly >>>>>>> report
on this behavior through the proxy of a finite string machine
description.
Partial decidability is not a hard problem.
/Flibble
My point is that all of the halting problem proofs
are wrong when they require a Turing machine decider
H to report on the behavior of machine M on input i
because machine M is not in the domain of any Turing
machine decider. Only finite strings such as ⟨M⟩ the
Turing machine description of machine M are its
domain.
Definition of Turing Machine Ĥ
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and // incorrect requirement
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt. // incorrect requirement
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
The fact that the correctly simulated input
specifies recursive simulation prevents the
simulated ⟨Ĥ⟩ from ever reaching its simulated
final halt state of ⟨Ĥ.qn⟩, thus specifies non-termination.
This is not contradicted by the fact that
Ĥ applied to ⟨Ĥ⟩ halts because Ĥ is outside of
the domain of every Turing machine computed function.
In the atypical case where the behavior of the simulation
of an input to a potential halt decider disagrees with the
behavior of the direct execution of the underlying machine
(because this input calls this same simulating decider) it
is the behavior of the input that rules because deciders
compute the mapping for their inputs.
Nope, just more of your lies.
The behavior of an input to a halt decider is DEFINED in all cases to
be the behavior of the machine the input represents,
Yet I have conclusively proven otherwise and
you are too stupid to understand the proof.
You are so stupid that you think you can get
away with disagreeing with the x86 language.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD simulated by HHH according to the rules of the
x86 language does not fucking halt you fucking moron.
If any definition says otherwise then this definition
is fucked up.
On 7/26/2025 5:49 PM, olcott wrote:
On 7/26/2025 2:58 PM, olcott wrote:
On 7/26/2025 2:52 PM, Mr Flibble wrote:
On Sat, 26 Jul 2025 14:26:27 -0500, olcott wrote:
On 7/26/2025 1:30 PM, Alan Mackenzie wrote:
In comp.theory olcott <[email protected]> wrote:It only seems to you that I lack understanding because you are so sure >>>>> that I must be wrong that you make sure to totally ignore the subtle >>>>> nuances of meaning that proves I am correct.
The error of all of the halting problem proofs is that they
require a
Turing machine halt decider to report on the behavior of a directly >>>>>>> executed Turing machine.
It is common knowledge that no Turing machine decider can take
another
directly executing Turing machine as an input, thus the above
requirement is not precisely correct.
When we correct the error of this incorrect requirement it becomes a >>>>>>> Turing machine decider indirectly reports on the behavior of a
directly executing Turing machine through the proxy of a finite
string
description of this machine.
Now I have proven and corrected the error of all of the halting
problem proofs.
No you haven't, the subject matter is too far beyond your
intellectual
capacity.
No Turing machine based (at least partial) halt decider can possibly >>>>> *directly* report on the behavior of any directly executing Turing
machine. The best that any of them can possibly do is indirectly
report
on this behavior through the proxy of a finite string machine
description.
Partial decidability is not a hard problem.
/Flibble
My point is that all of the halting problem proofs
are wrong when they require a Turing machine decider
H to report on the behavior of machine M on input i
because machine M is not in the domain of any Turing
machine decider. Only finite strings such as ⟨M⟩ the
Turing machine description of machine M are its
domain.
Definition of Turing Machine Ĥ
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and // incorrect requirement
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt. // incorrect requirement >>
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
The fact that the correctly simulated input
specifies recursive simulation prevents the
simulated ⟨Ĥ⟩ from ever reaching its simulated
final halt state of ⟨Ĥ.qn⟩, thus specifies non-termination.
This is not contradicted by the fact that
Ĥ applied to ⟨Ĥ⟩ halts because Ĥ is outside of
the domain of every Turing machine computed function.
In the atypical case where the behavior of the simulation
of an input to a potential halt decider disagrees with the
behavior of the direct execution of the underlying machine
(because this input calls this same simulating decider) it
is the behavior of the input that rules because deciders
compute the mapping *FROM* their inputs.
On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:By itself I mean the exact same machine code bytes
On 7/27/2025 7:07 PM, Richard Damon wrote:
On 7/27/25 5:46 PM, olcott wrote:
On 7/27/2025 4:31 PM, Richard Damon wrote:
On 7/27/25 4:28 PM, olcott wrote:
On 7/27/2025 2:58 PM, Richard Damon wrote:
On 7/27/25 9:50 AM, olcott wrote:
On 7/27/2025 6:11 AM, Richard Damon wrote:
On 7/26/25 10:43 PM, olcott wrote:>>
When HHH(DDD) simulates DDD it also simulates itself
simulating DDD because DDD calls HHH(DDD).
But can only do that if HHH is part of its input, or it is not >>>>>>>>>> simulating its input.
And, it FAILS at simulating itself, as it concludes that
HHH(DDD) will never return, when it does.
This ChatGPT analysis of its input below
correctly derives both of our views. I did
not bias this analysis by telling ChatGPT
what I expect to see.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
DDD();
}
Simulating Termination Analyzer HHH correctly simulates its
input until:
(a) It detects a non-terminating behavior pattern then it
aborts its simulation and returns 0,
(b) Its simulated input reaches its simulated "return"
statement then it returns 1.
https://chatgpt.com/share/688521d8-e5fc-8011-9d7c-0d77ac83706c >>>>>>>>>
Just proves that you have contaminated the learning with false >>>>>>>> idea about programs.
I made sure that ChatGPT isolates this conversation
from everything else that I ever said. Besides telling
ChatGPT about the possibility of a simulating termination
analyzer (that I have proved does work on some inputs)
it figured out all the rest on its own without any
prompting from me.
You CAN'T totally isolate it. You can tell it to not use what you
have told it previously (which you did not do),
ChatGPT remember prior conversations
is turned off
My Account
Settings
Personalization
Memory
Reference saved memories
This is important because I need to know the
minimum basis that it needs to understand what
I said so that I can know that I have no gaps
in my reasoning.
But that setting isn't perfect.
but anything said to the AI, has a chance of being recorded and
used for future training.
During periodic updates.
And you have been posting your lies on usenet, which is a source of
training, for awhile.
Just think, you might be the one responsible for providing the
lies that future AIs have decided to accept ruining the chance of
some future breakthrough.
The above input that I provided has zero falsehoods.
ChatGPT figured out all of the reasoning from that
basis.
But. not full definitions, like the fact that a given program on a
given input will always do the same thing.
When DDD is emulated by HHH it must emulate
DDD calling itself in recursive emulation.
When DDD is emulated by HHH1 it need not emulate
itself at all.
But "itself" doesn't matter to x86 instructions,
at the exact same machine address.
On 7/28/2025 6:38 AM, Richard Damon wrote:
On 7/27/25 10:58 PM, olcott wrote:
On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:By itself I mean the exact same machine code bytes
On 7/27/2025 7:07 PM, Richard Damon wrote:
On 7/27/25 5:46 PM, olcott wrote:
On 7/27/2025 4:31 PM, Richard Damon wrote:
On 7/27/25 4:28 PM, olcott wrote:
On 7/27/2025 2:58 PM, Richard Damon wrote:
On 7/27/25 9:50 AM, olcott wrote:
On 7/27/2025 6:11 AM, Richard Damon wrote:
On 7/26/25 10:43 PM, olcott wrote:>>
When HHH(DDD) simulates DDD it also simulates itself >>>>>>>>>>>>> simulating DDD because DDD calls HHH(DDD).
But can only do that if HHH is part of its input, or it is >>>>>>>>>>>> not simulating its input.
And, it FAILS at simulating itself, as it concludes that >>>>>>>>>>>> HHH(DDD) will never return, when it does.
This ChatGPT analysis of its input below
correctly derives both of our views. I did
not bias this analysis by telling ChatGPT
what I expect to see.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
DDD();
}
Simulating Termination Analyzer HHH correctly simulates its >>>>>>>>>>> input until:
(a) It detects a non-terminating behavior pattern then it >>>>>>>>>>> aborts its simulation and returns 0,
(b) Its simulated input reaches its simulated "return"
statement then it returns 1.
https://chatgpt.com/share/688521d8-e5fc-8011-9d7c-0d77ac83706c >>>>>>>>>>>
Just proves that you have contaminated the learning with false >>>>>>>>>> idea about programs.
I made sure that ChatGPT isolates this conversation
from everything else that I ever said. Besides telling
ChatGPT about the possibility of a simulating termination
analyzer (that I have proved does work on some inputs)
it figured out all the rest on its own without any
prompting from me.
You CAN'T totally isolate it. You can tell it to not use what
you have told it previously (which you did not do),
ChatGPT remember prior conversations
is turned off
My Account
Settings
Personalization
Memory
Reference saved memories
This is important because I need to know the
minimum basis that it needs to understand what
I said so that I can know that I have no gaps
in my reasoning.
But that setting isn't perfect.
but anything said to the AI, has a chance of being recorded and >>>>>>>> used for future training.
During periodic updates.
And you have been posting your lies on usenet, which is a source
of training, for awhile.
Just think, you might be the one responsible for providing the >>>>>>>> lies that future AIs have decided to accept ruining the chance >>>>>>>> of some future breakthrough.
The above input that I provided has zero falsehoods.
ChatGPT figured out all of the reasoning from that
basis.
But. not full definitions, like the fact that a given program on a >>>>>> given input will always do the same thing.
When DDD is emulated by HHH it must emulate
DDD calling itself in recursive emulation.
When DDD is emulated by HHH1 it need not emulate
itself at all.
But "itself" doesn't matter to x86 instructions,
at the exact same machine address.
Which doesn't affect the behavior of those bytes.
void DDD()
{
HHH(DDD);
return;
}
That you are too stupid to understand that DDD simulated
by HHH does call HHH in recursive emulation even after
I have provided fully operational code of DDD calling
HHH(DDD) in recursive emulation *IS NOT A REBUTTAL*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
On 7/28/2025 6:49 PM, Richard Damon wrote:
On 7/28/25 7:20 PM, olcott wrote:
On 7/28/2025 5:57 PM, Richard Damon wrote:
On 7/28/25 9:54 AM, olcott wrote:
On 7/28/2025 8:21 AM, joes wrote:
Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:
On 7/28/2025 2:30 AM, joes wrote:
Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:
On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:
Yeah, so when you change HHH to abort later, you also change DDD. >>>>>>> HHH is never changed.By itself I mean the exact same machine code bytes at the exact >>>>>>>>> sameWhen DDD is emulated by HHH1 it need not emulate itself at all. >>>>>>>>>> But "itself" doesn't matter to x86 instructions,
machine address.
It is changed in the hypothetical unaborted simulation. HHH is
reporting
on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the
halting DDD,
and definitely not on HHH(DDD), itself.
All halt deciders are required to predict the behavior
of their input. HHH does correctly predict that DDD correctly
simulated by HHH cannot possibly reach its own simulated
"return" instruction final halt state.
How is it a "correct prediction" if it sees something different than
what that DDD does.
What DDD does is keep calling HHH(DDD) in recursive
simulation until HHH kills this whole process.
But the behavior of the program continues past that (something you
don't seem to understand) and that behavior will also have its HHH
terminate the DDD it is simulating and return 0 to DDD and then Halt.
Your problem is you don't understand that the simulating HHH doesn't
define the behavior of DDD, it is the execution of DDD that defines
what a correct simulation of it is.
Remember, to have simulated that DDD, it must have include the code
of the HHH that it was based on, which is the HHH that made the
prediction, and thus returns 0, so DDD will halt.
We are not asking: Does DDD() halt.
That is (as it turns out) an incorrect question.
No, that is EXACTLY the question.
I guess you are just admitting that you whole world is based on LYING
about what things are supposed to be.
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Right, and HHH was given the equivalenet of (M) by being given the
code of *ALL* of DDD
I guess you don't understand that fact, even though you CLAIM the
input is the proper representation of DDD.
Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.
No, it is DEFINED to be the behavior of the direct execution of the
program it represent.
*That has always been the fatal flaw of all of the proofs*
We could equally define the area of a square circle
as its radius multiplied by the length of one of its sides.
It never has been that DDD simulated by HHH is incorrect
because it does not agree with what people expect to see.
It has always been that it is correct because it matches
the semantics that the code specifies.
DDD simulated by HHH specifies that DDD keeps calling
HHH in recursive simulation until HHH kills the whole
process of DDD.
On 7/28/2025 6:26 PM, Richard Damon wrote:
On 7/28/25 8:34 AM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
That you are too stupid to understand that DDD simulated
by HHH does call HHH in recursive emulation even after
I have provided fully operational code of DDD calling
HHH(DDD) in recursive emulation *IS NOT A REBUTTAL*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
What you are too stupid to understand is that while the *PROGRAM* HHH,
which does the specific actions it is defined to, when it simulates
the input that represents the *PROGRAM* DDD, which by definition
includes the code of the HHH that it is built on, that will not reach
the final state.
HHH correctly predicts that DDD correctly simulated
by HHH cannot possibly reach its simulated "return"
statement final halt state. This is because DDD does
call HHH(DDD) in recursive simulation.
*Within those exact words I am exactly correct*
Trying to change those *EXACT WORDS* to show that
I am incorrect *IS CHEATING*
After we have mutual agreement *ON THOSE EXACT WORDS*
thenn (then and only then) we can begin discussing
whether or not those words are relevant.
On 7/28/2025 9:00 PM, Richard Damon wrote:
On 7/28/25 7:44 PM, olcott wrote:
On 7/28/2025 6:26 PM, Richard Damon wrote:
On 7/28/25 8:34 AM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
That you are too stupid to understand that DDD simulated
by HHH does call HHH in recursive emulation even after
I have provided fully operational code of DDD calling
HHH(DDD) in recursive emulation *IS NOT A REBUTTAL*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
What you are too stupid to understand is that while the *PROGRAM*
HHH, which does the specific actions it is defined to, when it
simulates the input that represents the *PROGRAM* DDD, which by
definition includes the code of the HHH that it is built on, that
will not reach the final state.
HHH correctly predicts that DDD correctly simulated
by HHH cannot possibly reach its simulated "return"
statement final halt state. This is because DDD does
call HHH(DDD) in recursive simulation.
Can't do that, as HHH doesn't correct simulate its input, since
correct simulation requires being complete.
Never heard of mathematical induction?
On 7/28/2025 4:13 AM, Fred. Zwarts wrote:
Op 27.jul.2025 om 01:28 schreef olcott:It never was the actual input that specifies non-halting
On 7/26/2025 5:49 PM, olcott wrote:
On 7/26/2025 2:58 PM, olcott wrote:
On 7/26/2025 2:52 PM, Mr Flibble wrote:
On Sat, 26 Jul 2025 14:26:27 -0500, olcott wrote:
On 7/26/2025 1:30 PM, Alan Mackenzie wrote:
In comp.theory olcott <[email protected]> wrote:It only seems to you that I lack understanding because you are so >>>>>>> sure
The error of all of the halting problem proofs is that they
require a
Turing machine halt decider to report on the behavior of a
directly
executed Turing machine.
It is common knowledge that no Turing machine decider can take >>>>>>>>> another
directly executing Turing machine as an input, thus the above >>>>>>>>> requirement is not precisely correct.
When we correct the error of this incorrect requirement it
becomes a
Turing machine decider indirectly reports on the behavior of a >>>>>>>>> directly executing Turing machine through the proxy of a finite >>>>>>>>> string
description of this machine.
Now I have proven and corrected the error of all of the halting >>>>>>>>> problem proofs.
No you haven't, the subject matter is too far beyond your
intellectual
capacity.
that I must be wrong that you make sure to totally ignore the subtle >>>>>>> nuances of meaning that proves I am correct.
No Turing machine based (at least partial) halt decider can possibly >>>>>>> *directly* report on the behavior of any directly executing Turing >>>>>>> machine. The best that any of them can possibly do is indirectly >>>>>>> report
on this behavior through the proxy of a finite string machine
description.
Partial decidability is not a hard problem.
/Flibble
My point is that all of the halting problem proofs
are wrong when they require a Turing machine decider
H to report on the behavior of machine M on input i
because machine M is not in the domain of any Turing
machine decider. Only finite strings such as ⟨M⟩ the
Turing machine description of machine M are its
domain.
Definition of Turing Machine Ĥ
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and // incorrect requirement
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt. // incorrect requirement
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
The fact that the correctly simulated input
specifies recursive simulation prevents the
simulated ⟨Ĥ⟩ from ever reaching its simulated
final halt state of ⟨Ĥ.qn⟩, thus specifies non-termination.
This is not contradicted by the fact that
Ĥ applied to ⟨Ĥ⟩ halts because Ĥ is outside of
the domain of every Turing machine computed function.
In the atypical case where the behavior of the simulation
of an input to a potential halt decider disagrees with the
behavior of the direct execution of the underlying machine
(because this input calls this same simulating decider) it
is the behavior of the input that rules because deciders
compute the mapping *FROM* their inputs.
But the input specifies halting behaviour,
behavior.
On 7/28/2025 3:57 AM, Fred. Zwarts wrote:
Op 27.jul.2025 om 01:43 schreef olcott:
On 7/26/2025 6:35 PM, Richard Damon wrote:
The behavior of an input to a halt decider is DEFINED in all cases
to be the behavior of the machine the input represents,
Yet I have conclusively proven otherwise and
you are too stupid to understand the proof.
That was not a proof, but an assumption with a huge mistake.
https://www.researchgate.net/publication/394042683_ChatGPT_analyzes_HHHDDD
ChatGPT agrees that HHH(DDD)==0 is correct even though
DDD() halts.
On 7/28/2025 9:36 PM, Richard Damon wrote:
On 7/28/25 10:32 PM, olcott wrote:
On 7/28/2025 9:00 PM, Richard Damon wrote:
On 7/28/25 7:44 PM, olcott wrote:
On 7/28/2025 6:26 PM, Richard Damon wrote:
On 7/28/25 8:34 AM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
That you are too stupid to understand that DDD simulated
by HHH does call HHH in recursive emulation even after
I have provided fully operational code of DDD calling
HHH(DDD) in recursive emulation *IS NOT A REBUTTAL*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
What you are too stupid to understand is that while the *PROGRAM*
HHH, which does the specific actions it is defined to, when it
simulates the input that represents the *PROGRAM* DDD, which by
definition includes the code of the HHH that it is built on, that
will not reach the final state.
HHH correctly predicts that DDD correctly simulated
by HHH cannot possibly reach its simulated "return"
statement final halt state. This is because DDD does
call HHH(DDD) in recursive simulation.
Can't do that, as HHH doesn't correct simulate its input, since
correct simulation requires being complete.
Never heard of mathematical induction?
You don't have a valid induction. The problem is every version of HHH
gets a different version of DDD, so you can't build the induction, as
the n and n+1 steps don't relate.
The only difference in the elements of the infinite
set of HHH/DDD pairs where HHH emulates N instructions
of DDD cannot possibly have any effect on whether this
DDD instance reaches its "return" instruction final
halt state *AND YOU HAVE ALWAYS KNOWN THAT*
On 7/28/2025 9:36 PM, Richard Damon wrote:
On 7/28/25 10:32 PM, olcott wrote:
On 7/28/2025 9:00 PM, Richard Damon wrote:
On 7/28/25 7:44 PM, olcott wrote:
On 7/28/2025 6:26 PM, Richard Damon wrote:
On 7/28/25 8:34 AM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
That you are too stupid to understand that DDD simulated
by HHH does call HHH in recursive emulation even after
I have provided fully operational code of DDD calling
HHH(DDD) in recursive emulation *IS NOT A REBUTTAL*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
What you are too stupid to understand is that while the *PROGRAM*
HHH, which does the specific actions it is defined to, when it
simulates the input that represents the *PROGRAM* DDD, which by
definition includes the code of the HHH that it is built on, that
will not reach the final state.
HHH correctly predicts that DDD correctly simulated
by HHH cannot possibly reach its simulated "return"
statement final halt state. This is because DDD does
call HHH(DDD) in recursive simulation.
Can't do that, as HHH doesn't correct simulate its input, since
correct simulation requires being complete.
Never heard of mathematical induction?
You don't have a valid induction. The problem is every version of HHH
gets a different version of DDD, so you can't build the induction, as
the n and n+1 steps don't relate.
The only difference in the elements of the infinite
set of HHH/DDD pairs where HHH emulates N instructions
of DDD cannot possibly have any effect on whether this
DDD instance reaches its "return" instruction final
halt state *AND YOU HAVE ALWAYS KNOWN THAT*
On 7/28/25 7:58 PM, olcott wrote:
On 7/28/2025 6:49 PM, Richard Damon wrote:
On 7/28/25 7:20 PM, olcott wrote:*That has always been the fatal flaw of all of the proofs*
On 7/28/2025 5:57 PM, Richard Damon wrote:
On 7/28/25 9:54 AM, olcott wrote:What DDD does is keep calling HHH(DDD) in recursive simulation until
On 7/28/2025 8:21 AM, joes wrote:How is it a "correct prediction" if it sees something different than >>>>> what that DDD does.
Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:All halt deciders are required to predict the behavior of their
On 7/28/2025 2:30 AM, joes wrote:
Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:
On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:
HHH is never changed.Yeah, so when you change HHH to abort later, you also change >>>>>>>>> DDD.By itself I mean the exact same machine code bytes at the exact >>>>>>>>>> same machine address.When DDD is emulated by HHH1 it need not emulate itself at >>>>>>>>>>>> all.But "itself" doesn't matter to x86 instructions,
It is changed in the hypothetical unaborted simulation. HHH is
reporting on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on >>>>>>> the halting DDD,
and definitely not on HHH(DDD), itself.
input. HHH does correctly predict that DDD correctly simulated by
HHH cannot possibly reach its own simulated "return" instruction
final halt state.
HHH kills this whole process.
But the behavior of the program continues past that (something you
don't seem to understand) and that behavior will also have its HHH
terminate the DDD it is simulating and return 0 to DDD and then Halt.
Your problem is you don't understand that the simulating HHH doesn't
define the behavior of DDD, it is the execution of DDD that defines
what a correct simulation of it is.
Remember, to have simulated that DDD, it must have include the codeWe are not asking: Does DDD() halt.
of the HHH that it was based on, which is the HHH that made the
prediction, and thus returns 0, so DDD will halt.
That is (as it turns out) an incorrect question.
No, that is EXACTLY the question.
I guess you are just admitting that you whole world is based on LYING
about what things are supposed to be.
Turing machines cannot directly report on the behavior of other
Turing machines they can at best indirectly report on the behavior of
Turing machines through the proxy of finite string machine
descriptions such as ⟨M⟩.
Right, and HHH was given the equivalenet of (M) by being given the
code of *ALL* of DDD
I guess you don't understand that fact, even though you CLAIM the
input is the proper representation of DDD.
Thus the behavior specified by the input finite string overrules and
supersedes the behavior of the direct execution.
No, it is DEFINED to be the behavior of the direct execution of the
program it represent.
No, your failure to follow the rules is what makes you just a liar.
On Mon, 28 Jul 2025 21:56:16 -0400, Richard Damon wrote:
On 7/28/25 7:58 PM, olcott wrote:
On 7/28/2025 6:49 PM, Richard Damon wrote:
On 7/28/25 7:20 PM, olcott wrote:*That has always been the fatal flaw of all of the proofs*
On 7/28/2025 5:57 PM, Richard Damon wrote:
On 7/28/25 9:54 AM, olcott wrote:What DDD does is keep calling HHH(DDD) in recursive simulation until >>>>> HHH kills this whole process.
On 7/28/2025 8:21 AM, joes wrote:How is it a "correct prediction" if it sees something different than >>>>>> what that DDD does.
Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:All halt deciders are required to predict the behavior of their
On 7/28/2025 2:30 AM, joes wrote:
Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:
On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:
HHH is never changed.Yeah, so when you change HHH to abort later, you also change >>>>>>>>>> DDD.By itself I mean the exact same machine code bytes at the exact >>>>>>>>>>> same machine address.When DDD is emulated by HHH1 it need not emulate itself at >>>>>>>>>>>>> all.But "itself" doesn't matter to x86 instructions,
It is changed in the hypothetical unaborted simulation. HHH is >>>>>>>> reporting on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on >>>>>>>> the halting DDD,
and definitely not on HHH(DDD), itself.
input. HHH does correctly predict that DDD correctly simulated by >>>>>>> HHH cannot possibly reach its own simulated "return" instruction >>>>>>> final halt state.
But the behavior of the program continues past that (something you
don't seem to understand) and that behavior will also have its HHH
terminate the DDD it is simulating and return 0 to DDD and then Halt.
Your problem is you don't understand that the simulating HHH doesn't
define the behavior of DDD, it is the execution of DDD that defines
what a correct simulation of it is.
Remember, to have simulated that DDD, it must have include the code >>>>>> of the HHH that it was based on, which is the HHH that made theWe are not asking: Does DDD() halt.
prediction, and thus returns 0, so DDD will halt.
That is (as it turns out) an incorrect question.
No, that is EXACTLY the question.
I guess you are just admitting that you whole world is based on LYING
about what things are supposed to be.
Turing machines cannot directly report on the behavior of other
Turing machines they can at best indirectly report on the behavior of >>>>> Turing machines through the proxy of finite string machine
descriptions such as ⟨M⟩.
Right, and HHH was given the equivalenet of (M) by being given the
code of *ALL* of DDD
I guess you don't understand that fact, even though you CLAIM the
input is the proper representation of DDD.
Thus the behavior specified by the input finite string overrules and >>>>> supersedes the behavior of the direct execution.
No, it is DEFINED to be the behavior of the direct execution of the
program it represent.
No, your failure to follow the rules is what makes you just a liar.
Yet another ad hominem attack!
/Flibble
On 7/28/2025 8:56 PM, Richard Damon wrote:
On 7/28/25 7:58 PM, olcott wrote:
On 7/28/2025 6:49 PM, Richard Damon wrote:
On 7/28/25 7:20 PM, olcott wrote:
On 7/28/2025 5:57 PM, Richard Damon wrote:
On 7/28/25 9:54 AM, olcott wrote:
On 7/28/2025 8:21 AM, joes wrote:
Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:
On 7/28/2025 2:30 AM, joes wrote:
Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:
On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:
Yeah, so when you change HHH to abort later, you also change DDD. >>>>>>>>> HHH is never changed.By itself I mean the exact same machine code bytes at the >>>>>>>>>>> exact sameWhen DDD is emulated by HHH1 it need not emulate itself at >>>>>>>>>>>>> all.But "itself" doesn't matter to x86 instructions,
machine address.
It is changed in the hypothetical unaborted simulation. HHH is >>>>>>>> reporting
on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the
halting DDD,
and definitely not on HHH(DDD), itself.
All halt deciders are required to predict the behavior
of their input. HHH does correctly predict that DDD correctly
simulated by HHH cannot possibly reach its own simulated
"return" instruction final halt state.
How is it a "correct prediction" if it sees something different
than what that DDD does.
What DDD does is keep calling HHH(DDD) in recursive
simulation until HHH kills this whole process.
But the behavior of the program continues past that (something you
don't seem to understand) and that behavior will also have its HHH
terminate the DDD it is simulating and return 0 to DDD and then Halt.
Your problem is you don't understand that the simulating HHH doesn't
define the behavior of DDD, it is the execution of DDD that defines
what a correct simulation of it is.
Remember, to have simulated that DDD, it must have include the
code of the HHH that it was based on, which is the HHH that made
the prediction, and thus returns 0, so DDD will halt.
We are not asking: Does DDD() halt.
That is (as it turns out) an incorrect question.
No, that is EXACTLY the question.
I guess you are just admitting that you whole world is based on
LYING about what things are supposed to be.
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Right, and HHH was given the equivalenet of (M) by being given the
code of *ALL* of DDD
I guess you don't understand that fact, even though you CLAIM the
input is the proper representation of DDD.
Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.
No, it is DEFINED to be the behavior of the direct execution of the
program it represent.
*That has always been the fatal flaw of all of the proofs*
No, your failure to follow the rules is what makes you just a liar.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When the above code is in the same memory space as HHH
such that DDD calls HHH(DDD) and then HHH does emulate
itself emulating DDD then this does specify recursive
emulation.
Anyone or anything that disagrees would be disagreeing
with the definition of the x86 language.
On 7/29/2025 5:37 PM, Richard Damon wrote:
On 7/29/25 12:53 PM, olcott wrote:
On 7/28/2025 8:56 PM, Richard Damon wrote:
On 7/28/25 7:58 PM, olcott wrote:
On 7/28/2025 6:49 PM, Richard Damon wrote:
On 7/28/25 7:20 PM, olcott wrote:
On 7/28/2025 5:57 PM, Richard Damon wrote:
On 7/28/25 9:54 AM, olcott wrote:
On 7/28/2025 8:21 AM, joes wrote:
Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:
On 7/28/2025 2:30 AM, joes wrote:
Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:
On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:
HHH is never changed.Yeah, so when you change HHH to abort later, you also change >>>>>>>>>>>> DDD.By itself I mean the exact same machine code bytes at the >>>>>>>>>>>>> exact sameWhen DDD is emulated by HHH1 it need not emulate itself >>>>>>>>>>>>>>> at all.But "itself" doesn't matter to x86 instructions,
machine address.
It is changed in the hypothetical unaborted simulation. HHH is >>>>>>>>>> reporting
on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the >>>>>>>>>> halting DDD,
and definitely not on HHH(DDD), itself.
All halt deciders are required to predict the behavior
of their input. HHH does correctly predict that DDD correctly >>>>>>>>> simulated by HHH cannot possibly reach its own simulated
"return" instruction final halt state.
How is it a "correct prediction" if it sees something different >>>>>>>> than what that DDD does.
What DDD does is keep calling HHH(DDD) in recursive
simulation until HHH kills this whole process.
But the behavior of the program continues past that (something you >>>>>> don't seem to understand) and that behavior will also have its HHH >>>>>> terminate the DDD it is simulating and return 0 to DDD and then Halt. >>>>>>
Your problem is you don't understand that the simulating HHH
doesn't define the behavior of DDD, it is the execution of DDD
that defines what a correct simulation of it is.
Remember, to have simulated that DDD, it must have include the >>>>>>>> code of the HHH that it was based on, which is the HHH that made >>>>>>>> the prediction, and thus returns 0, so DDD will halt.
We are not asking: Does DDD() halt.
That is (as it turns out) an incorrect question.
No, that is EXACTLY the question.
I guess you are just admitting that you whole world is based on
LYING about what things are supposed to be.
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Right, and HHH was given the equivalenet of (M) by being given the >>>>>> code of *ALL* of DDD
I guess you don't understand that fact, even though you CLAIM the
input is the proper representation of DDD.
Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.
No, it is DEFINED to be the behavior of the direct execution of
the program it represent.
*That has always been the fatal flaw of all of the proofs*
No, your failure to follow the rules is what makes you just a liar.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When the above code is in the same memory space as HHH
such that DDD calls HHH(DDD) and then HHH does emulate
itself emulating DDD then this does specify recursive
emulation.
Anyone or anything that disagrees would be disagreeing
with the definition of the x86 language.
So, if HHH accesses that memory, it becomes part of the input.
It becomes part of the input in the sense that the
correct simulation of the input to HHH(DDD) is not
the same as the correct simulation of the input to
HHH1(DDD) because DDD only calls HHH(DDD) and does
not call HHH1(DDD).
DDD correctly simulated by HHH cannot possibly
halt thus HHH(DDD)==0 is correct.
DDD correctly simulated by HHH1 does halt thus
HHH(DDD)==1 is correct.
On 7/29/2025 8:51 PM, Richard Damon wrote:Indeed. But there are different reasons:
On 7/29/25 9:24 PM, olcott wrote:
On 7/29/2025 5:37 PM, Richard Damon wrote:
On 7/29/25 12:53 PM, olcott wrote:
On 7/28/2025 8:56 PM, Richard Damon wrote:
On 7/28/25 7:58 PM, olcott wrote:
On 7/28/2025 6:49 PM, Richard Damon wrote:
On 7/28/25 7:20 PM, olcott wrote:
On 7/28/2025 5:57 PM, Richard Damon wrote:
On 7/28/25 9:54 AM, olcott wrote:
On 7/28/2025 8:21 AM, joes wrote:
Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:
On 7/28/2025 2:30 AM, joes wrote:
Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:
HHH is never changed.Yeah, so when you change HHH to abort later, you also >>>>>>>>>>>>>> change DDD.machine address.When DDD is emulated by HHH1 it need not emulate itself >>>>>>>>>>>>>>>>> at all.But "itself" doesn't matter to x86 instructions, >>>>>>>>>>>>>>> By itself I mean the exact same machine code bytes at the >>>>>>>>>>>>>>> exact same
It is changed in the hypothetical unaborted simulation. HHH >>>>>>>>>>>> is reporting
on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the >>>>>>>>>>>> halting DDD,
and definitely not on HHH(DDD), itself.
All halt deciders are required to predict the behavior
of their input. HHH does correctly predict that DDD correctly >>>>>>>>>>> simulated by HHH cannot possibly reach its own simulated >>>>>>>>>>> "return" instruction final halt state.
How is it a "correct prediction" if it sees something
different than what that DDD does.
What DDD does is keep calling HHH(DDD) in recursive
simulation until HHH kills this whole process.
But the behavior of the program continues past that (something >>>>>>>> you don't seem to understand) and that behavior will also have >>>>>>>> its HHH terminate the DDD it is simulating and return 0 to DDD >>>>>>>> and then Halt.
Your problem is you don't understand that the simulating HHH
doesn't define the behavior of DDD, it is the execution of DDD >>>>>>>> that defines what a correct simulation of it is.
Remember, to have simulated that DDD, it must have include the >>>>>>>>>> code of the HHH that it was based on, which is the HHH that >>>>>>>>>> made the prediction, and thus returns 0, so DDD will halt. >>>>>>>>>>
We are not asking: Does DDD() halt.
That is (as it turns out) an incorrect question.
No, that is EXACTLY the question.
I guess you are just admitting that you whole world is based on >>>>>>>> LYING about what things are supposed to be.
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Right, and HHH was given the equivalenet of (M) by being given >>>>>>>> the code of *ALL* of DDD
I guess you don't understand that fact, even though you CLAIM
the input is the proper representation of DDD.
Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.
No, it is DEFINED to be the behavior of the direct execution of >>>>>>>> the program it represent.
*That has always been the fatal flaw of all of the proofs*
No, your failure to follow the rules is what makes you just a liar. >>>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When the above code is in the same memory space as HHH
such that DDD calls HHH(DDD) and then HHH does emulate
itself emulating DDD then this does specify recursive
emulation.
Anyone or anything that disagrees would be disagreeing
with the definition of the x86 language.
So, if HHH accesses that memory, it becomes part of the input.
It becomes part of the input in the sense that the
correct simulation of the input to HHH(DDD) is not
the same as the correct simulation of the input to
HHH1(DDD) because DDD only calls HHH(DDD) and does
not call HHH1(DDD).
DDD correctly simulated by HHH cannot possibly
halt thus HHH(DDD)==0 is correct.
DDD correctly simulated by HHH1 does halt thus
HHH(DDD)==1 is correct.
It either *IS* or it *ISN'T* there is no middle.
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
On 7/29/2025 8:51 PM, Richard Damon wrote:
On 7/29/25 9:24 PM, olcott wrote:
On 7/29/2025 5:37 PM, Richard Damon wrote:
On 7/29/25 12:53 PM, olcott wrote:
On 7/28/2025 8:56 PM, Richard Damon wrote:
On 7/28/25 7:58 PM, olcott wrote:
On 7/28/2025 6:49 PM, Richard Damon wrote:
On 7/28/25 7:20 PM, olcott wrote:
On 7/28/2025 5:57 PM, Richard Damon wrote:
On 7/28/25 9:54 AM, olcott wrote:
On 7/28/2025 8:21 AM, joes wrote:
Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:
On 7/28/2025 2:30 AM, joes wrote:
Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:
HHH is never changed.Yeah, so when you change HHH to abort later, you also >>>>>>>>>>>>>> change DDD.machine address.When DDD is emulated by HHH1 it need not emulate itself >>>>>>>>>>>>>>>>> at all.But "itself" doesn't matter to x86 instructions, >>>>>>>>>>>>>>> By itself I mean the exact same machine code bytes at the >>>>>>>>>>>>>>> exact same
It is changed in the hypothetical unaborted simulation. HHH >>>>>>>>>>>> is reporting
on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the >>>>>>>>>>>> halting DDD,
and definitely not on HHH(DDD), itself.
All halt deciders are required to predict the behavior
of their input. HHH does correctly predict that DDD correctly >>>>>>>>>>> simulated by HHH cannot possibly reach its own simulated >>>>>>>>>>> "return" instruction final halt state.
How is it a "correct prediction" if it sees something
different than what that DDD does.
What DDD does is keep calling HHH(DDD) in recursive
simulation until HHH kills this whole process.
But the behavior of the program continues past that (something >>>>>>>> you don't seem to understand) and that behavior will also have >>>>>>>> its HHH terminate the DDD it is simulating and return 0 to DDD >>>>>>>> and then Halt.
Your problem is you don't understand that the simulating HHH
doesn't define the behavior of DDD, it is the execution of DDD >>>>>>>> that defines what a correct simulation of it is.
Remember, to have simulated that DDD, it must have include the >>>>>>>>>> code of the HHH that it was based on, which is the HHH that >>>>>>>>>> made the prediction, and thus returns 0, so DDD will halt. >>>>>>>>>>
We are not asking: Does DDD() halt.
That is (as it turns out) an incorrect question.
No, that is EXACTLY the question.
I guess you are just admitting that you whole world is based on >>>>>>>> LYING about what things are supposed to be.
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Right, and HHH was given the equivalenet of (M) by being given >>>>>>>> the code of *ALL* of DDD
I guess you don't understand that fact, even though you CLAIM
the input is the proper representation of DDD.
Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.
No, it is DEFINED to be the behavior of the direct execution of >>>>>>>> the program it represent.
*That has always been the fatal flaw of all of the proofs*
No, your failure to follow the rules is what makes you just a liar. >>>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When the above code is in the same memory space as HHH
such that DDD calls HHH(DDD) and then HHH does emulate
itself emulating DDD then this does specify recursive
emulation.
Anyone or anything that disagrees would be disagreeing
with the definition of the x86 language.
So, if HHH accesses that memory, it becomes part of the input.
It becomes part of the input in the sense that the
correct simulation of the input to HHH(DDD) is not
the same as the correct simulation of the input to
HHH1(DDD) because DDD only calls HHH(DDD) and does
not call HHH1(DDD).
DDD correctly simulated by HHH cannot possibly
halt thus HHH(DDD)==0 is correct.
DDD correctly simulated by HHH1 does halt thus
HHH(DDD)==1 is correct.
It either *IS* or it *ISN'T* there is no middle.
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
On 7/30/2025 5:59 AM, Richard Damon wrote:
On 7/29/25 11:12 PM, olcott wrote:
On 7/29/2025 8:51 PM, Richard Damon wrote:
On 7/29/25 9:24 PM, olcott wrote:
On 7/29/2025 5:37 PM, Richard Damon wrote:
On 7/29/25 12:53 PM, olcott wrote:
On 7/28/2025 8:56 PM, Richard Damon wrote:
On 7/28/25 7:58 PM, olcott wrote:
On 7/28/2025 6:49 PM, Richard Damon wrote:
On 7/28/25 7:20 PM, olcott wrote:
On 7/28/2025 5:57 PM, Richard Damon wrote:
On 7/28/25 9:54 AM, olcott wrote:
On 7/28/2025 8:21 AM, joes wrote:
Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/28/2025 2:30 AM, joes wrote:
Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:
HHH is never changed.Yeah, so when you change HHH to abort later, you also >>>>>>>>>>>>>>>> change DDD.machine address.When DDD is emulated by HHH1 it need not emulate >>>>>>>>>>>>>>>>>>> itself at all.But "itself" doesn't matter to x86 instructions, >>>>>>>>>>>>>>>>> By itself I mean the exact same machine code bytes at >>>>>>>>>>>>>>>>> the exact same
It is changed in the hypothetical unaborted simulation. >>>>>>>>>>>>>> HHH is reporting
on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on >>>>>>>>>>>>>> the halting DDD,
and definitely not on HHH(DDD), itself.
All halt deciders are required to predict the behavior >>>>>>>>>>>>> of their input. HHH does correctly predict that DDD correctly >>>>>>>>>>>>> simulated by HHH cannot possibly reach its own simulated >>>>>>>>>>>>> "return" instruction final halt state.
How is it a "correct prediction" if it sees something
different than what that DDD does.
What DDD does is keep calling HHH(DDD) in recursive
simulation until HHH kills this whole process.
But the behavior of the program continues past that (something >>>>>>>>>> you don't seem to understand) and that behavior will also have >>>>>>>>>> its HHH terminate the DDD it is simulating and return 0 to DDD >>>>>>>>>> and then Halt.
Your problem is you don't understand that the simulating HHH >>>>>>>>>> doesn't define the behavior of DDD, it is the execution of DDD >>>>>>>>>> that defines what a correct simulation of it is.
Remember, to have simulated that DDD, it must have include >>>>>>>>>>>> the code of the HHH that it was based on, which is the HHH >>>>>>>>>>>> that made the prediction, and thus returns 0, so DDD will halt. >>>>>>>>>>>>
We are not asking: Does DDD() halt.
That is (as it turns out) an incorrect question.
No, that is EXACTLY the question.
I guess you are just admitting that you whole world is based >>>>>>>>>> on LYING about what things are supposed to be.
Right, and HHH was given the equivalenet of (M) by being given >>>>>>>>>> the code of *ALL* of DDD
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩. >>>>>>>>>>
I guess you don't understand that fact, even though you CLAIM >>>>>>>>>> the input is the proper representation of DDD.
Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.
No, it is DEFINED to be the behavior of the direct execution >>>>>>>>>> of the program it represent.
*That has always been the fatal flaw of all of the proofs*
No, your failure to follow the rules is what makes you just a liar. >>>>>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When the above code is in the same memory space as HHH
such that DDD calls HHH(DDD) and then HHH does emulate
itself emulating DDD then this does specify recursive
emulation.
Anyone or anything that disagrees would be disagreeing
with the definition of the x86 language.
So, if HHH accesses that memory, it becomes part of the input.
It becomes part of the input in the sense that the
correct simulation of the input to HHH(DDD) is not
the same as the correct simulation of the input to
HHH1(DDD) because DDD only calls HHH(DDD) and does
not call HHH1(DDD).
DDD correctly simulated by HHH cannot possibly
halt thus HHH(DDD)==0 is correct.
DDD correctly simulated by HHH1 does halt thus
HHH(DDD)==1 is correct.
It either *IS* or it *ISN'T* there is no middle.
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
Sure they do, when correctly simulated. What doens't happne is that
the PARTIAL simulation (and thus not correct) of HHH can't reach that
state.
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e
[000021a6] e843f4ffff call 000015ee
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== ============= [000021be][00103872][00000000] 55 push ebp [000021bf][00103872][00000000] 8bec mov ebp,esp [000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e [0000219e][0011390e][00113912] 55 push ebp [0000219f][0011390e][00113912] 8bec mov ebp,esp [000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
New slave_stack at:14e33e
[0000219e][0015e336][0015e33a] 55 push ebp [0000219f][0015e336][0015e33a] 8bec mov ebp,esp [000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH
That you never made any attempt at an actual rebuttal
seems to prove that you know you are wrong.
On 7/30/2025 6:58 PM, Richard Damon wrote:
On 7/30/25 11:02 AM, olcott wrote:
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e
[000021a6] e843f4ffff call 000015ee
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
cant' be the full input as not simuatable.
We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.
The Call HHH instruction below.
Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.
Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.
machine stack stack machine assembly >>> address address data code language
======== ======== ======== ========== =============
[000021be][00103872][00000000] 55 push ebp
[000021bf][00103872][00000000] 8bec mov ebp,esp
[000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD
[000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
New slave_stack at:103916
Not a correct simulation of the call HHH instruction.
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e >>> [0000219e][0011390e][00113912] 55 push ebp
[0000219f][0011390e][00113912] 8bec mov ebp,esp
[000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD
[000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
New slave_stack at:14e33e
[0000219e][0015e336][0015e33a] 55 push ebp
[0000219f][0015e336][0015e33a] 8bec mov ebp,esp
[000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD
[000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH
The above proves that HHH does emulate itself emulating
DDD correctly in that the emulated HHH does emulate DDD
correctly.
It also shows the repeating pattern that DDD correctly
emulated by DDD derives.
Without even having an implemented HHH we can still
see that DDD emulated by an emulated HHH would produce
this same same repeating pattern.
On 7/30/2025 9:16 PM, Richard Damon wrote:
On 7/30/25 8:42 PM, olcott wrote:
On 7/30/2025 6:58 PM, Richard Damon wrote:
On 7/30/25 11:02 AM, olcott wrote:
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e
[000021a6] e843f4ffff call 000015ee
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
cant' be the full input as not simuatable.
We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.
The Call HHH instruction below.
Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.
Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== =============
[000021be][00103872][00000000] 55 push ebp
[000021bf][00103872][00000000] 8bec mov ebp,esp
[000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD
[000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
New slave_stack at:103916
Not a correct simulation of the call HHH instruction.
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e >>>>> [0000219e][0011390e][00113912] 55 push ebp
[0000219f][0011390e][00113912] 8bec mov ebp,esp
[000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD
[000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
New slave_stack at:14e33e
[0000219e][0015e336][0015e33a] 55 push ebp
[0000219f][0015e336][0015e33a] 8bec mov ebp,esp
[000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD
[000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH
The above proves that HHH does emulate itself emulating
DDD correctly in that the emulated HHH does emulate DDD
correctly.
No, because you don't show the simulation of the code of HHH.
Mixing the above 8 instructions in with another 176
pages of instructions does not help understanding
things.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
We can know that HHH did correctly emulate itself
emulating DDD because this emulated HHH does derive
the correct first four instructions of DDD.
I guess you don't know what that means.
It also shows the repeating pattern that DDD correctly
emulated by DDD derives.
But that isn't what actually happens. the second copy doesn't actually
happen in the actual simulation of the input.
Counter-factual and this proves that it is counter-factual https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Without even having an implemented HHH we can still
see that DDD emulated by an emulated HHH would produce
this same same repeating pattern.
But if HHH isn't implements, you can't HAVE DDD as a valid input.
HHH is implemented yet too difficult for you to
understand so we verify that DDD does emulate
itself emulating DDD in that its emulated DDD
does emulate the first four instructions of DDD
as shown above.
All you are doing is proving you are just lying about what you are doing.
That you call me a liar could get you condemned to actual Hell.
Revelations 21:8
...all liars, their lot shall be in the lake that burns
with fire and sulphur, which is the second death.”
You are just proving that your whold argument is based on category
errors and lies.
That you keep changing the words that I say to make your
rebuttal easier is the strawman deception can could get you
condemned to actual Hell.
On 7/31/2025 6:34 PM, Richard Damon wrote:
On 7/31/25 12:26 PM, olcott wrote:
On 7/30/2025 9:16 PM, Richard Damon wrote:
On 7/30/25 8:42 PM, olcott wrote:
On 7/30/2025 6:58 PM, Richard Damon wrote:
On 7/30/25 11:02 AM, olcott wrote:
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e
[000021a6] e843f4ffff call 000015ee
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
cant' be the full input as not simuatable.
We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.
The Call HHH instruction below.
Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.
Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== =============
[000021be][00103872][00000000] 55 push ebp
[000021bf][00103872][00000000] 8bec mov ebp,esp
[000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD >>>>>>> [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH >>>>>>> New slave_stack at:103916
Not a correct simulation of the call HHH instruction.
Begin Local Halt Decider Simulation Execution Trace Stored
at:11391e
[0000219e][0011390e][00113912] 55 push ebp
[0000219f][0011390e][00113912] 8bec mov ebp,esp
[000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD >>>>>>> [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH >>>>>>> New slave_stack at:14e33e
[0000219e][0015e336][0015e33a] 55 push ebp
[0000219f][0015e336][0015e33a] 8bec mov ebp,esp
[000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD >>>>>>> [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH >>>>>>>
The above proves that HHH does emulate itself emulating
DDD correctly in that the emulated HHH does emulate DDD
correctly.
No, because you don't show the simulation of the code of HHH.
Mixing the above 8 instructions in with another 176
pages of instructions does not help understanding
things.
And FAILING to do it is just a lie.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Which, as has been pointed out, NOT the trace generated by HHH
simulating DDD, as it begins at main, which HHH NEVER simulates.
HHH simulates DDD then simulates a different instance
of itself simulating a different instance of DDD which
calls another different instance of HHH(DDD)...
On 7/30/2025 4:23 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 05:12 schreef olcott:*I challenge you to show a premature abort*
Indeed. But there are different reasons:
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Failing to do that proves that you are wrong.
Because we have been over this so many times I am
convinced that you already know that you are wrong
and are just trolling me.
There is no stack unwinding when HHH sees DDD calls the
same function with the same parameter twice in sequence.
At this point HHH kills the whole DDD process including
all recursive emulations.
based on the wrong assumption that a finite recursion specifies non-
halting.
Halting is defined as reaching the "return" statement
final halt state. It is not defined as stopping running
for any reason otherwise both of these would be determined
to be halting:
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Because they stop running as soon as their process it killed.
Then the simulating HHH does reach its own halt state when it reports
non-halting.
Yet neither the simulated DDD nor the simulated HHH
can possibly reach their own final halt state
The simulated HHH, that has a similar final halt state after it aborts,
The simulated HHH cannot possibly abort because the directly
executed HHH is always one whole recursive simulation ahead
thus reaching its abort criteria first.
After HHH sees that its simulated DDD is calling the same
function with the same parameter twice in sequence it kills
the whole simulated process. Even if it waited to see this
35 times in sequence the next inner one would have only seen
it 34 times, thus has not met its own abort criteria.
does not reach it own final halt state, because the simulating HHH
does not allow it to reach it by the premature abort done by the
simulating HHH.
You cannot prove that your use of the term "premature abort"
is anything besides a misconception. *See above challenge*
On 8/1/2025 4:00 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 16:52 schreef olcott:
On 7/30/2025 4:23 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 05:12 schreef olcott:*I challenge you to show a premature abort*
Indeed. But there are different reasons:
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,
This has been presented tro you many times, but you close your eyes
for it and pretend that it does not exist.>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
We have told you that the suggestion that these 18 bytes are the whole
input is misleading and incorrect. The input also includes all
function called by DDD, directly or indirectly, including the HHH that
aborts after a few cycles.
This input specifies a halting program as other correct simulators and
direct execution prove.
Neither the directly executed HHH() the directly executed DDD()
not DDD correctly simulated by HHH can possibly ever stop running
unless HHH(DDD) aborts the simulation of its input.
Turing machine halt deciders are only accountable for the
behavior that their inputs specifies thus the behavior
of non-input direct executions has always been outside
of their domain. The DDD correctly simulated by HHH cannot
possibly halt proves that HHH is correct to reject its input.
We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.
As usual a false claim.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
If there is an actual *premature abort* then there
is a specific point in the execution trace where
DDD correctly simulated by HHH stops running without
ever being aborted. Otherwise you are using the term
*premature abort* incorrectly.
On 8/1/2025 10:26 AM, joes wrote:
Am Fri, 01 Aug 2025 10:12:35 -0500 schrieb olcott:Everyone keeps dishonestly changing my words from
If there is an actual *premature abort* then there is a specific point
in the execution trace where DDD correctly simulated by HHH stops
running without ever being aborted.
Yes, after 12 instructions of DDD only or just before the third
recursive simulation.
(a) DDD correctly simulated by HHH (can't possibly halt)
(b) The directly executed DDD (that halts).
Turing machine deciders do not have directly executed
Turing machines in their domain. They only have finite
string machine description in their domain.
This means that when the behavior specified by the correct
simulation of the input disagrees with the behavior of the
direct execution of DDD() it is the behavior specified by
the input that overrules and supersedes.
On 8/1/2025 11:00 AM, Richard Damon wrote:
On 8/1/25 11:44 AM, olcott wrote:
On 8/1/2025 10:26 AM, joes wrote:
Am Fri, 01 Aug 2025 10:12:35 -0500 schrieb olcott:Everyone keeps dishonestly changing my words from
If there is an actual *premature abort* then there is a specific point >>>>> in the execution trace where DDD correctly simulated by HHH stops
running without ever being aborted.
Yes, after 12 instructions of DDD only or just before the third
recursive simulation.
(a) DDD correctly simulated by HHH (can't possibly halt)
No, it is that THIS HHH doesn't correctly simulate THIS DDD,
The outermost directly executed HHH does correctly
simulate N instructions of DDD and an instance of
itself in the same separate process context that it
created for DDD.
The correctly simulated instance of itself creates
yet another process context to simulate its own
instance of DDD.
On 8/1/2025 4:00 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 16:52 schreef olcott:
On 7/30/2025 4:23 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 05:12 schreef olcott:*I challenge you to show a premature abort*
Indeed. But there are different reasons:
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,
This has been presented tro you many times, but you close your eyes
for it and pretend that it does not exist.>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
We have told you that the suggestion that these 18 bytes are the whole
input is misleading and incorrect. The input also includes all
function called by DDD, directly or indirectly, including the HHH that
aborts after a few cycles.
This input specifies a halting program as other correct simulators and
direct execution prove.
Neither the directly executed HHH() the directly executed DDD()
not DDD correctly simulated by HHH can possibly ever stop running
unless HHH(DDD) aborts the simulation of its input.
Turing machine halt deciders are only accountable for the
behavior that their inputs specifies thus the behavior
of non-input direct executions has always been outside
of their domain. The DDD correctly simulated by HHH cannot
possibly halt proves that HHH is correct to reject its input.
Illogical, counter-factual and incorrect claim without evidence.
We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.
As usual a false claim.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
If there is an actual *premature abort* then there
is a specific point in the execution trace where
DDD correctly simulated by HHH stops running without
ever being aborted. Otherwise you are using the term
*premature abort* incorrectly.
On 8/2/2025 4:30 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 17:12 schreef olcott:
On 8/1/2025 4:00 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 16:52 schreef olcott:
On 7/30/2025 4:23 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 05:12 schreef olcott:*I challenge you to show a premature abort*
Indeed. But there are different reasons:
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,
This has been presented tro you many times, but you close your eyes
for it and pretend that it does not exist.>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
We have told you that the suggestion that these 18 bytes are the
whole input is misleading and incorrect. The input also includes all
function called by DDD, directly or indirectly, including the HHH
that aborts after a few cycles.
This input specifies a halting program as other correct simulators
and direct execution prove.
Neither the directly executed HHH() the directly executed DDD()
not DDD correctly simulated by HHH can possibly ever stop running
unless HHH(DDD) aborts the simulation of its input.
It is an irrelevant change of subject to imagine a hypothetical non-
input that has no abort code.
*Not according to the leading author of theory of computation textbooks*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Turing machine halt deciders are only accountable for the
behavior that their inputs specifies thus the behavior
of non-input direct executions has always been outside
of their domain. The DDD correctly simulated by HHH cannot
possibly halt proves that HHH is correct to reject its input.
No, it shows that HHH fails to reach the final halt state, where a
simulator (even when named HHH) that does not abort,has no problem to
reach the final halt state.
Where the Hell are you getting that from?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Prove your statement on this code.
We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.
As usual a false claim.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
If there is an actual *premature abort* then there
is a specific point in the execution trace where
DDD correctly simulated by HHH stops running without
ever being aborted. Otherwise you are using the term
*premature abort* incorrectly.
Illogical, counter-factual and incorrect claim without evidence.
What do you mean by premature abort?
The actual word "premature" means too early.
If the abort is too early then there is a point
in the execution trace that is not too early.
It is exactly the premature abort that causes that the final halt
state is not reached. Of, course the trace of that prematurely aborted
simulation does not show the last part of a correct simulation.
In other words when DDD calls its own simulator HHH in
recursive simulation this is exactly the same thing as
DDD never calling its own simulator HHH1 in recursive
simulation?
Sounds like 1984 newspeak to me.
https://en.wikipedia.org/wiki/Newspeak
But a comparison with a correct simulation done by e.g. HHH1, shows
the exact point where the final halt state is reached and where HHH
does the premature abort.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 716 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 59:02:09 |
| Calls: | 12,117 |
| Files: | 15,010 |
| Messages: | 6,518,720 |