On 3/12/2025 1:35 PM, Mike Terry wrote:
On 12/03/2025 09:24, Fred. Zwarts wrote:
Op 11.mrt.2025 om 21:37 schreef Mike Terry:
On 11/03/2025 18:23, Richard Heathfield wrote:
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in the >>>>>> halt7.c file (along with DDD) that PO provides links to from time
to time. However it's not very illuminating due to bugs/design
errors/ misunderstandings which only serve to obfuscate PO's
errors in thinking.
[I've now seen the code. Oh deary deary me.]
:)
Thank you for a spirited attempt to be cogent - or at least as
cogent as it is possible to be in the circumstances!
I think PO's first step must be to demonstrate that HHH() correctly
diagnoses some easy functions, such as these:
Not really necessary - PO is not trying or claiming to have a (full)
halt decider.
Originally his claim was that he had a program which worked for the
counter-example TM used in the common (e.g. Linz book) proof. Such
a program is impossible, as Linz and others prove, so having a
program H and its corresponding "counter-example" D, such that H
correctly decides D, would certainly show that the Linz proof is
wrong. His claim was always that he had "refuted the HP proof", or
sometimes that he had refuted the HP theorem itself although he's
been told dozens of times that there are many alternative proofs for
the result.
[As it turned out, PO's D(D) halted when run under his x86utm
environment, while H(D,D) which is required to return the halting
status of computation D(D) returned 0 (=non-halting). That is
exactly what the Linz proofs claim!]
Anyhow, his decider only /has/ to correctly decide the one input,
which is the D constructed from H by the usual method (basically D
calls H to see what H claims is the halting behaviour, then does the
opposite - I'm not sure if you're familiar with the proof, but
imagine you would be given your background).
His decider H works (subject to design errors/bugs and so on) by
single- stepping a simulation of its input computation, and
monitoring for conditions that PO believes indicate non-termination.
He tests a couple of conditions, and when one of those matches H
aborts and returns non- halting. Alternatively if the simulation
halts normally, H returns halting. The problem is (at least) one of
his non-halting-behaviour tests is invalid, matching during the
simulation of DDD, which is a halting computation.
It seems that he does not understand that the these conditions (that
indicate non-termination behaviour), form exactly the halting problem.
PO claims that simulation is the solution, but he only shifts the
problem of non-termination detection to the detection of these
'special conditions'.
When we realise that, we understand that a finite or infinite
simulation is not very relevant. The discussion should address these
conditions. But PO carefully avoids discussions about the detection
of these conditions, although they are the heart of the problem.
I completely agree.
We could create a (partial) simulating halt decider (PSHD) that works
by simulating the steps of its input computation, and looking for
patterns in the resulting trace indicating halting or non-halting
behaviour. If these patterns were /*sound*/, meaning that matching
guarantees the computation behaviour is indeed halting/non-halting as
the test claims, then the PSHD could abort the simulation and decide
halting behaviour correctly on that basis. [This much is obvious, and
is basically what Sipser means in his "agreement" statement that PO
often quotes, although PO has his own differing interpretation of what
that means.]
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
When DDD is emulated by HHH according to the semantics
of the above x86 machine language then DDD cannot possibly
reach past its own machine address 0000217a.
My posthumous reviewers will notice that my current
reviewers were disingenuous to the extent of dishonesty
on this specific point.
On 3/12/2025 5:47 PM, Richard Damon wrote:
On 3/12/25 2:53 PM, olcott wrote:
On 3/12/2025 1:35 PM, Mike Terry wrote:
On 12/03/2025 09:24, Fred. Zwarts wrote:
Op 11.mrt.2025 om 21:37 schreef Mike Terry:
On 11/03/2025 18:23, Richard Heathfield wrote:
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in >>>>>>>> the halt7.c file (along with DDD) that PO provides links to from >>>>>>>> time to time. However it's not very illuminating due to bugs/ >>>>>>>> design errors/ misunderstandings which only serve to obfuscate >>>>>>>> PO's errors in thinking.
[I've now seen the code. Oh deary deary me.]
:)
Thank you for a spirited attempt to be cogent - or at least as
cogent as it is possible to be in the circumstances!
I think PO's first step must be to demonstrate that HHH()
correctly diagnoses some easy functions, such as these:
Not really necessary - PO is not trying or claiming to have a
(full) halt decider.
Originally his claim was that he had a program which worked for
the counter-example TM used in the common (e.g. Linz book) proof.
Such a program is impossible, as Linz and others prove, so having
a program H and its corresponding "counter-example" D, such that H >>>>>> correctly decides D, would certainly show that the Linz proof is
wrong. His claim was always that he had "refuted the HP proof",
or sometimes that he had refuted the HP theorem itself although
he's been told dozens of times that there are many alternative
proofs for the result.
[As it turned out, PO's D(D) halted when run under his x86utm
environment, while H(D,D) which is required to return the halting
status of computation D(D) returned 0 (=non-halting). That is
exactly what the Linz proofs claim!]
Anyhow, his decider only /has/ to correctly decide the one input,
which is the D constructed from H by the usual method (basically D >>>>>> calls H to see what H claims is the halting behaviour, then does
the opposite - I'm not sure if you're familiar with the proof, but >>>>>> imagine you would be given your background).
His decider H works (subject to design errors/bugs and so on) by
single- stepping a simulation of its input computation, and
monitoring for conditions that PO believes indicate non-
termination. He tests a couple of conditions, and when one of
those matches H aborts and returns non- halting. Alternatively if
the simulation halts normally, H returns halting. The problem is >>>>>> (at least) one of his non-halting-behaviour tests is invalid,
matching during the simulation of DDD, which is a halting
computation.
It seems that he does not understand that the these conditions
(that indicate non-termination behaviour), form exactly the halting
problem.
PO claims that simulation is the solution, but he only shifts the
problem of non-termination detection to the detection of these
'special conditions'.
When we realise that, we understand that a finite or infinite
simulation is not very relevant. The discussion should address
these conditions. But PO carefully avoids discussions about the
detection of these conditions, although they are the heart of the
problem.
I completely agree.
We could create a (partial) simulating halt decider (PSHD) that
works by simulating the steps of its input computation, and looking
for patterns in the resulting trace indicating halting or non-
halting behaviour. If these patterns were /*sound*/, meaning that
matching guarantees the computation behaviour is indeed halting/non-
halting as the test claims, then the PSHD could abort the simulation
and decide halting behaviour correctly on that basis. [This much is
obvious, and is basically what Sipser means in his "agreement"
statement that PO often quotes, although PO has his own differing
interpretation of what that means.]
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
When DDD is emulated by HHH according to the semantics
of the above x86 machine language then DDD cannot possibly
reach past its own machine address 0000217a.
My posthumous reviewers will notice that my current
reviewers were disingenuous to the extent of dishonesty
on this specific point.
But the problem is the HHH that does that never answers,
So you forgot the details of this context?
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When HHH correctly emulates N steps of the
above functions none of them can possibly reach
their own "return" instruction and terminate normally.
On 3/12/2025 5:47 PM, Richard Damon wrote:
On 3/12/25 2:53 PM, olcott wrote:
On 3/12/2025 1:35 PM, Mike Terry wrote:
On 12/03/2025 09:24, Fred. Zwarts wrote:
Op 11.mrt.2025 om 21:37 schreef Mike Terry:
On 11/03/2025 18:23, Richard Heathfield wrote:
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in the >>>>>>>> halt7.c file (along with DDD) that PO provides links to from time to >>>>>>>> time. However it's not very illuminating due to bugs/ design errors/ >>>>>>>> misunderstandings which only serve to obfuscate PO's errors in thinking.
[I've now seen the code. Oh deary deary me.]
:)
Thank you for a spirited attempt to be cogent - or at least as cogent >>>>>>> as it is possible to be in the circumstances!
I think PO's first step must be to demonstrate that HHH() correctly >>>>>>> diagnoses some easy functions, such as these:
Not really necessary - PO is not trying or claiming to have a (full) >>>>>> halt decider.
Originally his claim was that he had a program which worked for the >>>>>> counter-example TM used in the common (e.g. Linz book) proof. Such a >>>>>> program is impossible, as Linz and others prove, so having a program H >>>>>> and its corresponding "counter-example" D, such that H correctly
decides D, would certainly show that the Linz proof is wrong. His >>>>>> claim was always that he had "refuted the HP proof", or sometimes that >>>>>> he had refuted the HP theorem itself although he's been told dozens of >>>>>> times that there are many alternative proofs for the result.
[As it turned out, PO's D(D) halted when run under his x86utm
environment, while H(D,D) which is required to return the halting
status of computation D(D) returned 0 (=non-halting). That is exactly >>>>>> what the Linz proofs claim!]
Anyhow, his decider only /has/ to correctly decide the one input, which >>>>>> is the D constructed from H by the usual method (basically D calls H to >>>>>> see what H claims is the halting behaviour, then does the opposite - >>>>>> I'm not sure if you're familiar with the proof, but imagine you would >>>>>> be given your background).
His decider H works (subject to design errors/bugs and so on) by
single- stepping a simulation of its input computation, and monitoring >>>>>> for conditions that PO believes indicate non- termination. He tests a >>>>>> couple of conditions, and when one of those matches H aborts and
returns non- halting. Alternatively if the simulation halts normally, H >>>>>> returns halting. The problem is (at least) one of his
non-halting-behaviour tests is invalid, matching during the simulation >>>>>> of DDD, which is a halting computation.
It seems that he does not understand that the these conditions (that >>>>> indicate non-termination behaviour), form exactly the halting problem. >>>>> PO claims that simulation is the solution, but he only shifts the
problem of non-termination detection to the detection of these 'special >>>>> conditions'.
When we realise that, we understand that a finite or infinite
simulation is not very relevant. The discussion should address these >>>>> conditions. But PO carefully avoids discussions about the detection of >>>>> these conditions, although they are the heart of the problem.
I completely agree.
We could create a (partial) simulating halt decider (PSHD) that works
by simulating the steps of its input computation, and looking for
patterns in the resulting trace indicating halting or non-halting
behaviour. If these patterns were /*sound*/, meaning that matching
guarantees the computation behaviour is indeed halting/non-halting as
the test claims, then the PSHD could abort the simulation and decide
halting behaviour correctly on that basis. [This much is obvious, and >>>> is basically what Sipser means in his "agreement" statement that PO
often quotes, although PO has his own differing interpretation of what >>>> that means.]
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
When DDD is emulated by HHH according to the semantics
of the above x86 machine language then DDD cannot possibly
reach past its own machine address 0000217a.
My posthumous reviewers will notice that my current
reviewers were disingenuous to the extent of dishonesty
on this specific point.
But the problem is the HHH that does that never answers,
So you forgot the details of this context?
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When HHH correctly emulates N steps of the
above functions none of them can possibly reach
their own "return" instruction and terminate normally.
On 3/12/2025 1:35 PM, Mike Terry wrote:
On 12/03/2025 09:24, Fred. Zwarts wrote:
Op 11.mrt.2025 om 21:37 schreef Mike Terry:
On 11/03/2025 18:23, Richard Heathfield wrote:
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in the >>>>>> halt7.c file (along with DDD) that PO provides links to from time
to time. However it's not very illuminating due to bugs/design
errors/ misunderstandings which only serve to obfuscate PO's
errors in thinking.
[I've now seen the code. Oh deary deary me.]
:)
Thank you for a spirited attempt to be cogent - or at least as
cogent as it is possible to be in the circumstances!
I think PO's first step must be to demonstrate that HHH() correctly
diagnoses some easy functions, such as these:
Not really necessary - PO is not trying or claiming to have a (full)
halt decider.
Originally his claim was that he had a program which worked for the
counter-example TM used in the common (e.g. Linz book) proof. Such
a program is impossible, as Linz and others prove, so having a
program H and its corresponding "counter-example" D, such that H
correctly decides D, would certainly show that the Linz proof is
wrong. His claim was always that he had "refuted the HP proof", or
sometimes that he had refuted the HP theorem itself although he's
been told dozens of times that there are many alternative proofs for
the result.
[As it turned out, PO's D(D) halted when run under his x86utm
environment, while H(D,D) which is required to return the halting
status of computation D(D) returned 0 (=non-halting). That is
exactly what the Linz proofs claim!]
Anyhow, his decider only /has/ to correctly decide the one input,
which is the D constructed from H by the usual method (basically D
calls H to see what H claims is the halting behaviour, then does the
opposite - I'm not sure if you're familiar with the proof, but
imagine you would be given your background).
His decider H works (subject to design errors/bugs and so on) by
single- stepping a simulation of its input computation, and
monitoring for conditions that PO believes indicate non-termination.
He tests a couple of conditions, and when one of those matches H
aborts and returns non- halting. Alternatively if the simulation
halts normally, H returns halting. The problem is (at least) one of
his non-halting-behaviour tests is invalid, matching during the
simulation of DDD, which is a halting computation.
It seems that he does not understand that the these conditions (that
indicate non-termination behaviour), form exactly the halting problem.
PO claims that simulation is the solution, but he only shifts the
problem of non-termination detection to the detection of these
'special conditions'.
When we realise that, we understand that a finite or infinite
simulation is not very relevant. The discussion should address these
conditions. But PO carefully avoids discussions about the detection
of these conditions, although they are the heart of the problem.
I completely agree.
We could create a (partial) simulating halt decider (PSHD) that works
by simulating the steps of its input computation, and looking for
patterns in the resulting trace indicating halting or non-halting
behaviour. If these patterns were /*sound*/, meaning that matching
guarantees the computation behaviour is indeed halting/non-halting as
the test claims, then the PSHD could abort the simulation and decide
halting behaviour correctly on that basis. [This much is obvious, and
is basically what Sipser means in his "agreement" statement that PO
often quotes, although PO has his own differing interpretation of what
that means.]
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
When DDD is emulated by HHH according to the semantics
of the above x86 machine language then DDD cannot possibly
reach past its own machine address 0000217a.
My posthumous reviewers will notice that my current
reviewers were disingenuous to the extent of dishonesty
on this specific point.
On 3/12/2025 5:47 PM, Richard Damon wrote:Repeating that HHH fails for any N to reach the end of the simulation an
On 3/12/25 2:53 PM, olcott wrote:
On 3/12/2025 1:35 PM, Mike Terry wrote:
On 12/03/2025 09:24, Fred. Zwarts wrote:
Op 11.mrt.2025 om 21:37 schreef Mike Terry:
On 11/03/2025 18:23, Richard Heathfield wrote:
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in >>>>>>>> the halt7.c file (along with DDD) that PO provides links to from >>>>>>>> time to time. However it's not very illuminating due to bugs/ >>>>>>>> design errors/ misunderstandings which only serve to obfuscate >>>>>>>> PO's errors in thinking.
[I've now seen the code. Oh deary deary me.]
:)
Thank you for a spirited attempt to be cogent - or at least as
cogent as it is possible to be in the circumstances!
I think PO's first step must be to demonstrate that HHH()
correctly diagnoses some easy functions, such as these:
Not really necessary - PO is not trying or claiming to have a
(full) halt decider.
Originally his claim was that he had a program which worked for
the counter-example TM used in the common (e.g. Linz book) proof.
Such a program is impossible, as Linz and others prove, so having
a program H and its corresponding "counter-example" D, such that H >>>>>> correctly decides D, would certainly show that the Linz proof is
wrong. His claim was always that he had "refuted the HP proof",
or sometimes that he had refuted the HP theorem itself although
he's been told dozens of times that there are many alternative
proofs for the result.
[As it turned out, PO's D(D) halted when run under his x86utm
environment, while H(D,D) which is required to return the halting
status of computation D(D) returned 0 (=non-halting). That is
exactly what the Linz proofs claim!]
Anyhow, his decider only /has/ to correctly decide the one input,
which is the D constructed from H by the usual method (basically D >>>>>> calls H to see what H claims is the halting behaviour, then does
the opposite - I'm not sure if you're familiar with the proof, but >>>>>> imagine you would be given your background).
His decider H works (subject to design errors/bugs and so on) by
single- stepping a simulation of its input computation, and
monitoring for conditions that PO believes indicate non-
termination. He tests a couple of conditions, and when one of
those matches H aborts and returns non- halting. Alternatively if
the simulation halts normally, H returns halting. The problem is >>>>>> (at least) one of his non-halting-behaviour tests is invalid,
matching during the simulation of DDD, which is a halting
computation.
It seems that he does not understand that the these conditions
(that indicate non-termination behaviour), form exactly the halting
problem.
PO claims that simulation is the solution, but he only shifts the
problem of non-termination detection to the detection of these
'special conditions'.
When we realise that, we understand that a finite or infinite
simulation is not very relevant. The discussion should address
these conditions. But PO carefully avoids discussions about the
detection of these conditions, although they are the heart of the
problem.
I completely agree.
We could create a (partial) simulating halt decider (PSHD) that
works by simulating the steps of its input computation, and looking
for patterns in the resulting trace indicating halting or non-
halting behaviour. If these patterns were /*sound*/, meaning that
matching guarantees the computation behaviour is indeed halting/non-
halting as the test claims, then the PSHD could abort the simulation
and decide halting behaviour correctly on that basis. [This much is
obvious, and is basically what Sipser means in his "agreement"
statement that PO often quotes, although PO has his own differing
interpretation of what that means.]
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
When DDD is emulated by HHH according to the semantics
of the above x86 machine language then DDD cannot possibly
reach past its own machine address 0000217a.
My posthumous reviewers will notice that my current
reviewers were disingenuous to the extent of dishonesty
on this specific point.
But the problem is the HHH that does that never answers,
So you forgot the details of this context?
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When HHH correctly emulates N steps of the
above functions none of them can possibly reach
their own "return" instruction and terminate normally.
On 3/12/2025 10:56 PM, Richard Damon wrote:
On 3/12/25 8:36 PM, olcott wrote:
On 3/12/2025 5:47 PM, Richard Damon wrote:
On 3/12/25 2:53 PM, olcott wrote:
On 3/12/2025 1:35 PM, Mike Terry wrote:
On 12/03/2025 09:24, Fred. Zwarts wrote:
Op 11.mrt.2025 om 21:37 schreef Mike Terry:
On 11/03/2025 18:23, Richard Heathfield wrote:
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in >>>>>>>>>> the halt7.c file (along with DDD) that PO provides links to >>>>>>>>>> from time to time. However it's not very illuminating due to >>>>>>>>>> bugs/ design errors/ misunderstandings which only serve to >>>>>>>>>> obfuscate PO's errors in thinking.
[I've now seen the code. Oh deary deary me.]
:)
Thank you for a spirited attempt to be cogent - or at least as >>>>>>>>> cogent as it is possible to be in the circumstances!
I think PO's first step must be to demonstrate that HHH()
correctly diagnoses some easy functions, such as these:
Not really necessary - PO is not trying or claiming to have a
(full) halt decider.
Originally his claim was that he had a program which worked for >>>>>>>> the counter-example TM used in the common (e.g. Linz book)
proof. Such a program is impossible, as Linz and others prove, >>>>>>>> so having a program H and its corresponding "counter-example" D, >>>>>>>> such that H correctly decides D, would certainly show that the >>>>>>>> Linz proof is wrong. His claim was always that he had "refuted >>>>>>>> the HP proof", or sometimes that he had refuted the HP theorem >>>>>>>> itself although he's been told dozens of times that there are
many alternative proofs for the result.
[As it turned out, PO's D(D) halted when run under his x86utm
environment, while H(D,D) which is required to return the
halting status of computation D(D) returned 0 (=non-halting).
That is exactly what the Linz proofs claim!]
Anyhow, his decider only /has/ to correctly decide the one
input, which is the D constructed from H by the usual method
(basically D calls H to see what H claims is the halting
behaviour, then does the opposite - I'm not sure if you're
familiar with the proof, but imagine you would be given your
background).
His decider H works (subject to design errors/bugs and so on) by >>>>>>>> single- stepping a simulation of its input computation, and
monitoring for conditions that PO believes indicate non-
termination. He tests a couple of conditions, and when one of
those matches H aborts and returns non- halting. Alternatively >>>>>>>> if the simulation halts normally, H returns halting. The
problem is (at least) one of his non-halting-behaviour tests is >>>>>>>> invalid, matching during the simulation of DDD, which is a
halting computation.
It seems that he does not understand that the these conditions
(that indicate non-termination behaviour), form exactly the
halting problem.
PO claims that simulation is the solution, but he only shifts the >>>>>>> problem of non-termination detection to the detection of these
'special conditions'.
When we realise that, we understand that a finite or infinite
simulation is not very relevant. The discussion should address
these conditions. But PO carefully avoids discussions about the
detection of these conditions, although they are the heart of the >>>>>>> problem.
I completely agree.
We could create a (partial) simulating halt decider (PSHD) that
works by simulating the steps of its input computation, and
looking for patterns in the resulting trace indicating halting or
non- halting behaviour. If these patterns were /*sound*/, meaning >>>>>> that matching guarantees the computation behaviour is indeed
halting/ non- halting as the test claims, then the PSHD could
abort the simulation and decide halting behaviour correctly on
that basis. [This much is obvious, and is basically what Sipser
means in his "agreement" statement that PO often quotes, although
PO has his own differing interpretation of what that means.]
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
When DDD is emulated by HHH according to the semantics
of the above x86 machine language then DDD cannot possibly
reach past its own machine address 0000217a.
My posthumous reviewers will notice that my current
reviewers were disingenuous to the extent of dishonesty
on this specific point.
But the problem is the HHH that does that never answers,
So you forgot the details of this context?
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When HHH correctly emulates N steps of the
above functions none of them can possibly reach
their own "return" instruction and terminate normally.
No, you make a rash judgement, because you are lying to yourself on
the definitions.
Infinite_Loop and Infinite_Recursion, when directly run, will, in
fact, run forever, so as a decider, HHH can abort its simulation of
them when it proves that and return 0, as they will not ever reach the
final state.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
IT S ONLY THAT YOU INSIST ON THE DECEPTION OF THE
STRAWMAN ALWAYS CHANGING THE SUBJECT AWAY FROM THE
BEHAVIOR OF DDD CORRECTLY EMULATED BY HHH.
On 3/13/2025 4:22 AM, Mikko wrote:Depends on HHH, which we know 1) halts and 2) can't be simulated by
On 2025-03-13 00:36:04 +0000, olcott said:
When HHH correctly emulates N steps of the above functions none of
them can possibly reach their own "return" instruction and terminate
normally.
Nevertheless, assuming HHH is a decider, Infinite_Loop and
Infinite_Recursion specify a non-terminating behaviour, DDD specifies a
terminating behaviour
_DDD()
[00002172] 55 push ebp ; housekeeping [00002173] 8bec
mov ebp,esp ; housekeeping [00002175] 6872210000 push 00002172 ; push
DDD [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) [0000217f]
83c404 add esp,+04 [00002182] 5d pop ebp [00002183] c3
ret Size in bytes:(0018) [00002183]
What is the sequence of machine language instructions of DDD emulated by
HHH such that DDD reaches its machine address 00002183?
Any failure to answer with the sequence of machine addresses will be construed as YOU KNOW THAT YOU ARE LYING OR DON'T UNDERSTAND THE QUESTON--
On 3/13/2025 4:22 AM, Mikko wrote:
On 2025-03-13 00:36:04 +0000, olcott said:
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When HHH correctly emulates N steps of the
above functions none of them can possibly reach
their own "return" instruction and terminate normally.
Nevertheless, assuming HHH is a decider, Infinite_Loop and
Infinite_Recursion
specify a non-terminating behaviour, DDD specifies a terminating
behaviour
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
What is the sequence of machine language
instructions of DDD emulated by HHH such that DDD
reaches its machine address 00002183?
Any failure to answer with the sequence of machine
addresses will be construed as
YOU KNOW THAT YOU ARE LYING OR DON'T UNDERSTAND THE QUESTON
On 3/13/2025 4:15 PM, joes wrote:
Am Thu, 13 Mar 2025 15:56:22 -0500 schrieb olcott:
On 3/13/2025 4:22 AM, Mikko wrote:
On 2025-03-13 00:36:04 +0000, olcott said:
When HHH correctly emulates N steps of the above functions none of
them can possibly reach their own "return" instruction and terminate >>>>> normally.
Nevertheless, assuming HHH is a decider, Infinite_Loop and
Infinite_Recursion specify a non-terminating behaviour, DDD specifies a >>>> terminating behaviour
_DDD()
[00002172] 55 push ebp ; housekeeping [00002173] 8bec
mov ebp,esp ; housekeeping [00002175] 6872210000 push 00002172 ; push >>> DDD [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) [0000217f]
83c404 add esp,+04 [00002182] 5d pop ebp [00002183] c3
ret Size in bytes:(0018) [00002183]
What is the sequence of machine language instructions of DDD emulated by >>> HHH such that DDD reaches its machine address 00002183?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Depends on HHH, which we know 1) halts and 2) can't be simulated by
itself.
Of the infinite set every possible HHH such that N
steps of DDD are correctly emulated by each HHH it
is a verified fact to anyone with sufficient technical
competence that no DDD ever reaches its own "ret"
instruction and terminates normally.
The same thing applies to this c code:
void DDD()
{
HHH(DDD);
return;
}
Anyone knowing this and failing to affirm it will
be construed as not wanting any honest dialogue.
If people did not deny these facts for sadistic trollish
pleasure these same ideas can be applied to creating a
True(X) predicate to give LLM AI systems a foundation
anchored in facts thus eliminating AI Hallucinations.
Such a system could eventually take on every user on
every social media platform and make the Nazi lies
look utterly ridiculous to even the liars themselves
Before it can possibly do this it much know exactly
what True(X) is And how it works. True(X) begins
with a set of stipulated truths (basic facts that
cannot be derived from other basic facts).
Haskell Curry calls these the elementary theorems: https://www.liarparadox.org/Haskell_Curry_45.pdf
On 3/13/2025 4:22 AM, Mikko wrote:I built an aeroplane. After flying three times around the globe, I found
On 2025-03-13 00:36:04 +0000, olcott said:
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When HHH correctly emulates N steps of the
above functions none of them can possibly reach
their own "return" instruction and terminate normally.
Nevertheless, assuming HHH is a decider, Infinite_Loop and
Infinite_Recursion
specify a non-terminating behaviour, DDD specifies a terminating
behaviour
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
What is the sequence of machine language
instructions of DDD emulated by HHH such that DDD
reaches its machine address 00002183?
On 3/13/2025 4:22 AM, Mikko wrote:
On 2025-03-13 00:36:04 +0000, olcott said:
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When HHH correctly emulates N steps of the
above functions none of them can possibly reach
their own "return" instruction and terminate normally.
Nevertheless, assuming HHH is a decider, Infinite_Loop and Infinite_Recursion
specify a non-terminating behaviour, DDD specifies a terminating behaviour
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
What is the sequence of machine language
instructions of DDD emulated by HHH such that DDD
reaches its machine address 00002183?
On 3/14/2025 4:03 AM, Mikko wrote:
On 2025-03-13 20:56:22 +0000, olcott said:
On 3/13/2025 4:22 AM, Mikko wrote:
On 2025-03-13 00:36:04 +0000, olcott said:
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When HHH correctly emulates N steps of the
above functions none of them can possibly reach
their own "return" instruction and terminate normally.
Nevertheless, assuming HHH is a decider, Infinite_Loop and
Infinite_Recursion
specify a non-terminating behaviour, DDD specifies a terminating
behaviour
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
What is the sequence of machine language
instructions of DDD emulated by HHH such that DDD
reaches its machine address 00002183?
Irrelevant off-topic distraction.
Proving that you don't have a clue that Rice's Theorem
is anchored in the behavior that its finite string input
specifies. The depth of your knowledge is memorizing
quotes from textbooks.
On 3/14/2025 4:03 AM, Mikko wrote:
On 2025-03-13 20:56:22 +0000, olcott said:
On 3/13/2025 4:22 AM, Mikko wrote:
On 2025-03-13 00:36:04 +0000, olcott said:_DDD()
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When HHH correctly emulates N steps of the
above functions none of them can possibly reach
their own "return" instruction and terminate normally.
Nevertheless, assuming HHH is a decider, Infinite_Loop and Infinite_Recursion
specify a non-terminating behaviour, DDD specifies a terminating behaviour >>>
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
What is the sequence of machine language
instructions of DDD emulated by HHH such that DDD
reaches its machine address 00002183?
Irrelevant off-topic distraction.
Proving that you don't have a clue that Rice's Theorem
is anchored in the behavior that its finite string input
specifies. The depth of your knowledge is memorizing
quotes from textbooks.
On 3/13/2025 4:22 AM, Mikko wrote:
On 2025-03-13 00:36:04 +0000, olcott said:
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When HHH correctly emulates N steps of the
above functions none of them can possibly reach
their own "return" instruction and terminate normally.
Nevertheless, assuming HHH is a decider, Infinite_Loop and Infinite_Recursion
specify a non-terminating behaviour, DDD specifies a terminating behaviour
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
What is the sequence of machine language
instructions of DDD emulated by HHH such that DDD
reaches its machine address 00002183?
Any failure to answer with the sequence of machine
addresses will be construed as
YOU KNOW THAT YOU ARE LYING OR DON'T UNDERSTAND THE QUESTON
On 3/15/2025 5:24 AM, Mikko wrote:
On 2025-03-13 20:56:22 +0000, olcott said:
On 3/13/2025 4:22 AM, Mikko wrote:
On 2025-03-13 00:36:04 +0000, olcott said:_DDD()
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When HHH correctly emulates N steps of the
above functions none of them can possibly reach
their own "return" instruction and terminate normally.
Nevertheless, assuming HHH is a decider, Infinite_Loop and Infinite_Recursion
specify a non-terminating behaviour, DDD specifies a terminating behaviour >>>
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
What is the sequence of machine language
instructions of DDD emulated by HHH such that DDD
reaches its machine address 00002183?
Any failure to answer with the sequence of machine
addresses will be construed as
YOU KNOW THAT YOU ARE LYING OR DON'T UNDERSTAND THE QUESTON
That a question is not answered is not a lie.
It is when the claim that I am incorrect is repeated
many many times with many requests for supporting
reasoning showing how I am wrong are totally ignored.
On 3/15/2025 5:24 AM, Mikko wrote:
On 2025-03-13 20:56:22 +0000, olcott said:
On 3/13/2025 4:22 AM, Mikko wrote:
On 2025-03-13 00:36:04 +0000, olcott said:
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When HHH correctly emulates N steps of the
above functions none of them can possibly reach
their own "return" instruction and terminate normally.
Nevertheless, assuming HHH is a decider, Infinite_Loop and
Infinite_Recursion
specify a non-terminating behaviour, DDD specifies a terminating
behaviour
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
What is the sequence of machine language
instructions of DDD emulated by HHH such that DDD
reaches its machine address 00002183?
Any failure to answer with the sequence of machine
addresses will be construed as
YOU KNOW THAT YOU ARE LYING OR DON'T UNDERSTAND THE QUESTON
That a question is not answered is not a lie.
It is when the claim that I am incorrect is repeated
many many times with many requests for supporting
reasoning showing how I am wrong are totally ignored.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 148:57:16 |
| Calls: | 12,091 |
| Calls today: | 4 |
| Files: | 15,000 |
| Messages: | 6,517,565 |