So much bad faith and dishonesty shown in this forum that myself and Peter Olcott have to fight against.
On 5/23/2025 8:20 PM, Mr Flibble wrote:
So much bad faith and dishonesty shown in this forum that myself and
Peter
Olcott have to fight against.
/Flibble
Yes that is true.
The primary dishonest tactic changes the words
that are stated into words that can be refuted
and then refutes these changed words.
On 5/24/2025 8:12 AM, Richard Damon wrote:
On 5/23/25 10:08 PM, olcott wrote:
On 5/23/2025 8:20 PM, Mr Flibble wrote:
So much bad faith and dishonesty shown in this forum that myself and
Peter
Olcott have to fight against.
/Flibble
Yes that is true.
The primary dishonest tactic changes the words
that are stated into words that can be refuted
and then refutes these changed words.
Which is EXACTLY YOUR problem.
SInce you H and D just fail to meet the requirement of the theory you
talk about, your whole argument is just a category error.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I did not include any theory in what I said.
It is merely a verified fact that DDD simulated
by HHH according to the rules of the x86 language
cannot possibly reach its "ret" instruction final
halt state.
Any mere theory that disagrees with verified facts
is f-cked in the head.
On 5/24/2025 2:33 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself and Peter >>> Olcott have to fight against.
Just remember that in such fights the goal is not to win but to avoid
losing.
Are you admitting that you are a liar
that has no interest in an honest dialogue?
So much bad faith and dishonesty shown in this forum that myself and Peter Olcott have to fight against.
On 5/25/2025 1:21 AM, Mikko wrote:Why repeating this bug in HHH?
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself and
Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty.
If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself and >>>>> Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty. >>>> If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH accordingWhy repeating this bug in HHH?
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug ....
.... makes your statement the kind of reckless disregard for the truth
that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR
We know that HHH is unable to reach the reachable 'ret' instruction.
We also know that it not possible to repair HHH. It is impossible for
HHH to simulate itself.
It is also a verified fact that HHH does simulate itself simulating DDD
thus again you are proven to be a liar.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself and
Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty.
If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
If you are only here to play the troll you will not
acknowledge the truth of the above tautology.
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:Why repeating this bug in HHH?
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself
and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty. >>>> If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug makes your statement
the kind of reckless disregard for the truth
that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR
We know that HHH is unable to reach the reachable 'ret' instruction.
We also know that it not possible to repair HHH. It is impossible for
HHH to simulate itself.
It is also a verified fact that HHH does simulate
itself simulating DDD thus again you are proven
to be a liar.
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:Why repeating this bug in HHH?
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself
and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty. >>>> If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug makes your statement
the kind of reckless disregard for the truth
that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:Why repeating this bug in HHH?
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself >>>>>>> and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against
dishonesty.
If you could remove all dishonesty the protests woud stop, too, and >>>>>> nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug makes your statement
the kind of reckless disregard for the truth
that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR
Ad hominem attacks showing lack of counter arguments.
When you are objectively a liar then calling
you a liar is merely stating the facts.
On 5/25/2025 11:59 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself and >>>>>>> Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against
dishonesty.
If you could remove all dishonesty the protests woud stop, too, and >>>>>> nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH accordingWhy repeating this bug in HHH?
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug ....
That is untrue. The bug is clear to anybody who understands C code.
OK then to prove that you are not a damned liar
(you won't do this because you know that you are a liar)
show how DDD simulated by HHH according to the rules
of the x86 language reaches its own "ret" instruction
final halt state. FIND THE BUG ASSHOLE !!!
.... makes your statement the kind of reckless disregard for the truth
that loses defamation cases.
Poppycock!
In other words by objective standards: YOU ARE A LIAR
What do you understand about objective standards? Evidently, very
little.
We know that HHH is unable to reach the reachable 'ret' instruction.
We also know that it not possible to repair HHH. It is impossible for
HHH to simulate itself.
It is also a verified fact that HHH does simulate itself simulating DDD
thus again you are proven to be a liar.
No, it is you who is the liar. You lie continually by calling things you >> would like to be true "verified facts", regardless of the fact that these
assertions have never been verified by anybody other than yourself.
I have fully operational code of HHH correctly
simulating itself simulating DDD dipshit.
On 5/25/2025 2:39 PM, dbush wrote:
On 5/25/2025 3:04 PM, olcott wrote:
You Are the epitome of bad faith and dishonesty.
That I call you out on your lies and back it up with evidence is
anything but.
You must be an atheist or you would fear telling these lies.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 5/25/2025 11:59 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself and >>>>>>> Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty. >>>>>> If you could remove all dishonesty the protests woud stop, too, and >>>>>> nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH accordingWhy repeating this bug in HHH?
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug ....
That is untrue. The bug is clear to anybody who understands C code.
OK then to prove that you are not a damned liar
(you won't do this because you know that you are a liar)
show how DDD simulated by HHH according to the rules
of the x86 language reaches its own "ret" instruction
final halt state.
FIND THE BUG ASSHOLE !!!
.... makes your statement the kind of reckless disregard for the truth
that loses defamation cases.
Poppycock!
In other words by objective standards: YOU ARE A LIAR
What do you understand about objective standards? Evidently, very
little.
We know that HHH is unable to reach the reachable 'ret' instruction.
We also know that it not possible to repair HHH. It is impossible for
HHH to simulate itself.
It is also a verified fact that HHH does simulate itself simulating DDD
thus again you are proven to be a liar.
No, it is you who is the liar. You lie continually by calling things you
would like to be true "verified facts", regardless of the fact that these
assertions have never been verified by anybody other than yourself.
I have fully operational code of HHH correctly
simulating itself simulating DDD dipshit.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:Why repeating this bug in HHH?
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself >>>>>>> and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against
dishonesty.
If you could remove all dishonesty the protests woud stop, too, and >>>>>> nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug makes your statement
the kind of reckless disregard for the truth
that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR
Ad hominem attacks showing lack of counter arguments.
When you are objectively a liar then calling
you a liar is merely stating the facts.
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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. >>> ----------------------------
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately
false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
And you dishonestly left out the part that immediately follows where
he states that you are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
PO's problem is his misinterpretation of "its simulated input would
never stop running unless aborted".
In the case of his HHH/DD, the simulated input (DD) /does/ stop
running if simulated far enough, but
Ridiculously COUNTER-FACTUAL
void DDD()
{
HHH(DDD);
return;
}
At exactly what point does DDD simulated by
HHH reach its simulated "return" statement?
Would a googolplex of simulations be enough?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
After a googolplex of simulations does HHH get
tired and say screw it I am going to interpret
"push ebp" as "jmp 000021a3" ?
HHH simply /doesn't/ go far enough because PO has mistakenly decided
he's seen some pattern that implies non-halting in the trace. [A
pattern akin to the "tight loop" pattern, except that the tight loop
pattern is sound, while his pattern is unsound, matching on a halting
input. Simples!]
This proves, as you yourself said:
On 5/25/2025 3:04 PM, olcott wrote:
You Are the epitome of bad faith and dishonesty.
This may cost you your actual soul: Revelations 21:8.
On 5/25/2025 3:28 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/25/2025 11:59 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
That everyone that understands these things
sees that there is no bug ....
That is untrue. The bug is clear to anybody who understands C code.
OK then to prove that you are not a damned liar
(you won't do this because you know that you are a liar)
show how DDD simulated by HHH according to the rules
of the x86 language reaches its own "ret" instruction
final halt state.
You've got a wierd notion of what it means to be a liar.
FIND THE BUG ASSHOLE !!!
You're not a nice person. The bug in question has been pointed out many
times, in particular by Fred.
I am not going to be a nice person to those that
are lying about my work.
Being a nice person in this case is weakness and invitation to more
abuse.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Alluded to is not the same as pointing the
exact machine address where DDD emulated by
HHH breaks the rules of the x86 language
such that DDD emulated by HHH reaches its
own "ret" instruction.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 5/25/2025 3:28 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/25/2025 11:59 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that
myself and
Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against
dishonesty.
If you could remove all dishonesty the protests woud stop, too, and >>>>>>>> nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH accordingWhy repeating this bug in HHH?
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug ....
That is untrue. The bug is clear to anybody who understands C code.
OK then to prove that you are not a damned liar
(you won't do this because you know that you are a liar)
show how DDD simulated by HHH according to the rules
of the x86 language reaches its own "ret" instruction
final halt state.
You've got a wierd notion of what it means to be a liar.
FIND THE BUG ASSHOLE !!!
You're not a nice person. The bug in question has been pointed out many
times, in particular by Fred.
I am not going to be a nice person to those that
are lying about my work. Being a nice person in
this case is weakness and invitation to more abuse.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Alluded to is not the same as pointing the
exact machine address where DDD emulated by
HHH breaks the rules of the x86 language
such that DDD emulated by HHH reaches its
own "ret" instruction.
On 5/25/2025 3:47 PM, Richard Damon wrote:
On 5/25/25 4:30 PM, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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. >>>>> ----------------------------
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly >>>>> simulates as far as [A], at which point it correctly determines that >>>>> "its simulated input would never stop running unless aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately
false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
And you dishonestly left out the part that immediately follows where
he states that you are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
Nope.
You don't understand what he said.
Yes I did and you know I did and you risk
eternal damnation by saying otherwise.
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately
false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/? STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
And you dishonestly left out the part that immediately follows where he states that you are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
On 5/25/2025 2:27 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 20:42 schreef olcott:
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:Why repeating this bug in HHH?
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that
myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against
dishonesty.
If you could remove all dishonesty the protests woud stop, too, and >>>>>>>> nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug makes your statement
the kind of reckless disregard for the truth
that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR
Ad hominem attacks showing lack of counter arguments.
When you are objectively a liar then calling
you a liar is merely stating the facts.
Again a baseless ad hominem attack, showing lack of counter arguments.
I dared you to show my mistake your failure to even
attempt this sufficiently proves that you are a liar.
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing the decider, but
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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. >>>>> ----------------------------
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly >>>>> simulates as far as [A], at which point it correctly determines that >>>>> "its simulated input would never stop running unless aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately
false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
And you dishonestly left out the part that immediately follows where
he states that you are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/
- I did explain how Sipser's words can be naturally interpreted as
explaining
how a simulating halt decider can operate. [That is not a proof.] >>
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning
showing how an expression of language is true, this is a proof.
- I also explained why that explanation *doesn't* apply to your HHH/
DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets
completely confused even by this simple example.
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
Once you and I work through this one point I may
finally have complete closure.
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself and Peter >>> Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty.
If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
On 5/25/2025 7:11 PM, Richard Damon wrote:
On 5/25/25 4:53 PM, olcott wrote:
On 5/25/2025 3:47 PM, Richard Damon wrote:
On 5/25/25 4:30 PM, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I said a SHD >>>>>>> does above. It tells PO that in the tight loop example, H correctly >>>>>>> simulates as far as [A], at which point it correctly determines that >>>>>>> "its simulated input would never stop running unless aborted", so >>>>>>> it can decide "non-halting".
All correct and natural, and no deliberately
false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
And you dishonestly left out the part that immediately follows
where he states that you are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
Nope.
You don't understand what he said.
Yes I did and you know I did and you risk
eternal damnation by saying otherwise.
No, because you think your DDD that doesn't contain the code of HHH as
part of it can be simulated.
Liar!
On 5/25/2025 4:20 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/25/2025 3:28 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/25/2025 11:59 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
[ .... ]
That everyone that understands these things
sees that there is no bug ....
That is untrue. The bug is clear to anybody who understands C code.
OK then to prove that you are not a damned liar
(you won't do this because you know that you are a liar)
show how DDD simulated by HHH according to the rules
of the x86 language reaches its own "ret" instruction
final halt state.
You've got a wierd notion of what it means to be a liar.
FIND THE BUG ASSHOLE !!!
You're not a nice person. The bug in question has been pointed out
many
times, in particular by Fred.
I am not going to be a nice person to those that
are lying about my work.
There's only one person around here lying about your work.
Being a nice person in this case is weakness and invitation to more
abuse.
Do you have any friends in real life, just as a matter of interest?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Alluded to is not the same as pointing the
exact machine address where DDD emulated by
HHH breaks the rules of the x86 language
such that DDD emulated by HHH reaches its
own "ret" instruction.
There is no "exact address where ... breaks the rules of the X86
language." There's an art to slipping in loaded questions. You haven't >> mastered that art.
In that sequence of x86 instructions, the processor simply executes in
sequence, calling whatever HHH is,
There is no "whatever HHH is" when HHH is specified to simulate DDD.
which then returns and proceeds to the
ret instruction at 0x21a3. I think it's been established that by HHH you >> mean a certain function hosted on the GitHub website, and that that
function returns normally.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 5/26/2025 3:32 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 21:39 schreef olcott:
On 5/25/2025 2:27 PM, Fred. Zwarts wrote:You only ignore it when your failures are shown and start again
Op 25.mei.2025 om 20:42 schreef olcott:
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:Why repeating this bug in HHH?
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that >>>>>>>>>>> myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against >>>>>>>>>> dishonesty.
If you could remove all dishonesty the protests woud stop, >>>>>>>>>> too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug makes your statement
the kind of reckless disregard for the truth
that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR
Ad hominem attacks showing lack of counter arguments.
When you are objectively a liar then calling
you a liar is merely stating the facts.
Again a baseless ad hominem attack, showing lack of counter arguments.
I dared you to show my mistake your failure to even
attempt this sufficiently proves that you are a liar.
repeating the baseless claims.
Every competent programmer will understand that when the input
specifies a halting program, including the code to abort and return,
but HHH fails to see that part of the specification, then HHH has a bug.
I know you will ignore it again and reply with only ad hominem attacks.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing the decider, but
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I said a SHD >>>>>>> does above. It tells PO that in the tight loop example, H correctly >>>>>>> simulates as far as [A], at which point it correctly determines that >>>>>>> "its simulated input would never stop running unless aborted", so >>>>>>> it can decide "non-halting".
All correct and natural, and no deliberately
false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
And you dishonestly left out the part that immediately follows
where he states that you are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/
- I did explain how Sipser's words can be naturally interpreted as
explaining
how a simulating halt decider can operate. [That is not a proof.] >>>>
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning
showing how an expression of language is true, this is a proof.
- I also explained why that explanation *doesn't* apply to your
HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets
completely confused even by this simple example.
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
Once you and I work through this one point I may
finally have complete closure.
also the input.
We are discussing the input where DDD calls a HHH that aborts after
one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough
On 5/26/2025 11:07 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:16 schreef olcott:
On 5/26/2025 3:32 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 21:39 schreef olcott:_DDD()
On 5/25/2025 2:27 PM, Fred. Zwarts wrote:You only ignore it when your failures are shown and start again
Op 25.mei.2025 om 20:42 schreef olcott:
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:Why repeating this bug in HHH?
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that >>>>>>>>>>>>> myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against >>>>>>>>>>>> dishonesty.
If you could remove all dishonesty the protests woud stop, >>>>>>>>>>>> too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug makes your statement
the kind of reckless disregard for the truth
that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR
Ad hominem attacks showing lack of counter arguments.
When you are objectively a liar then calling
you a liar is merely stating the facts.
Again a baseless ad hominem attack, showing lack of counter
arguments.
I dared you to show my mistake your failure to even
attempt this sufficiently proves that you are a liar.
repeating the baseless claims.
Every competent programmer will understand that when the input
specifies a halting program, including the code to abort and return,
but HHH fails to see that part of the specification, then HHH has a
bug.
I know you will ignore it again and reply with only ad hominem attacks. >>>
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
HHH needs only one recursion more that the number of recursions in the
input.
So, if your HHH has only one recursion, two recursions are needed,
except when you change the input, but that is not allowed.
So you said that the first four instructions of DDD
are emulated twice and we are at machine address 0000219a.
So a correct emulator could interpret "call 000015d2"
to mean "jmp 000021a3" ???
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:And that is the bug in HHH. It does not go far enough.
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing the decider,
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:Just for the record:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I said a SHD >>>>>>>>> does above. It tells PO that in the tight loop example, H
correctly
simulates as far as [A], at which point it correctly determines >>>>>>>>> that
"its simulated input would never stop running unless aborted", so >>>>>>>>> it can decide "non-halting".
All correct and natural, and no deliberately
false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
And you dishonestly left out the part that immediately follows >>>>>>>> where he states that you are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met >>>>>>
1) I didn't offer any proofs of /anything/
- I did explain how Sipser's words can be naturally interpreted
as explaining
how a simulating halt decider can operate. [That is not a >>>>>> proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning
showing how an expression of language is true, this is a proof.
- I also explained why that explanation *doesn't* apply to your
HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets
completely confused even by this simple example.
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
Once you and I work through this one point I may
finally have complete closure.
but also the input.
We are discussing the input where DDD calls a HHH that aborts after
one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough
No Mike is just wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
On 5/26/2025 1:31 PM, Fred. Zwarts wrote:That is what I said. The simulated HHH, specified in the input, does
Op 26.mei.2025 om 18:20 schreef olcott:
On 5/26/2025 11:07 AM, Fred. Zwarts wrote:Apparently this is over your head. That is not what I said. You are
Op 26.mei.2025 om 17:16 schreef olcott:
On 5/26/2025 3:32 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 21:39 schreef olcott:
On 5/25/2025 2:27 PM, Fred. Zwarts wrote:You only ignore it when your failures are shown and start again
Op 25.mei.2025 om 20:42 schreef olcott:
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:Why repeating this bug in HHH?
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that >>>>>>>>>>>>>>> myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests >>>>>>>>>>>>>> against dishonesty.
If you could remove all dishonesty the protests woud stop, >>>>>>>>>>>>>> too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according >>>>>>>>>>>>> to the rules of the x86 language cannot possibly reach >>>>>>>>>>>>> its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug makes your statement
the kind of reckless disregard for the truth
that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR
Ad hominem attacks showing lack of counter arguments.
When you are objectively a liar then calling
you a liar is merely stating the facts.
Again a baseless ad hominem attack, showing lack of counter
arguments.
I dared you to show my mistake your failure to even
attempt this sufficiently proves that you are a liar.
repeating the baseless claims.
Every competent programmer will understand that when the input
specifies a halting program, including the code to abort and
return, but HHH fails to see that part of the specification, then
HHH has a bug.
I know you will ignore it again and reply with only ad hominem
attacks.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
HHH needs only one recursion more that the number of recursions in
the input.
So, if your HHH has only one recursion, two recursions are needed,
except when you change the input, but that is not allowed.
So you said that the first four instructions of DDD
are emulated twice and we are at machine address 0000219a.
So a correct emulator could interpret "call 000015d2"
to mean "jmp 000021a3" ???
mixing recursion levels.
The simulated HHH in its first recursion (which is the second
recursion of the simulating HHH) aborts at 0000219a (because we do not
change the input, so the simulated HHH aborts after one cycle). It is
programmed to not execute the call but abort and return. That will
make that the call at 0000219a simulated by the simulating HHH returns
and the simulating HHH will process the next instruction at 0000219f
and the following instructions, up to the 'ret' instruction at 000021a3.
A return from a call is very normal in the x86 language and if you
think that it means that the call is replaced with a jmp instruction,
you show your ignorance of the x86 language.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
unless some HHH aborts its emulation of its DDD
DDD() and HHH() never halt.
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:And that is the bug in HHH. It does not go far enough.
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing the decider,
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*And you dishonestly left out the part that immediately follows >>>>>>>>>> where he states that you are wrong:
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I said a SHD >>>>>>>>>>> does above. It tells PO that in the tight loop example, H >>>>>>>>>>> correctly
simulates as far as [A], at which point it correctly
determines that
"its simulated input would never stop running unless
aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately
false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are
exactly met
Just for the record:
1) I didn't offer any proofs of /anything/
- I did explain how Sipser's words can be naturally interpreted >>>>>>>> as explaining
how a simulating halt decider can operate. [That is not a >>>>>>>> proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning
showing how an expression of language is true, this is a proof.
- I also explained why that explanation *doesn't* apply to your >>>>>>>> HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets
completely confused even by this simple example.
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
Once you and I work through this one point I may
finally have complete closure.
but also the input.
We are discussing the input where DDD calls a HHH that aborts
after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough
No Mike is just wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
No, *you* are just wrong.
A correct simulation needs only one recursion more than the simulated
HHH. The bug in HHH is, that it aborts one cycle too early.
The outermost HHH always sees one whole recursive emulation
more than the next inner one.
This outer HHH aborts the
moment that it sees the infinite recursion behavior pattern.
If HHH waited for the next inner HHH to see this, then
this inner one would wait on its own next inner one
because every HHH has the exact same machine code at
the exact same machine address.
On 5/26/2025 1:55 PM, Fred. Zwarts wrote:I see that it is over your head. But it is simple:
Op 26.mei.2025 om 20:41 schreef olcott:
On 5/26/2025 1:31 PM, Fred. Zwarts wrote:That is what I said. The simulated HHH, specified in the input, does
Op 26.mei.2025 om 18:20 schreef olcott:
On 5/26/2025 11:07 AM, Fred. Zwarts wrote:Apparently this is over your head. That is not what I said. You are
Op 26.mei.2025 om 17:16 schreef olcott:
On 5/26/2025 3:32 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 21:39 schreef olcott:
On 5/25/2025 2:27 PM, Fred. Zwarts wrote:You only ignore it when your failures are shown and start again >>>>>>>> repeating the baseless claims.
Op 25.mei.2025 om 20:42 schreef olcott:
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:Why repeating this bug in HHH?
On 2025-05-24 01:20:18 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>
So much bad faith and dishonesty shown in this forum >>>>>>>>>>>>>>>>> that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests >>>>>>>>>>>>>>>> against dishonesty.
If you could remove all dishonesty the protests woud >>>>>>>>>>>>>>>> stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according >>>>>>>>>>>>>>> to the rules of the x86 language cannot possibly reach >>>>>>>>>>>>>>> its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug makes your statement
the kind of reckless disregard for the truth
that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR >>>>>>>>>>>>>
Ad hominem attacks showing lack of counter arguments.
When you are objectively a liar then calling
you a liar is merely stating the facts.
Again a baseless ad hominem attack, showing lack of counter >>>>>>>>>> arguments.
I dared you to show my mistake your failure to even
attempt this sufficiently proves that you are a liar.
Every competent programmer will understand that when the input >>>>>>>> specifies a halting program, including the code to abort and
return, but HHH fails to see that part of the specification,
then HHH has a bug.
I know you will ignore it again and reply with only ad hominem >>>>>>>> attacks.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
HHH needs only one recursion more that the number of recursions in >>>>>> the input.
So, if your HHH has only one recursion, two recursions are needed, >>>>>> except when you change the input, but that is not allowed.
So you said that the first four instructions of DDD
are emulated twice and we are at machine address 0000219a.
So a correct emulator could interpret "call 000015d2"
to mean "jmp 000021a3" ???
mixing recursion levels.
The simulated HHH in its first recursion (which is the second
recursion of the simulating HHH) aborts at 0000219a (because we do
not change the input, so the simulated HHH aborts after one cycle).
It is programmed to not execute the call but abort and return. That
will make that the call at 0000219a simulated by the simulating HHH
returns and the simulating HHH will process the next instruction at
0000219f and the following instructions, up to the 'ret' instruction
at 000021a3.
A return from a call is very normal in the x86 language and if you
think that it means that the call is replaced with a jmp
instruction, you show your ignorance of the x86 language.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
unless some HHH aborts its emulation of its DDD
DDD() and HHH() never halt.
abort, so no abort is needed in the simulating HHH.
Likewise when you are starving to death there is no reason
to get anything to eat because you know that after you eat
you will no longer be starving to death.
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 20:48 schreef olcott:
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:And that is the bug in HHH. It does not go far enough.
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing the
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*And you dishonestly left out the part that immediately >>>>>>>>>>>> follows where he states that you are wrong:
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I said >>>>>>>>>>>>> a SHD
does above. It tells PO that in the tight loop example, H >>>>>>>>>>>>> correctly
simulates as far as [A], at which point it correctly >>>>>>>>>>>>> determines that
"its simulated input would never stop running unless >>>>>>>>>>>>> aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately
false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are >>>>>>>>>>> exactly met
Just for the record:
1) I didn't offer any proofs of /anything/
- I did explain how Sipser's words can be naturally
interpreted as explaining
how a simulating halt decider can operate. [That is not a >>>>>>>>>> proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning
showing how an expression of language is true, this is a proof. >>>>>>>>>
- I also explained why that explanation *doesn't* apply to >>>>>>>>>> your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets
completely confused even by this simple example.
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
Once you and I work through this one point I may
finally have complete closure.
decider, but also the input.
We are discussing the input where DDD calls a HHH that aborts
after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough
No Mike is just wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
No, *you* are just wrong.
A correct simulation needs only one recursion more than the
simulated HHH. The bug in HHH is, that it aborts one cycle too early.
The outermost HHH always sees one whole recursive emulation
more than the next inner one.
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails.
My code proves otherwise. https://github.com/plolcott/x86utm/blob/master/Halt7.c
On 5/26/2025 2:07 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:01 schreef olcott:
On 5/26/2025 1:55 PM, Fred. Zwarts wrote:I see that it is over your head. But it is simple:
Op 26.mei.2025 om 20:41 schreef olcott:
On 5/26/2025 1:31 PM, Fred. Zwarts wrote:That is what I said. The simulated HHH, specified in the input, does
Op 26.mei.2025 om 18:20 schreef olcott:
On 5/26/2025 11:07 AM, Fred. Zwarts wrote:Apparently this is over your head. That is not what I said. You
Op 26.mei.2025 om 17:16 schreef olcott:So you said that the first four instructions of DDD
On 5/26/2025 3:32 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 21:39 schreef olcott:
On 5/25/2025 2:27 PM, Fred. Zwarts wrote:You only ignore it when your failures are shown and start
Op 25.mei.2025 om 20:42 schreef olcott:
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:When you are objectively a liar then calling
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:Why repeating this bug in HHH?
On 2025-05-24 01:20:18 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>>>
So much bad faith and dishonesty shown in this forum >>>>>>>>>>>>>>>>>>> that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests >>>>>>>>>>>>>>>>>> against dishonesty.
If you could remove all dishonesty the protests woud >>>>>>>>>>>>>>>>>> stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>> [000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according >>>>>>>>>>>>>>>>> to the rules of the x86 language cannot possibly reach >>>>>>>>>>>>>>>>> its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug makes your statement
the kind of reckless disregard for the truth
that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR >>>>>>>>>>>>>>>
Ad hominem attacks showing lack of counter arguments. >>>>>>>>>>>>>
you a liar is merely stating the facts.
Again a baseless ad hominem attack, showing lack of counter >>>>>>>>>>>> arguments.
I dared you to show my mistake your failure to even
attempt this sufficiently proves that you are a liar.
again repeating the baseless claims.
Every competent programmer will understand that when the input >>>>>>>>>> specifies a halting program, including the code to abort and >>>>>>>>>> return, but HHH fails to see that part of the specification, >>>>>>>>>> then HHH has a bug.
I know you will ignore it again and reply with only ad hominem >>>>>>>>>> attacks.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
HHH needs only one recursion more that the number of recursions >>>>>>>> in the input.
So, if your HHH has only one recursion, two recursions are
needed, except when you change the input, but that is not allowed. >>>>>>>
are emulated twice and we are at machine address 0000219a.
So a correct emulator could interpret "call 000015d2"
to mean "jmp 000021a3" ???
are mixing recursion levels.
The simulated HHH in its first recursion (which is the second
recursion of the simulating HHH) aborts at 0000219a (because we do >>>>>> not change the input, so the simulated HHH aborts after one
cycle). It is programmed to not execute the call but abort and
return. That will make that the call at 0000219a simulated by the
simulating HHH returns and the simulating HHH will process the
next instruction at 0000219f and the following instructions, up to >>>>>> the 'ret' instruction at 000021a3.
A return from a call is very normal in the x86 language and if you >>>>>> think that it means that the call is replaced with a jmp
instruction, you show your ignorance of the x86 language.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
unless some HHH aborts its emulation of its DDD
DDD() and HHH() never halt.
abort, so no abort is needed in the simulating HHH.
Likewise when you are starving to death there is no reason
to get anything to eat because you know that after you eat
you will no longer be starving to death.
If no-one is starving, we do not need to eat. If there is no non-
halting program, there is no need to abort its simulation.
Unless HHH(DDD) aborts its own simulation of DDD
then DDD(), HHH() never halt
On 5/26/2025 2:27 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:13 schreef olcott:
On 5/26/2025 2:07 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:01 schreef olcott:
On 5/26/2025 1:55 PM, Fred. Zwarts wrote:I see that it is over your head. But it is simple:
Op 26.mei.2025 om 20:41 schreef olcott:
On 5/26/2025 1:31 PM, Fred. Zwarts wrote:That is what I said. The simulated HHH, specified in the input,
Op 26.mei.2025 om 18:20 schreef olcott:
On 5/26/2025 11:07 AM, Fred. Zwarts wrote:Apparently this is over your head. That is not what I said. You >>>>>>>> are mixing recursion levels.
Op 26.mei.2025 om 17:16 schreef olcott:
On 5/26/2025 3:32 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 21:39 schreef olcott:
On 5/25/2025 2:27 PM, Fred. Zwarts wrote:You only ignore it when your failures are shown and start >>>>>>>>>>>> again repeating the baseless claims.
Op 25.mei.2025 om 20:42 schreef olcott:
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:When you are objectively a liar then calling
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>>>>>
So much bad faith and dishonesty shown in this >>>>>>>>>>>>>>>>>>>>> forum that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests >>>>>>>>>>>>>>>>>>>> against dishonesty.
If you could remove all dishonesty the protests woud >>>>>>>>>>>>>>>>>>>> stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according >>>>>>>>>>>>>>>>>>> to the rules of the x86 language cannot possibly reach >>>>>>>>>>>>>>>>>>> its own "ret" instruction final halt state. >>>>>>>>>>>>>>>>>> Why repeating this bug in HHH?
That everyone that understands these things
sees that there is no bug makes your statement >>>>>>>>>>>>>>>>> the kind of reckless disregard for the truth >>>>>>>>>>>>>>>>> that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR >>>>>>>>>>>>>>>>>
Ad hominem attacks showing lack of counter arguments. >>>>>>>>>>>>>>>
you a liar is merely stating the facts.
Again a baseless ad hominem attack, showing lack of >>>>>>>>>>>>>> counter arguments.
I dared you to show my mistake your failure to even
attempt this sufficiently proves that you are a liar. >>>>>>>>>>>>>
Every competent programmer will understand that when the >>>>>>>>>>>> input specifies a halting program, including the code to >>>>>>>>>>>> abort and return, but HHH fails to see that part of the >>>>>>>>>>>> specification, then HHH has a bug.
I know you will ignore it again and reply with only ad >>>>>>>>>>>> hominem attacks.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
HHH needs only one recursion more that the number of
recursions in the input.
So, if your HHH has only one recursion, two recursions are >>>>>>>>>> needed, except when you change the input, but that is not
allowed.
So you said that the first four instructions of DDD
are emulated twice and we are at machine address 0000219a.
So a correct emulator could interpret "call 000015d2"
to mean "jmp 000021a3" ???
The simulated HHH in its first recursion (which is the second
recursion of the simulating HHH) aborts at 0000219a (because we >>>>>>>> do not change the input, so the simulated HHH aborts after one >>>>>>>> cycle). It is programmed to not execute the call but abort and >>>>>>>> return. That will make that the call at 0000219a simulated by
the simulating HHH returns and the simulating HHH will process >>>>>>>> the next instruction at 0000219f and the following instructions, >>>>>>>> up to the 'ret' instruction at 000021a3.
A return from a call is very normal in the x86 language and if >>>>>>>> you think that it means that the call is replaced with a jmp
instruction, you show your ignorance of the x86 language.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
unless some HHH aborts its emulation of its DDD
DDD() and HHH() never halt.
does abort, so no abort is needed in the simulating HHH.
Likewise when you are starving to death there is no reason
to get anything to eat because you know that after you eat
you will no longer be starving to death.
If no-one is starving, we do not need to eat. If there is no non-
halting program, there is no need to abort its simulation.
Unless HHH(DDD) aborts its own simulation of DDD
then DDD(), HHH() never halt
Counter-factual. If we keep the input fixed, the simulated HHH aborts
after one cycle.
Every HHH has the exact same machine code.
If the outer HHH waits for the next inner one to abort
then the next inner one waits for its next inner one...
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing the decider, but
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I said a SHD >>>>>>> does above. It tells PO that in the tight loop example, H correctly >>>>>>> simulates as far as [A], at which point it correctly determines that >>>>>>> "its simulated input would never stop running unless aborted", so >>>>>>> it can decide "non-halting".
All correct and natural, and no deliberately
false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
And you dishonestly left out the part that immediately follows
where he states that you are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/
- I did explain how Sipser's words can be naturally interpreted as
explaining
how a simulating halt decider can operate. [That is not a proof.] >>>>
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning
showing how an expression of language is true, this is a proof.
- I also explained why that explanation *doesn't* apply to your
HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets
completely confused even by this simple example.
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
Once you and I work through this one point I may
finally have complete closure.
also the input.
We are discussing the input where DDD calls a HHH that aborts after
one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough
On 5/26/2025 3:32 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 21:39 schreef olcott:
On 5/25/2025 2:27 PM, Fred. Zwarts wrote:You only ignore it when your failures are shown and start again
Op 25.mei.2025 om 20:42 schreef olcott:
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:Why repeating this bug in HHH?
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that >>>>>>>>>>> myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against >>>>>>>>>> dishonesty.
If you could remove all dishonesty the protests woud stop, >>>>>>>>>> too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
That everyone that understands these things
sees that there is no bug makes your statement
the kind of reckless disregard for the truth
that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR
Ad hominem attacks showing lack of counter arguments.
When you are objectively a liar then calling
you a liar is merely stating the facts.
Again a baseless ad hominem attack, showing lack of counter arguments.
I dared you to show my mistake your failure to even
attempt this sufficiently proves that you are a liar.
repeating the baseless claims.
Every competent programmer will understand that when the input
specifies a halting program, including the code to abort and return,
but HHH fails to see that part of the specification, then HHH has a bug.
I know you will ignore it again and reply with only ad hominem attacks.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself
and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty. >>>> If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the beginning
to end.
I am asking you to affirm that I am correct about this point.
DDD simulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state, thus is correctly rejected as non-halting.
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself >>>>>>> and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against
dishonesty.
If you could remove all dishonesty the protests woud stop, too, and >>>>>> nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the
beginning
to end.
I am asking you to affirm that I am correct about this point.
DDD simulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state, thus is correctly rejected as non-halting.
But you have to affirm first that HHH *IS* a program that does that,
and can't be "changed" to some other program, and that DDD is
"completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
On 5/26/2025 2:54 PM, Fred. Zwarts wrote:Completely irrelevant in this discussion. So, no rebuttal.
Op 26.mei.2025 om 21:42 schreef olcott:
On 5/26/2025 2:27 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:13 schreef olcott:
On 5/26/2025 2:07 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:01 schreef olcott:
On 5/26/2025 1:55 PM, Fred. Zwarts wrote:I see that it is over your head. But it is simple:
Op 26.mei.2025 om 20:41 schreef olcott:
On 5/26/2025 1:31 PM, Fred. Zwarts wrote:That is what I said. The simulated HHH, specified in the input, >>>>>>>> does abort, so no abort is needed in the simulating HHH.
Op 26.mei.2025 om 18:20 schreef olcott:
On 5/26/2025 11:07 AM, Fred. Zwarts wrote:Apparently this is over your head. That is not what I said. >>>>>>>>>> You are mixing recursion levels.
Op 26.mei.2025 om 17:16 schreef olcott:
On 5/26/2025 3:32 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 21:39 schreef olcott:
On 5/25/2025 2:27 PM, Fred. Zwarts wrote:You only ignore it when your failures are shown and start >>>>>>>>>>>>>> again repeating the baseless claims.
Op 25.mei.2025 om 20:42 schreef olcott:
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:When you are objectively a liar then calling >>>>>>>>>>>>>>>>> you a liar is merely stating the facts.
On 5/25/2025 10:49 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 25.mei.2025 om 16:36 schreef olcott: >>>>>>>>>>>>>>>>>>>>> On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>>>>>>>
So much bad faith and dishonesty shown in this >>>>>>>>>>>>>>>>>>>>>>> forum that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and >>>>>>>>>>>>>>>>>>>>>> protests against dishonesty.
If you could remove all dishonesty the protests >>>>>>>>>>>>>>>>>>>>>> woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according >>>>>>>>>>>>>>>>>>>>> to the rules of the x86 language cannot possibly reach >>>>>>>>>>>>>>>>>>>>> its own "ret" instruction final halt state. >>>>>>>>>>>>>>>>>>>> Why repeating this bug in HHH?
That everyone that understands these things >>>>>>>>>>>>>>>>>>> sees that there is no bug makes your statement >>>>>>>>>>>>>>>>>>> the kind of reckless disregard for the truth >>>>>>>>>>>>>>>>>>> that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR >>>>>>>>>>>>>>>>>>>
Ad hominem attacks showing lack of counter arguments. >>>>>>>>>>>>>>>>>
Again a baseless ad hominem attack, showing lack of >>>>>>>>>>>>>>>> counter arguments.
I dared you to show my mistake your failure to even >>>>>>>>>>>>>>> attempt this sufficiently proves that you are a liar. >>>>>>>>>>>>>>>
Every competent programmer will understand that when the >>>>>>>>>>>>>> input specifies a halting program, including the code to >>>>>>>>>>>>>> abort and return, but HHH fails to see that part of the >>>>>>>>>>>>>> specification, then HHH has a bug.
I know you will ignore it again and reply with only ad >>>>>>>>>>>>>> hominem attacks.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
HHH needs only one recursion more that the number of
recursions in the input.
So, if your HHH has only one recursion, two recursions are >>>>>>>>>>>> needed, except when you change the input, but that is not >>>>>>>>>>>> allowed.
So you said that the first four instructions of DDD
are emulated twice and we are at machine address 0000219a. >>>>>>>>>>> So a correct emulator could interpret "call 000015d2"
to mean "jmp 000021a3" ???
The simulated HHH in its first recursion (which is the second >>>>>>>>>> recursion of the simulating HHH) aborts at 0000219a (because >>>>>>>>>> we do not change the input, so the simulated HHH aborts after >>>>>>>>>> one cycle). It is programmed to not execute the call but abort >>>>>>>>>> and return. That will make that the call at 0000219a simulated >>>>>>>>>> by the simulating HHH returns and the simulating HHH will
process the next instruction at 0000219f and the following >>>>>>>>>> instructions, up to the 'ret' instruction at 000021a3.
A return from a call is very normal in the x86 language and if >>>>>>>>>> you think that it means that the call is replaced with a jmp >>>>>>>>>> instruction, you show your ignorance of the x86 language.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
unless some HHH aborts its emulation of its DDD
DDD() and HHH() never halt.
Likewise when you are starving to death there is no reason
to get anything to eat because you know that after you eat
you will no longer be starving to death.
If no-one is starving, we do not need to eat. If there is no non-
halting program, there is no need to abort its simulation.
Unless HHH(DDD) aborts its own simulation of DDD
then DDD(), HHH() never halt
Counter-factual. If we keep the input fixed, the simulated HHH
aborts after one cycle.
Every HHH has the exact same machine code.
If the outer HHH waits for the next inner one to abort
then the next inner one waits for its next inner one...
So, you admit that you change the input when you change the simulator.
That is a stupid thing to say that has nothing to do
with recursive emulation.
If the outer HHH waits for the next inner one to abort
then the next inner one waits for its next inner one...
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the input
Op 26.mei.2025 om 20:48 schreef olcott:
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:The outermost HHH always sees one whole recursive emulation
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:And that is the bug in HHH. It does not go far enough.
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing the
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*And you dishonestly left out the part that immediately >>>>>>>>>>>>>> follows where he states that you are wrong:
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I >>>>>>>>>>>>>>> said a SHD
does above. It tells PO that in the tight loop example, >>>>>>>>>>>>>>> H correctly
simulates as far as [A], at which point it correctly >>>>>>>>>>>>>>> determines that
"its simulated input would never stop running unless >>>>>>>>>>>>>>> aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately
false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>>>
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are >>>>>>>>>>>>> exactly met
Just for the record:
1) I didn't offer any proofs of /anything/
- I did explain how Sipser's words can be naturally
interpreted as explaining
how a simulating halt decider can operate. [That is not >>>>>>>>>>>> a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning >>>>>>>>>>> showing how an expression of language is true, this is a proof. >>>>>>>>>>>
- I also explained why that explanation *doesn't* apply to >>>>>>>>>>>> your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets
completely confused even by this simple example.
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
Once you and I work through this one point I may
finally have complete closure.
decider, but also the input.
We are discussing the input where DDD calls a HHH that aborts >>>>>>>>>> after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough
No Mike is just wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
No, *you* are just wrong.
A correct simulation needs only one recursion more than the
simulated HHH. The bug in HHH is, that it aborts one cycle too early. >>>>>
more than the next inner one.
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails.
My code proves otherwise.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and specifies an abort, so the program specified by the input halts.
But HHH fails to see that. It does not even start to simulate itself,
but aborts at that point. So, it is in no way a proof that your
simulator is able to simulate itself, let alone to simulate itself
correctly.
It is a verified fact that HHH does simulate itself simulating DDD.
If you are too incompetent to understand that this does not count
as a rebuttal.
On 5/26/2025 9:09 PM, Richard Damon wrote:
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that
myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against
dishonesty.
If you could remove all dishonesty the protests woud stop, too, and >>>>>>>> nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the
beginning
to end.
I am asking you to affirm that I am correct about this point.
DDD simulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state, thus is correctly rejected as non-halting.
But you have to affirm first that HHH *IS* a program that does that,
and can't be "changed" to some other program, and that DDD is
"completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that
DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
It is a tautology that every input that must be
aborted to prevent the infinite simulation of this
input DOES SPECIFY NON-HALTING BEHAVIOR.
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself and Peter >>>> Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty.
If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the beginning
to end.
On 5/26/2025 2:27 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:13 schreef olcott:
On 5/26/2025 2:07 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:01 schreef olcott:
On 5/26/2025 1:55 PM, Fred. Zwarts wrote:I see that it is over your head. But it is simple:
Op 26.mei.2025 om 20:41 schreef olcott:
On 5/26/2025 1:31 PM, Fred. Zwarts wrote:That is what I said. The simulated HHH, specified in the input, does >>>>>> abort, so no abort is needed in the simulating HHH.
Op 26.mei.2025 om 18:20 schreef olcott:
On 5/26/2025 11:07 AM, Fred. Zwarts wrote:Apparently this is over your head. That is not what I said. You are >>>>>>>> mixing recursion levels.
Op 26.mei.2025 om 17:16 schreef olcott:
On 5/26/2025 3:32 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 21:39 schreef olcott:
On 5/25/2025 2:27 PM, Fred. Zwarts wrote:You only ignore it when your failures are shown and start again >>>>>>>>>>>> repeating the baseless claims.
Op 25.mei.2025 om 20:42 schreef olcott:
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:When you are objectively a liar then calling
On 5/25/2025 10:49 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:36 schreef olcott:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>>>>>
So much bad faith and dishonesty shown in this forum that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty.
If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according >>>>>>>>>>>>>>>>>>> to the rules of the x86 language cannot possibly reach >>>>>>>>>>>>>>>>>>> its own "ret" instruction final halt state. >>>>>>>>>>>>>>>>>> Why repeating this bug in HHH?
That everyone that understands these things
sees that there is no bug makes your statement >>>>>>>>>>>>>>>>> the kind of reckless disregard for the truth >>>>>>>>>>>>>>>>> that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR >>>>>>>>>>>>>>>>>
Ad hominem attacks showing lack of counter arguments. >>>>>>>>>>>>>>>
you a liar is merely stating the facts.
Again a baseless ad hominem attack, showing lack of counter arguments.
I dared you to show my mistake your failure to even
attempt this sufficiently proves that you are a liar. >>>>>>>>>>>>>
Every competent programmer will understand that when the input >>>>>>>>>>>> specifies a halting program, including the code to abort and return,
but HHH fails to see that part of the specification, then HHH has a bug.
I know you will ignore it again and reply with only ad hominem attacks.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
HHH needs only one recursion more that the number of recursions in the input.
So, if your HHH has only one recursion, two recursions are needed, >>>>>>>>>> except when you change the input, but that is not allowed.
So you said that the first four instructions of DDD
are emulated twice and we are at machine address 0000219a.
So a correct emulator could interpret "call 000015d2"
to mean "jmp 000021a3" ???
The simulated HHH in its first recursion (which is the second recursion
of the simulating HHH) aborts at 0000219a (because we do not change the
input, so the simulated HHH aborts after one cycle). It is programmed >>>>>>>> to not execute the call but abort and return. That will make that the >>>>>>>> call at 0000219a simulated by the simulating HHH returns and the >>>>>>>> simulating HHH will process the next instruction at 0000219f and the >>>>>>>> following instructions, up to the 'ret' instruction at 000021a3. >>>>>>>> A return from a call is very normal in the x86 language and if you >>>>>>>> think that it means that the call is replaced with a jmp instruction, >>>>>>>> you show your ignorance of the x86 language.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
unless some HHH aborts its emulation of its DDD
DDD() and HHH() never halt.
Likewise when you are starving to death there is no reason
to get anything to eat because you know that after you eat
you will no longer be starving to death.
If no-one is starving, we do not need to eat. If there is no non-
halting program, there is no need to abort its simulation.
Unless HHH(DDD) aborts its own simulation of DDD
then DDD(), HHH() never halt
Counter-factual. If we keep the input fixed, the simulated HHH aborts
after one cycle.
Every HHH has the exact same machine code.
On 5/26/2025 9:09 PM, Richard Damon wrote:
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty.
If you could remove all dishonesty the protests woud stop, too, and >>>>>>>> nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the beginning
to end.
I am asking you to affirm that I am correct about this point.
DDD simulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state, thus is correctly rejected as non-halting.
But you have to affirm first that HHH *IS* a program that does that,
and can't be "changed" to some other program, and that DDD is
"completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that
DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
On 5/26/2025 2:54 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:42 schreef olcott:
On 5/26/2025 2:27 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:13 schreef olcott:
On 5/26/2025 2:07 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:01 schreef olcott:
On 5/26/2025 1:55 PM, Fred. Zwarts wrote:I see that it is over your head. But it is simple:
Op 26.mei.2025 om 20:41 schreef olcott:
On 5/26/2025 1:31 PM, Fred. Zwarts wrote:That is what I said. The simulated HHH, specified in the input, does >>>>>>>> abort, so no abort is needed in the simulating HHH.
Op 26.mei.2025 om 18:20 schreef olcott:
On 5/26/2025 11:07 AM, Fred. Zwarts wrote:Apparently this is over your head. That is not what I said. You are >>>>>>>>>> mixing recursion levels.
Op 26.mei.2025 om 17:16 schreef olcott:So you said that the first four instructions of DDD
On 5/26/2025 3:32 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 21:39 schreef olcott:
On 5/25/2025 2:27 PM, Fred. Zwarts wrote:You only ignore it when your failures are shown and start again >>>>>>>>>>>>>> repeating the baseless claims.
Op 25.mei.2025 om 20:42 schreef olcott:
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:When you are objectively a liar then calling >>>>>>>>>>>>>>>>> you a liar is merely stating the facts.
On 5/25/2025 10:49 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 25.mei.2025 om 16:36 schreef olcott: >>>>>>>>>>>>>>>>>>>>> On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>>>>>>>
So much bad faith and dishonesty shown in this forum that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty.
If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according >>>>>>>>>>>>>>>>>>>>> to the rules of the x86 language cannot possibly reach >>>>>>>>>>>>>>>>>>>>> its own "ret" instruction final halt state. >>>>>>>>>>>>>>>>>>>> Why repeating this bug in HHH?
That everyone that understands these things >>>>>>>>>>>>>>>>>>> sees that there is no bug makes your statement >>>>>>>>>>>>>>>>>>> the kind of reckless disregard for the truth >>>>>>>>>>>>>>>>>>> that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR >>>>>>>>>>>>>>>>>>>
Ad hominem attacks showing lack of counter arguments. >>>>>>>>>>>>>>>>>
Again a baseless ad hominem attack, showing lack of counter arguments.
I dared you to show my mistake your failure to even >>>>>>>>>>>>>>> attempt this sufficiently proves that you are a liar. >>>>>>>>>>>>>>>
Every competent programmer will understand that when the input >>>>>>>>>>>>>> specifies a halting program, including the code to abort and return,
but HHH fails to see that part of the specification, then HHH has a bug.
I know you will ignore it again and reply with only ad hominem attacks.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
HHH needs only one recursion more that the number of recursions in the input.
So, if your HHH has only one recursion, two recursions are needed, >>>>>>>>>>>> except when you change the input, but that is not allowed. >>>>>>>>>>>
are emulated twice and we are at machine address 0000219a. >>>>>>>>>>> So a correct emulator could interpret "call 000015d2"
to mean "jmp 000021a3" ???
The simulated HHH in its first recursion (which is the second recursion
of the simulating HHH) aborts at 0000219a (because we do not change the
input, so the simulated HHH aborts after one cycle). It is programmed
to not execute the call but abort and return. That will make that the
call at 0000219a simulated by the simulating HHH returns and the >>>>>>>>>> simulating HHH will process the next instruction at 0000219f and the >>>>>>>>>> following instructions, up to the 'ret' instruction at 000021a3. >>>>>>>>>> A return from a call is very normal in the x86 language and if you >>>>>>>>>> think that it means that the call is replaced with a jmp instruction,
you show your ignorance of the x86 language.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
unless some HHH aborts its emulation of its DDD
DDD() and HHH() never halt.
Likewise when you are starving to death there is no reason
to get anything to eat because you know that after you eat
you will no longer be starving to death.
If no-one is starving, we do not need to eat. If there is no non-
halting program, there is no need to abort its simulation.
Unless HHH(DDD) aborts its own simulation of DDD
then DDD(), HHH() never halt
Counter-factual. If we keep the input fixed, the simulated HHH aborts
after one cycle.
Every HHH has the exact same machine code.
If the outer HHH waits for the next inner one to abort
then the next inner one waits for its next inner one...
So, you admit that you change the input when you change the simulator.
That is a stupid thing to say that has nothing to do
with recursive emulation.
On 5/26/2025 9:09 PM, Richard Damon wrote:
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that
myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against
dishonesty.
If you could remove all dishonesty the protests woud stop, too, and >>>>>>>> nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the
beginning
to end.
I am asking you to affirm that I am correct about this point.
DDD simulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state, thus is correctly rejected as non-halting.
But you have to affirm first that HHH *IS* a program that does that,
and can't be "changed" to some other program, and that DDD is
"completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that
DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
It is a tautology that every input that must be
aborted to prevent the infinite simulation of this
input DOES SPECIFY NON-HALTING BEHAVIOR.
The term "Program" is too narrow minded.
Unit of computation within a model of computation.
On 5/27/2025 10:45 AM, Richard Heathfield wrote:
On 27/05/2025 16:28, olcott wrote:
The term "Program" is too narrow minded.
Unit of computation within a model of computation.
You do like to keep your words moving, don't you?
If you don't like 'program', why not use the term 'computation'?
I need my work stated in such a way that it can be plugged
into C functions, x86 machine language functions, TMs,
RASP machines.
On 5/27/2025 12:01 PM, Richard Heathfield wrote:
On 27/05/2025 16:52, olcott wrote:
On 5/27/2025 10:45 AM, Richard Heathfield wrote:
On 27/05/2025 16:28, olcott wrote:
The term "Program" is too narrow minded.
Unit of computation within a model of computation.
You do like to keep your words moving, don't you?
If you don't like 'program', why not use the term 'computation'?
I need my work stated in such a way that it can be plugged
into C functions, x86 machine language functions, TMs,
RASP machines.
'Computation' covers all of those.
Not enough specificity.
On 5/27/2025 5:12 AM, Mikko wrote:
On 2025-05-27 02:22:55 +0000, olcott said:
On 5/26/2025 9:09 PM, Richard Damon wrote:
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that >>>>>>>>>>> myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against >>>>>>>>>> dishonesty.
If you could remove all dishonesty the protests woud stop, >>>>>>>>>> too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the >>>>>>>> beginning
to end.
I am asking you to affirm that I am correct about this point.
DDD simulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state, thus is correctly rejected as non-halting.
But you have to affirm first that HHH *IS* a program that does
that, and can't be "changed" to some other program, and that DDD
is "completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a fact
that DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
And predict so that if the prediction is ever tested it is not found
wrong.
*Termination analyzers PREDICT behavior dip-shit*
It is a tautology that every input that must be
aborted to prevent the infinite simulation of this
input DOES SPECIFY NON-HALTING BEHAVIOR.
Disagreeing with tautologies is intolerably dishonest.
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the input
Op 26.mei.2025 om 20:48 schreef olcott:
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:And that is the bug in HHH. It does not go far enough.
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing the >>>>>>>>>>>> decider, but also the input.
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*And you dishonestly left out the part that immediately >>>>>>>>>>>>>>>> follows where he states that you are wrong:
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I >>>>>>>>>>>>>>>>> said a SHD
does above. It tells PO that in the tight loop >>>>>>>>>>>>>>>>> example, H correctly
simulates as far as [A], at which point it correctly >>>>>>>>>>>>>>>>> determines that
"its simulated input would never stop running unless >>>>>>>>>>>>>>>>> aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>> false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>>>>>
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are >>>>>>>>>>>>>>> exactly met
Just for the record:
1) I didn't offer any proofs of /anything/
- I did explain how Sipser's words can be naturally >>>>>>>>>>>>>> interpreted as explaining
how a simulating halt decider can operate. [That is >>>>>>>>>>>>>> not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning >>>>>>>>>>>>> showing how an expression of language is true, this is a >>>>>>>>>>>>> proof.
- I also explained why that explanation *doesn't* apply >>>>>>>>>>>>>> to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets
completely confused even by this simple example.
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
Once you and I work through this one point I may
finally have complete closure.
We are discussing the input where DDD calls a HHH that >>>>>>>>>>>> aborts after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough
No Mike is just wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
No, *you* are just wrong.
A correct simulation needs only one recursion more than the
simulated HHH. The bug in HHH is, that it aborts one cycle too >>>>>>>> early.
The outermost HHH always sees one whole recursive emulation
more than the next inner one.
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails.
My code proves otherwise.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and specifies an abort, so the program specified by the input halts.
But HHH fails to see that. It does not even start to simulate
itself, but aborts at that point. So, it is in no way a proof that
your simulator is able to simulate itself, let alone to simulate
itself correctly.
It is a verified fact that HHH does simulate itself simulating DDD.
If you are too incompetent to understand that this does not count
as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does not
simulate itself, but aborts the simulation at the point where the
simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false assumptions
about itself, in particular it assumes that 'itself' does not halt.
That you do not understand your own code is in no way a rebuttal for
my claim that no simulator is able to simulate itself up to the end.
On 5/27/2025 3:37 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 04:22 schreef olcott:
On 5/26/2025 9:09 PM, Richard Damon wrote:Counter-factual. There is no need to prevent infinite simulation,
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that >>>>>>>>>>> myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against >>>>>>>>>> dishonesty.
If you could remove all dishonesty the protests woud stop, >>>>>>>>>> too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the >>>>>>>> beginning
to end.
I am asking you to affirm that I am correct about this point.
DDD simulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state, thus is correctly rejected as non-halting.
But you have to affirm first that HHH *IS* a program that does
that, and can't be "changed" to some other program, and that DDD
is "completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a fact
that DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
It is a tautology that every input that must be
aborted to prevent the infinite simulation of this
input DOES SPECIFY NON-HALTING BEHAVIOR.
because the input includes DDD with all functions called by DDD,
including the code in Halt7.c that specifies the abort.
Unless the outmost HHH aborts then none of them
abort because they all of the exact same machine code.
On 5/27/2025 5:04 AM, Mikko wrote:
On 2025-05-26 19:42:15 +0000, olcott said:
On 5/26/2025 2:27 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:13 schreef olcott:
On 5/26/2025 2:07 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:01 schreef olcott:
On 5/26/2025 1:55 PM, Fred. Zwarts wrote:I see that it is over your head. But it is simple:
Op 26.mei.2025 om 20:41 schreef olcott:
On 5/26/2025 1:31 PM, Fred. Zwarts wrote:That is what I said. The simulated HHH, specified in the input, >>>>>>>> does abort, so no abort is needed in the simulating HHH.
Op 26.mei.2025 om 18:20 schreef olcott:
On 5/26/2025 11:07 AM, Fred. Zwarts wrote:Apparently this is over your head. That is not what I said. >>>>>>>>>> You are mixing recursion levels.
Op 26.mei.2025 om 17:16 schreef olcott:
On 5/26/2025 3:32 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 21:39 schreef olcott:
On 5/25/2025 2:27 PM, Fred. Zwarts wrote:You only ignore it when your failures are shown and start >>>>>>>>>>>>>> again repeating the baseless claims.
Op 25.mei.2025 om 20:42 schreef olcott:
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:When you are objectively a liar then calling >>>>>>>>>>>>>>>>> you a liar is merely stating the facts.
On 5/25/2025 10:49 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 25.mei.2025 om 16:36 schreef olcott: >>>>>>>>>>>>>>>>>>>>> On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>>>>>>>
So much bad faith and dishonesty shown in this >>>>>>>>>>>>>>>>>>>>>>> forum that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and >>>>>>>>>>>>>>>>>>>>>> protests against dishonesty.
If you could remove all dishonesty the protests >>>>>>>>>>>>>>>>>>>>>> woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according >>>>>>>>>>>>>>>>>>>>> to the rules of the x86 language cannot possibly reach >>>>>>>>>>>>>>>>>>>>> its own "ret" instruction final halt state. >>>>>>>>>>>>>>>>>>>> Why repeating this bug in HHH?
That everyone that understands these things >>>>>>>>>>>>>>>>>>> sees that there is no bug makes your statement >>>>>>>>>>>>>>>>>>> the kind of reckless disregard for the truth >>>>>>>>>>>>>>>>>>> that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR >>>>>>>>>>>>>>>>>>>
Ad hominem attacks showing lack of counter arguments. >>>>>>>>>>>>>>>>>
Again a baseless ad hominem attack, showing lack of >>>>>>>>>>>>>>>> counter arguments.
I dared you to show my mistake your failure to even >>>>>>>>>>>>>>> attempt this sufficiently proves that you are a liar. >>>>>>>>>>>>>>>
Every competent programmer will understand that when the >>>>>>>>>>>>>> input specifies a halting program, including the code to >>>>>>>>>>>>>> abort and return, but HHH fails to see that part of the >>>>>>>>>>>>>> specification, then HHH has a bug.
I know you will ignore it again and reply with only ad >>>>>>>>>>>>>> hominem attacks.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
HHH needs only one recursion more that the number of
recursions in the input.
So, if your HHH has only one recursion, two recursions are >>>>>>>>>>>> needed, except when you change the input, but that is not >>>>>>>>>>>> allowed.
So you said that the first four instructions of DDD
are emulated twice and we are at machine address 0000219a. >>>>>>>>>>> So a correct emulator could interpret "call 000015d2"
to mean "jmp 000021a3" ???
The simulated HHH in its first recursion (which is the second >>>>>>>>>> recursion of the simulating HHH) aborts at 0000219a (because >>>>>>>>>> we do not change the input, so the simulated HHH aborts after >>>>>>>>>> one cycle). It is programmed to not execute the call but abort >>>>>>>>>> and return. That will make that the call at 0000219a simulated >>>>>>>>>> by the simulating HHH returns and the simulating HHH will
process the next instruction at 0000219f and the following >>>>>>>>>> instructions, up to the 'ret' instruction at 000021a3.
A return from a call is very normal in the x86 language and if >>>>>>>>>> you think that it means that the call is replaced with a jmp >>>>>>>>>> instruction, you show your ignorance of the x86 language.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
unless some HHH aborts its emulation of its DDD
DDD() and HHH() never halt.
Likewise when you are starving to death there is no reason
to get anything to eat because you know that after you eat
you will no longer be starving to death.
If no-one is starving, we do not need to eat. If there is no non-
halting program, there is no need to abort its simulation.
Unless HHH(DDD) aborts its own simulation of DDD
then DDD(), HHH() never halt
Counter-factual. If we keep the input fixed, the simulated HHH
aborts after one cycle.
Every HHH has the exact same machine code.
I.e., there is only one HHH, so saying "every HHH" is pointless.
Each recursive invocation creates another HHH instance
with its own virtual registers, stack and RAM.
On 5/27/2025 6:11 AM, Richard Damon wrote:
On 5/26/25 10:22 PM, olcott wrote:
On 5/26/2025 9:09 PM, Richard Damon wrote:
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that >>>>>>>>>>> myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against >>>>>>>>>> dishonesty.
If you could remove all dishonesty the protests woud stop, >>>>>>>>>> too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the >>>>>>>> beginning
to end.
I am asking you to affirm that I am correct about this point.
DDD simulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state, thus is correctly rejected as non-halting.
But you have to affirm first that HHH *IS* a program that does
that, and can't be "changed" to some other program, and that DDD
is "completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a fact
that DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
It is a tautology that every input that must be
aborted to prevent the infinite simulation of this
input DOES SPECIFY NON-HALTING BEHAVIOR.
RIGHT, A Termination analyzer is a PROGRAM that predicts the behavior
of the PROGRAM that has been supplied as an input.
The term "Program" is too narrow minded.
Unit of computation within a model of computation.
<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
This means that you H, must be fully defined in behavior, so it is a
program, and that the input contain all the code it uses, and thus (a
copy) of the code of the decider it is goig to all.
The x86 machine code of every function in Halt7.c shares
the same global memory space. The behavior is fully defined
by the x86 language of each function.
The heart of the x86utm operating system is https://github.com/wfeldt/libx86emu
a world class x86 emulator.
Your idea of an "infinte set" of deciders doesn't create "a" problem
to solve, but an infinite set of problems, each with a DIFFERENT
input, and thus you can look at one version to determine the behavior
of another.
In other words when I prove that:
All X are Y
you fail to understand that this entails:
Some X are not Y is false.
It is a Tautology, that any program that just calls a Analyzer that
will eventually return 0, and then halts, will halt.
You are still stupidly conflating an aborted simulation
with halting. They are not the same. Halting in computer
science is the same as a normal termination in software
engineering. Unless DDD emulated by HHH reaches its "ret"
instruction final halt state DDD HAS NEVER HALTED.
The use "must" in the sense you are using it doesn't work, as if the
Termination analyzer decided to abort, then it does abort, and to
determine if that was correct, we need to look at the correct simulation
Once HHH has correctly matches a non-terminating behavior
pattern it has complete proof that its simulated input
cannot possibly reach its own simulated "ret" instruction
final halt state.
of *THAT* input, which from our tautology, we know that it *WILL* halt,
If you run a program on a computer and smash the computer
into tiny bits with a sledge hammer we cannot say that its
program terminated normally, thus never halted. As soon as
we know that a simulated input cannot possibly reach its
own final halt state then we know it is non-halting.
and thusthe decider didn't "need" to abort, but just did. You can't at
this point change it not to abort, as you can't change programs
without making them a different program.
Thus, your infinite set of programs can be divided into two classes:
Class 1, those deciders that do abort because they were programmed to
do so, under the mistaken belief that they needed to. None of the
deciders see the input reaching a final state, so return 0, but all of
the inputs, when given to a correct simulator (while still calling the
decider that aborted and returns 0) will halt. Thus, ALL the Class 1
deciders failed to predict the behavior of their input.
Class 2, those deciders that do not ever abort because that is the way
they are programmed. None of these deciders will ever return an
answer, and thus just fail to be deciders, because it is true that a
program that tries to actually completely simulate itself will become
non- halting. By not answering these deciders have failed, but there
input was a class 2 input, and thus do not show anything about the
behavior of a class 1 input.
Your problem is you forget about the requirement for things to be a
program, or just don't understand what that means. You then try to
look at a system that doesn't actually implement and follow the
requirements of the problem, as it can't have two independent programs
in it, which you sometimes admit.
Your argument is based on self-contradictory assumoptions, and thus is
just invalid. You have admitted and stipulated that your decider and
input are not programs, and thus just not valid entities to talk about
in the problem. You have asserted that your publisbhed Halt7.c is
always part of the problem, but also that you are allowed to change
the code that it specifies. In other words, you insist on the right to
just LIE about what your system is.
Sorry, all you are doing is proi=ving that you don't understand how to
form a coherent argument, and that you "logic" system is based on the
right to lie. This has sunk you ideas and reputation into the lake of
fire that you seem to be ready to join in the near future.
On 5/27/2025 10:45 AM, Richard Heathfield wrote:
On 27/05/2025 16:28, olcott wrote:
The term "Program" is too narrow minded.
Unit of computation within a model of computation.
You do like to keep your words moving, don't you?
If you don't like 'program', why not use the term 'computation'?
I need my work stated in such a way that it can be plugged
into C functions, x86 machine language functions, TMs,
RASP machines.
After all, computations are what computers do.
This will keep the dictionary happy:
"The act or process of computing; calculation; reckoning.
The result of computation; the amount computed."
Wikipedia is happy: "Mechanical or electronic devices (or,
historically, people) that perform computations are known as computers."
And the rest of us can keep saying 'program' because /we/ know what we
mean by it even if you don't.
On 5/27/2025 12:01 PM, Richard Heathfield wrote:
On 27/05/2025 16:52, olcott wrote:
On 5/27/2025 10:45 AM, Richard Heathfield wrote:
On 27/05/2025 16:28, olcott wrote:
The term "Program" is too narrow minded.
Unit of computation within a model of computation.
You do like to keep your words moving, don't you?
If you don't like 'program', why not use the term 'computation'?
I need my work stated in such a way that it can be plugged
into C functions, x86 machine language functions, TMs,
RASP machines.
'Computation' covers all of those.
Not enough specificity.
On 5/27/2025 5:10 AM, Mikko wrote:
On 2025-05-26 10:04:02 +0000, Mikko said:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself
and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against
dishonesty.
If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the
beginning
to end.
You may ask again after you have corrected at least one error that I or
somene else has pointed out.
Disagreeing with verified facts is intolerably dishonest.
On 5/27/2025 5:10 AM, Mikko wrote:
On 2025-05-26 10:04:02 +0000, Mikko said:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty. >>>>> If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the beginning >>> to end.
You may ask again after you have corrected at least one error that I or
somene else has pointed out.
Disagreeing with verified facts is intolerably dishonest.
On 5/27/2025 5:04 AM, Mikko wrote:
On 2025-05-26 19:42:15 +0000, olcott said:
On 5/26/2025 2:27 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:13 schreef olcott:
On 5/26/2025 2:07 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:01 schreef olcott:
On 5/26/2025 1:55 PM, Fred. Zwarts wrote:I see that it is over your head. But it is simple:
Op 26.mei.2025 om 20:41 schreef olcott:
On 5/26/2025 1:31 PM, Fred. Zwarts wrote:That is what I said. The simulated HHH, specified in the input, does >>>>>>>> abort, so no abort is needed in the simulating HHH.
Op 26.mei.2025 om 18:20 schreef olcott:
On 5/26/2025 11:07 AM, Fred. Zwarts wrote:Apparently this is over your head. That is not what I said. You are >>>>>>>>>> mixing recursion levels.
Op 26.mei.2025 om 17:16 schreef olcott:So you said that the first four instructions of DDD
On 5/26/2025 3:32 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 21:39 schreef olcott:
On 5/25/2025 2:27 PM, Fred. Zwarts wrote:You only ignore it when your failures are shown and start again >>>>>>>>>>>>>> repeating the baseless claims.
Op 25.mei.2025 om 20:42 schreef olcott:
On 5/25/2025 1:07 PM, Fred. Zwarts wrote:
Op 25.mei.2025 om 18:39 schreef olcott:When you are objectively a liar then calling >>>>>>>>>>>>>>>>> you a liar is merely stating the facts.
On 5/25/2025 10:49 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 25.mei.2025 om 16:36 schreef olcott: >>>>>>>>>>>>>>>>>>>>> On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>>>>>>>
So much bad faith and dishonesty shown in this forum that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty.
If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according >>>>>>>>>>>>>>>>>>>>> to the rules of the x86 language cannot possibly reach >>>>>>>>>>>>>>>>>>>>> its own "ret" instruction final halt state. >>>>>>>>>>>>>>>>>>>> Why repeating this bug in HHH?
That everyone that understands these things >>>>>>>>>>>>>>>>>>> sees that there is no bug makes your statement >>>>>>>>>>>>>>>>>>> the kind of reckless disregard for the truth >>>>>>>>>>>>>>>>>>> that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR >>>>>>>>>>>>>>>>>>>
Ad hominem attacks showing lack of counter arguments. >>>>>>>>>>>>>>>>>
Again a baseless ad hominem attack, showing lack of counter arguments.
I dared you to show my mistake your failure to even >>>>>>>>>>>>>>> attempt this sufficiently proves that you are a liar. >>>>>>>>>>>>>>>
Every competent programmer will understand that when the input >>>>>>>>>>>>>> specifies a halting program, including the code to abort and return,
but HHH fails to see that part of the specification, then HHH has a bug.
I know you will ignore it again and reply with only ad hominem attacks.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
HHH needs only one recursion more that the number of recursions in the input.
So, if your HHH has only one recursion, two recursions are needed, >>>>>>>>>>>> except when you change the input, but that is not allowed. >>>>>>>>>>>
are emulated twice and we are at machine address 0000219a. >>>>>>>>>>> So a correct emulator could interpret "call 000015d2"
to mean "jmp 000021a3" ???
The simulated HHH in its first recursion (which is the second recursion
of the simulating HHH) aborts at 0000219a (because we do not change the
input, so the simulated HHH aborts after one cycle). It is programmed
to not execute the call but abort and return. That will make that the
call at 0000219a simulated by the simulating HHH returns and the >>>>>>>>>> simulating HHH will process the next instruction at 0000219f and the >>>>>>>>>> following instructions, up to the 'ret' instruction at 000021a3. >>>>>>>>>> A return from a call is very normal in the x86 language and if you >>>>>>>>>> think that it means that the call is replaced with a jmp instruction,
you show your ignorance of the x86 language.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
unless some HHH aborts its emulation of its DDD
DDD() and HHH() never halt.
Likewise when you are starving to death there is no reason
to get anything to eat because you know that after you eat
you will no longer be starving to death.
If no-one is starving, we do not need to eat. If there is no non-
halting program, there is no need to abort its simulation.
Unless HHH(DDD) aborts its own simulation of DDD
then DDD(), HHH() never halt
Counter-factual. If we keep the input fixed, the simulated HHH aborts
after one cycle.
Every HHH has the exact same machine code.
I.e., there is only one HHH, so saying "every HHH" is pointless.
Each recursive invocation creates another HHH instance
with its own virtual registers, stack and RAM.
On 5/27/2025 5:07 AM, Mikko wrote:
On 2025-05-26 20:02:42 +0000, olcott said:
On 5/26/2025 2:54 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:42 schreef olcott:
On 5/26/2025 2:27 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:13 schreef olcott:
On 5/26/2025 2:07 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:01 schreef olcott:
On 5/26/2025 1:55 PM, Fred. Zwarts wrote:I see that it is over your head. But it is simple:
Op 26.mei.2025 om 20:41 schreef olcott:
On 5/26/2025 1:31 PM, Fred. Zwarts wrote:That is what I said. The simulated HHH, specified in the input, does >>>>>>>>>> abort, so no abort is needed in the simulating HHH.
Op 26.mei.2025 om 18:20 schreef olcott:
On 5/26/2025 11:07 AM, Fred. Zwarts wrote:Apparently this is over your head. That is not what I said. You are
Op 26.mei.2025 om 17:16 schreef olcott:So you said that the first four instructions of DDD
On 5/26/2025 3:32 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 21:39 schreef olcott:
On 5/25/2025 2:27 PM, Fred. Zwarts wrote:You only ignore it when your failures are shown and start again
Op 25.mei.2025 om 20:42 schreef olcott:
On 5/25/2025 1:07 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 25.mei.2025 om 18:39 schreef olcott: >>>>>>>>>>>>>>>>>>>>> On 5/25/2025 10:49 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>>> Op 25.mei.2025 om 16:36 schreef olcott: >>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 1:21 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-05-24 01:20:18 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>>>>>>>>>
When you are objectively a liar then calling >>>>>>>>>>>>>>>>>>> you a liar is merely stating the facts.So much bad faith and dishonesty shown in this forum that myself and PeterEverything here seems to be dishonesty and protests against dishonesty.
Olcott have to fight against. >>>>>>>>>>>>>>>>>>>>>>>>
If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according >>>>>>>>>>>>>>>>>>>>>>> to the rules of the x86 language cannot possibly reach >>>>>>>>>>>>>>>>>>>>>>> its own "ret" instruction final halt state. >>>>>>>>>>>>>>>>>>>>>> Why repeating this bug in HHH?
That everyone that understands these things >>>>>>>>>>>>>>>>>>>>> sees that there is no bug makes your statement >>>>>>>>>>>>>>>>>>>>> the kind of reckless disregard for the truth >>>>>>>>>>>>>>>>>>>>> that loses defamation cases.
In other words by objective standards: YOU ARE A LIAR >>>>>>>>>>>>>>>>>>>>>
Ad hominem attacks showing lack of counter arguments. >>>>>>>>>>>>>>>>>>>
Again a baseless ad hominem attack, showing lack of counter arguments.
I dared you to show my mistake your failure to even >>>>>>>>>>>>>>>>> attempt this sufficiently proves that you are a liar. >>>>>>>>>>>>>>>>>
repeating the baseless claims.
Every competent programmer will understand that when the input >>>>>>>>>>>>>>>> specifies a halting program, including the code to abort and return,
but HHH fails to see that part of the specification, then HHH has a bug.
I know you will ignore it again and reply with only ad hominem attacks.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
HHH needs only one recursion more that the number of recursions in the input.
So, if your HHH has only one recursion, two recursions are needed,
except when you change the input, but that is not allowed. >>>>>>>>>>>>>
are emulated twice and we are at machine address 0000219a. >>>>>>>>>>>>> So a correct emulator could interpret "call 000015d2" >>>>>>>>>>>>> to mean "jmp 000021a3" ???
mixing recursion levels.
The simulated HHH in its first recursion (which is the second recursion
of the simulating HHH) aborts at 0000219a (because we do not change the
input, so the simulated HHH aborts after one cycle). It is programmed
to not execute the call but abort and return. That will make that the
call at 0000219a simulated by the simulating HHH returns and the >>>>>>>>>>>> simulating HHH will process the next instruction at 0000219f and the
following instructions, up to the 'ret' instruction at 000021a3. >>>>>>>>>>>> A return from a call is very normal in the x86 language and if you >>>>>>>>>>>> think that it means that the call is replaced with a jmp instruction,
you show your ignorance of the x86 language.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
unless some HHH aborts its emulation of its DDD
DDD() and HHH() never halt.
Likewise when you are starving to death there is no reason
to get anything to eat because you know that after you eat
you will no longer be starving to death.
If no-one is starving, we do not need to eat. If there is no non- >>>>>>>> halting program, there is no need to abort its simulation.
Unless HHH(DDD) aborts its own simulation of DDD
then DDD(), HHH() never halt
Counter-factual. If we keep the input fixed, the simulated HHH aborts >>>>>> after one cycle.
Every HHH has the exact same machine code.
If the outer HHH waits for the next inner one to abort
then the next inner one waits for its next inner one...
So, you admit that you change the input when you change the simulator.
That is a stupid thing to say that has nothing to do
with recursive emulation.
No, it not. It is am essential part of honest communication, where it
is essential to ensure that the message is correctly understood bofre
any substanatial comment about it is made.
Ben used his change the subject form of
fake rebuttal that wasted 15 years of my
life. Since then I do not tolerate any
change of subject until we get closure on
the current subject.
On 5/27/2025 3:37 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 04:22 schreef olcott:
On 5/26/2025 9:09 PM, Richard Damon wrote:Counter-factual. There is no need to prevent infinite simulation,
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that >>>>>>>>>>> myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against >>>>>>>>>> dishonesty.
If you could remove all dishonesty the protests woud stop, >>>>>>>>>> too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the >>>>>>>> beginning
to end.
I am asking you to affirm that I am correct about this point.
DDD simulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state, thus is correctly rejected as non-halting.
But you have to affirm first that HHH *IS* a program that does
that, and can't be "changed" to some other program, and that DDD
is "completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a fact
that DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
It is a tautology that every input that must be
aborted to prevent the infinite simulation of this
input DOES SPECIFY NON-HALTING BEHAVIOR.
because the input includes DDD with all functions called by DDD,
including the code in Halt7.c that specifies the abort.
Unless the outmost HHH aborts then none of them
abort because they all of the exact same machine code.
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the input
Op 26.mei.2025 om 20:48 schreef olcott:
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:And that is the bug in HHH. It does not go far enough.
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing the >>>>>>>>>>>> decider, but also the input.
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*And you dishonestly left out the part that immediately >>>>>>>>>>>>>>>> follows where he states that you are wrong:
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I >>>>>>>>>>>>>>>>> said a SHD
does above. It tells PO that in the tight loop >>>>>>>>>>>>>>>>> example, H correctly
simulates as far as [A], at which point it correctly >>>>>>>>>>>>>>>>> determines that
"its simulated input would never stop running unless >>>>>>>>>>>>>>>>> aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>> false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>>>>>
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are >>>>>>>>>>>>>>> exactly met
Just for the record:
1) I didn't offer any proofs of /anything/
- I did explain how Sipser's words can be naturally >>>>>>>>>>>>>> interpreted as explaining
how a simulating halt decider can operate. [That is >>>>>>>>>>>>>> not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning >>>>>>>>>>>>> showing how an expression of language is true, this is a >>>>>>>>>>>>> proof.
- I also explained why that explanation *doesn't* apply >>>>>>>>>>>>>> to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets
completely confused even by this simple example.
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
Once you and I work through this one point I may
finally have complete closure.
We are discussing the input where DDD calls a HHH that >>>>>>>>>>>> aborts after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough
No Mike is just wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
No, *you* are just wrong.
A correct simulation needs only one recursion more than the
simulated HHH. The bug in HHH is, that it aborts one cycle too >>>>>>>> early.
The outermost HHH always sees one whole recursive emulation
more than the next inner one.
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails.
My code proves otherwise.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and specifies an abort, so the program specified by the input halts.
But HHH fails to see that. It does not even start to simulate
itself, but aborts at that point. So, it is in no way a proof that
your simulator is able to simulate itself, let alone to simulate
itself correctly.
It is a verified fact that HHH does simulate itself simulating DDD.
If you are too incompetent to understand that this does not count
as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does not
simulate itself, but aborts the simulation at the point where the
simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false assumptions
about itself, in particular it assumes that 'itself' does not halt.
That you do not understand your own code is in no way a rebuttal for
my claim that no simulator is able to simulate itself up to the end.
On 5/26/2025 9:09 PM, Richard Damon wrote:
On 5/26/25 6:05 PM, olcott wrote:*Termination analyzers PREDICT behavior dip-shit* It is a tautology that every input that must be aborted to prevent the infinite simulation of
On 5/26/2025 3:44 PM, Richard Damon wrote:But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:But you have to affirm first that HHH *IS* a program that does that,
On 2025-05-25 14:36:26 +0000, olcott said:I am asking you to affirm that I am correct about this point.
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself >>>>>>>>> and Peter Olcott have to fight against.
Everything here seems to be dishonesty and protests against
dishonesty.
If you could remove all dishonesty the protests woud stop, too, >>>>>>>> and nothing would be left.
_DDD()
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 [0000219a]
e833f4ffff call 000015d2 // call HHH [0000219f]
83c404 add esp,+04 [000021a2] 5d pop ebp
[000021a3] c3 ret Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according to the rules >>>>>>> of the x86 language cannot possibly reach its own "ret"
instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the
beginning to end.
DDD simulated by HHH according to the rules of the x86 language
cannot possibly reach its own "ret" instruction final halt state,
thus is correctly rejected as non-halting.
and can't be "changed" to some other program, and that DDD is
"completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then DDD() and HHH() never
stop running proving that the input to HHH(DDD) SPECIFIES
NON-TERMINATING BEHAVIOR THAT MUST BE ABORTED.
DDD() will halt.
this input DOES SPECIFY NON-HALTING BEHAVIOR.
“My SHD detects that the program (e.g., `DDD()`) has an *infiniterecursion structure* and therefore halts early with a decision: non- halting.”
There exists no algorithm that, fo
On 5/28/2025 3:35 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 17:31 schreef olcott:
On 5/27/2025 3:37 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 04:22 schreef olcott:
On 5/26/2025 9:09 PM, Richard Damon wrote:Counter-factual. There is no need to prevent infinite simulation,
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that >>>>>>>>>>>>> myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against >>>>>>>>>>>> dishonesty.
If you could remove all dishonesty the protests woud stop, >>>>>>>>>>>> too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from >>>>>>>>>> the beginning
to end.
I am asking you to affirm that I am correct about this point. >>>>>>>>> DDD simulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state, thus is correctly rejected as non-halting. >>>>>>>>>
But you have to affirm first that HHH *IS* a program that does >>>>>>>> that, and can't be "changed" to some other program, and that DDD >>>>>>>> is "completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a fact
that DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
It is a tautology that every input that must be
aborted to prevent the infinite simulation of this
input DOES SPECIFY NON-HALTING BEHAVIOR.
because the input includes DDD with all functions called by DDD,
including the code in Halt7.c that specifies the abort.
Unless the outmost HHH aborts then none of them
abort because they all of the exact same machine code.
Only when you also change the input. Changing input from a HHH that
aborts to a HHH that does not abort is changing the subject.
It either every HHH aborts or no HHH aborts
because they all have the same machine code.
Simulating Termination analyzers must PREDICT
non-terminating behavior, thus are inherently
required to report on what the behavior would be.
To require a STA to report on the actual behavior
of a non-terminating input is to require them to
never report. This is not allowed.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations.
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the
Op 26.mei.2025 om 20:48 schreef olcott:
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:And that is the bug in HHH. It does not go far enough.
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing the >>>>>>>>>>>>>> decider, but also the input.
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I >>>>>>>>>>>>>>>>>>> said a SHD
does above. It tells PO that in the tight loop >>>>>>>>>>>>>>>>>>> example, H correctly
simulates as far as [A], at which point it correctly >>>>>>>>>>>>>>>>>>> determines that
"its simulated input would never stop running unless >>>>>>>>>>>>>>>>>>> aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>> false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- >>>>>>>>>>>>>>>>>>> email.me%3E
And you dishonestly left out the part that immediately >>>>>>>>>>>>>>>>>> follows where he states that you are wrong: >>>>>>>>>>>>>>>>>>
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to >>>>>>>>>>>>>>>>> are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/
- I did explain how Sipser's words can be naturally >>>>>>>>>>>>>>>> interpreted as explaining
how a simulating halt decider can operate. [That is >>>>>>>>>>>>>>>> not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning >>>>>>>>>>>>>>> showing how an expression of language is true, this is a >>>>>>>>>>>>>>> proof.
- I also explained why that explanation *doesn't* apply >>>>>>>>>>>>>>>> to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
Once you and I work through this one point I may >>>>>>>>>>>>>>> finally have complete closure.
We are discussing the input where DDD calls a HHH that >>>>>>>>>>>>>> aborts after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough
No Mike is just wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
No, *you* are just wrong.
A correct simulation needs only one recursion more than the >>>>>>>>>> simulated HHH. The bug in HHH is, that it aborts one cycle too >>>>>>>>>> early.
The outermost HHH always sees one whole recursive emulation
more than the next inner one.
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails.
My code proves otherwise.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
input and specifies an abort, so the program specified by the
input halts. But HHH fails to see that. It does not even start to
simulate itself, but aborts at that point. So, it is in no way a
proof that your simulator is able to simulate itself, let alone to >>>>>> simulate itself correctly.
It is a verified fact that HHH does simulate itself simulating DDD.
If you are too incompetent to understand that this does not count
as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does not
simulate itself, but aborts the simulation at the point where the
simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false assumptions
about itself, in particular it assumes that 'itself' does not halt.
That you do not understand your own code is in no way a rebuttal for
my claim that no simulator is able to simulate itself up to the end.
It seems you do not even understand what 'counter-factual' means. Your
own traces show that the simulation is aborted without simulating the
call instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD.
We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by 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 Local Halt Decider: Infinite Recursion Detected Simulation Stopped
On 5/28/2025 1:23 PM, Mr Flibble wrote:And nobody requires otherwise. But the input to HHH is a pointer to DDD.
On Mon, 26 May 2025 21:22:55 -0500, olcott wrote:
On 5/26/2025 9:09 PM, Richard Damon wrote:
On 5/26/25 6:05 PM, olcott wrote:*Termination analyzers PREDICT behavior dip-shit* It is a tautology that >>> every input that must be aborted to prevent the infinite simulation of
On 5/26/2025 3:44 PM, Richard Damon wrote:But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:But you have to affirm first that HHH *IS* a program that does that, >>>>>> and can't be "changed" to some other program, and that DDD is
On 2025-05-25 14:36:26 +0000, olcott said:I am asking you to affirm that I am correct about this point.
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself >>>>>>>>>>> and Peter Olcott have to fight against.
Everything here seems to be dishonesty and protests against >>>>>>>>>> dishonesty.
If you could remove all dishonesty the protests woud stop, too, >>>>>>>>>> and nothing would be left.
_DDD()
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 [0000219a] >>>>>>>>> e833f4ffff call 000015d2 // call HHH [0000219f]
83c404 add esp,+04 [000021a2] 5d pop ebp
[000021a3] c3 ret Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according to the rules >>>>>>>>> of the x86 language cannot possibly reach its own "ret"
instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the >>>>>>>> beginning to end.
DDD simulated by HHH according to the rules of the x86 language
cannot possibly reach its own "ret" instruction final halt state, >>>>>>> thus is correctly rejected as non-halting.
"completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then DDD() and HHH() never >>>>> stop running proving that the input to HHH(DDD) SPECIFIES
NON-TERMINATING BEHAVIOR THAT MUST BE ABORTED.
DDD() will halt.
this input DOES SPECIFY NON-HALTING BEHAVIOR.
Olcott is claiming:
“My SHD detects that the program (e.g., `DDD()`) has an *infiniterecursion structure* and therefore halts early with a decision: non-
halting.”
This would mean:
* SHD *does not simulate* the entire execution.
* Instead, it performs **analysis** (akin to symbolic execution, static
control flow, or syntactic pattern detection).
* It concludes **before execution completes** that the input program will
never halt.
This now resembles modern **termination analyzers** used in:
* Formal methods (e.g., Coq, Agda)
* CompCert (verified C compiler)
* Model checking and static analysis tools
---
### 🔍 What This Means
1. **SHD becomes a partial analyzer.**
* It is no longer a classical halt decider (which must be total).
* It becomes a **sound** (never wrongly claims halting) but
**incomplete** (may fail to decide in some cases) analyzer.
2. **Detection ≠ Simulation**
* Damon’s original critique presumes SHD reaches a contradiction
through simulation.
* But if SHD performs structural detection of recursive constructs
(e.g., unguarded self-calls), it’s operating at the **language or AST
level**, not the runtime level.
3. **Olcott's Argument Gets Stronger**
* If SHD statically proves a path leads to infinite recursion, then >> halting early is valid.
* This kind of structural non-termination detection is used in many >> safe languages and compilers.
---
### ⚖️ Remaining Limitations
However, the halting problem in its classical sense is **not about some
programs** — it is about **all** programs:
There exists no algorithm that, for every program $P$ and input $x$,decides whether $P(x)$ halts.
Olcott’s SHD does **not** refute this proof, because:
* SHD avoids the contradiction **by not accepting certain inputs** (i.e.,
pathological ones like `DDD()`).
* This is not a **refutation**, but a **domain restriction** — similar to >> how total languages avoid undecidability by design.
---
### ✅ Summary
| Topic | Classical View | Olcott’s
SHD |
| ---------------- | ------------------------------------ |
------------------------------------------- |
| Simulation | Required to define behavior | Avoided via
structural detection |
| Decider behavior | Total — must decide for all programs | Partial —
only
works on analyzable inputs |
| DDD self-call | Causes contradiction in proof | Detected as
infinite by SHD, then rejected |
| Result | Proof of undecidability holds | SHD reframes
the problem, doesn't refute it |
---
### 🧩 Final Assessment
**If Olcott’s SHD uses static analysis to detect infinite recursion**,it behaves like modern verification tools and total language analyzers — >> which are **sound** but **incomplete**.
That’s valid and **useful** — but it does **not refute the Halting
Problem
proof**. It sidesteps the contradiction **by changing the semantics** of
what inputs are allowed and how decisions are made.
So, Olcott’s SHD is **not wrong**, but its scope is misunderstood: it’s a
*partial, structural halting predictor*, not a general refutation of
undecidability.
My only aim is to show that the conventional halting
problem proof is wrong.
When HHH is required to report on the behavior that
its input actually specifies then the counter-example
input to the Halting Problem proofs is correctly
rejected as non-halting.
When HHH is required to report on behavior
OTHER THAN THE BEHAVIOR THAT ITS INPUT ACTUAL SPECIFIES
then the requirement is incorrect.
On 5/28/2025 2:38 PM, olcott wrote:
My only aim is to show that the conventional halting
problem proof is wrong.
But why would you care whether or not the proof is wrong when
you've gone on record (multiple times) as stating that what the
proof proves is correct?
Op 28.mei.2025 om 17:02 schreef olcott:
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:Counter-factual, nitwit.
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the input and specifies an abort,
Op 26.mei.2025 om 20:48 schreef olcott:
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:No Mike is just wrong.
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:And that is the bug in HHH. It does not go far enough. >>>>>>>>>>>>
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing the decider, but also the input.
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>> --------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>>> false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>> https://al.howardknight.net/? STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-
email.me%3E
And you dishonestly left out the part that immediately follows where he states
that you are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/
- I did explain how Sipser's words can be naturally interpreted as explaining
how a simulating halt decider can operate. [That is not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning >>>>>>>>>>>>>>>> showing how an expression of language is true, this is a proof.
- I also explained why that explanation *doesn't* apply to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>>
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>> wait before its emulated DDD magically halts
on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>
Once you and I work through this one point I may >>>>>>>>>>>>>>>> finally have complete closure.
We are discussing the input where DDD calls a HHH that aborts after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
No, *you* are just wrong.
A correct simulation needs only one recursion more than the simulated HHH. The bug in HHH
is, that it aborts one cycle too early.
The outermost HHH always sees one whole recursive emulation >>>>>>>>>> more than the next inner one.
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails.
My code proves otherwise.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
so the program specified by the input halts. But HHH fails to see that. It does not even
start to simulate itself, but aborts at that point. So, it is in no way a proof that your
simulator is able to simulate itself, let alone to simulate itself correctly.
It is a verified fact that HHH does simulate itself simulating DDD. >>>>>> If you are too incompetent to understand that this does not count
as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does not simulate itself, but aborts
the simulation at the point where the simulation of itself should start. >>>>
It does not simulate itself, but only makes some false assumptions about itself, in particular
it assumes that 'itself' does not halt.
That you do not understand your own code is in no way a rebuttal for my claim that no simulator
is able to simulate itself up to the end.
It seems you do not even understand what 'counter-factual' means. Your own traces show that the
simulation is aborted without simulating the call instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD.
We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by 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
You see? The call is not properly simulated. Otherwise the next instruction would be at 000015ee.
Now it starts a new slave stack and misses all the conditional jump instructions inside the
simulated 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
Again the same error.
[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
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
You see? HHH does not properly simulate itself. Because it missed all the conditional branch
instructions in the simulation of itself, an infinite recursion is assumed. This bug makes that it > aborts before it can see that there is only a finite recursion, after which the simulated HHH would
abort and return.
On Mon, 26 May 2025 21:22:55 -0500, olcott wrote:
On 5/26/2025 9:09 PM, Richard Damon wrote:
On 5/26/25 6:05 PM, olcott wrote:*Termination analyzers PREDICT behavior dip-shit* It is a tautology that
On 5/26/2025 3:44 PM, Richard Damon wrote:But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:But you have to affirm first that HHH *IS* a program that does that, >>>>> and can't be "changed" to some other program, and that DDD is
On 2025-05-25 14:36:26 +0000, olcott said:I am asking you to affirm that I am correct about this point.
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself >>>>>>>>>> and Peter Olcott have to fight against.
Everything here seems to be dishonesty and protests against
dishonesty.
If you could remove all dishonesty the protests woud stop, too, >>>>>>>>> and nothing would be left.
_DDD()
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 [0000219a] >>>>>>>> e833f4ffff call 000015d2 // call HHH [0000219f]
83c404 add esp,+04 [000021a2] 5d pop ebp
[000021a3] c3 ret Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according to the rules >>>>>>>> of the x86 language cannot possibly reach its own "ret"
instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the
beginning to end.
DDD simulated by HHH according to the rules of the x86 language
cannot possibly reach its own "ret" instruction final halt state,
thus is correctly rejected as non-halting.
"completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then DDD() and HHH() never >>>> stop running proving that the input to HHH(DDD) SPECIFIES
NON-TERMINATING BEHAVIOR THAT MUST BE ABORTED.
DDD() will halt.
every input that must be aborted to prevent the infinite simulation of
this input DOES SPECIFY NON-HALTING BEHAVIOR.
Olcott is claiming:
“My SHD detects that the program (e.g., `DDD()`) has an *infiniterecursion structure* and therefore halts early with a decision: non- halting.”
This would mean:
* SHD *does not simulate* the entire execution.
* Instead, it performs **analysis** (akin to symbolic execution, static control flow, or syntactic pattern detection).
* It concludes **before execution completes** that the input program will never halt.
This now resembles modern **termination analyzers** used in:
* Formal methods (e.g., Coq, Agda)
* CompCert (verified C compiler)
* Model checking and static analysis tools
---
### 🔍 What This Means
1. **SHD becomes a partial analyzer.**
* It is no longer a classical halt decider (which must be total).
* It becomes a **sound** (never wrongly claims halting) but **incomplete** (may fail to decide in some cases) analyzer.
2. **Detection ≠ Simulation**
* Damon’s original critique presumes SHD reaches a contradiction through simulation.
* But if SHD performs structural detection of recursive constructs
(e.g., unguarded self-calls), it’s operating at the **language or AST level**, not the runtime level.
3. **Olcott's Argument Gets Stronger**
* If SHD statically proves a path leads to infinite recursion, then halting early is valid.
* This kind of structural non-termination detection is used in many
safe languages and compilers.
Op 27.mei.2025 om 17:31 schreef olcott:
On 5/27/2025 3:37 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 04:22 schreef olcott:
On 5/26/2025 9:09 PM, Richard Damon wrote:Counter-factual. There is no need to prevent infinite simulation,
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty.
If you could remove all dishonesty the protests woud stop, too, and >>>>>>>>>>> nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the beginning
to end.
I am asking you to affirm that I am correct about this point.
DDD simulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state, thus is correctly rejected as non-halting.
But you have to affirm first that HHH *IS* a program that does that, >>>>>>> and can't be "changed" to some other program, and that DDD is
"completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that >>>>> DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
It is a tautology that every input that must be
aborted to prevent the infinite simulation of this
input DOES SPECIFY NON-HALTING BEHAVIOR.
because the input includes DDD with all functions called by DDD,
including the code in Halt7.c that specifies the abort.
Unless the outmost HHH aborts then none of them
abort because they all of the exact same machine code.
Only when you also change the input. Changing input from a HHH that
aborts to a HHH that does not abort is changing the subject.
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the input >>>>>> and specifies an abort, so the program specified by the input halts. >>>>>> But HHH fails to see that. It does not even start to simulate itself, >>>>>> but aborts at that point. So, it is in no way a proof that your
Op 26.mei.2025 om 20:48 schreef olcott:
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:The outermost HHH always sees one whole recursive emulation
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:And that is the bug in HHH. It does not go far enough.
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing the decider, but
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*And you dishonestly left out the part that immediately follows where he
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>> false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- email.me%3E >>>>>>>>>>>>>>>>>>
states that you are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/
- I did explain how Sipser's words can be naturally interpreted as explaining
how a simulating halt decider can operate. [That is not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning >>>>>>>>>>>>>>> showing how an expression of language is true, this is a proof. >>>>>>>>>>>>>>>
- I also explained why that explanation *doesn't* apply to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
Once you and I work through this one point I may >>>>>>>>>>>>>>> finally have complete closure.
also the input.
We are discussing the input where DDD calls a HHH that aborts after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough
No Mike is just wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
No, *you* are just wrong.
A correct simulation needs only one recursion more than the simulated
HHH. The bug in HHH is, that it aborts one cycle too early. >>>>>>>>>
more than the next inner one.
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails.
My code proves otherwise.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
simulator is able to simulate itself, let alone to simulate itself >>>>>> correctly.
It is a verified fact that HHH does simulate itself simulating DDD.
If you are too incompetent to understand that this does not count
as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does not
simulate itself, but aborts the simulation at the point where the
simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false assumptions
about itself, in particular it assumes that 'itself' does not halt.
That you do not understand your own code is in no way a rebuttal for my >>>> claim that no simulator is able to simulate itself up to the end.
It seems you do not even understand what 'counter-factual' means. Your
own traces show that the simulation is aborted without simulating the
call instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD.
We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by 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
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
On 5/28/2025 1:54 PM, Fred. Zwarts wrote:
Op 28.mei.2025 om 17:02 schreef olcott:
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:You see? The call is not properly simulated.
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the input >>>>>>>> and specifies an abort, so the program specified by the input halts. >>>>>>>> But HHH fails to see that. It does not even start to simulate itself, >>>>>>>> but aborts at that point. So, it is in no way a proof that your >>>>>>>> simulator is able to simulate itself, let alone to simulate itself >>>>>>>> correctly.
Op 26.mei.2025 om 20:48 schreef olcott:
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:The outermost HHH always sees one whole recursive emulation >>>>>>>>>>> more than the next inner one.
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:No Mike is just wrong.
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:And that is the bug in HHH. It does not go far enough. >>>>>>>>>>>>>
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing the decider, but
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>> --------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>>>> false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>> https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- email.me%3E
And you dishonestly left out the part that immediately follows where he
states that you are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/ >>>>>>>>>>>>>>>>>>
- I did explain how Sipser's words can be naturally interpreted as explaining
how a simulating halt decider can operate. [That is not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning >>>>>>>>>>>>>>>>> showing how an expression of language is true, this is a proof.
- I also explained why that explanation *doesn't* apply to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>> [000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>>>
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>
Once you and I work through this one point I may >>>>>>>>>>>>>>>>> finally have complete closure.
also the input.
We are discussing the input where DDD calls a HHH that aborts after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
No, *you* are just wrong.
A correct simulation needs only one recursion more than the simulated
HHH. The bug in HHH is, that it aborts one cycle too early. >>>>>>>>>>>
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails.
My code proves otherwise.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
It is a verified fact that HHH does simulate itself simulating DDD. >>>>>>> If you are too incompetent to understand that this does not count >>>>>>> as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does not >>>>>> simulate itself, but aborts the simulation at the point where the
simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false assumptions >>>>>> about itself, in particular it assumes that 'itself' does not halt. >>>>>> That you do not understand your own code is in no way a rebuttal for my >>>>>> claim that no simulator is able to simulate itself up to the end.
It seems you do not even understand what 'counter-factual' means. Your >>>> own traces show that the simulation is aborted without simulating the
call instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD.
We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by 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 >>
No stupid you are wrong.
I prove that HHH is simulating itself simulating DDD
by the next lines of the correctly simulated DDD.
On 5/28/2025 3:35 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 17:31 schreef olcott:
On 5/27/2025 3:37 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 04:22 schreef olcott:
On 5/26/2025 9:09 PM, Richard Damon wrote:Counter-factual. There is no need to prevent infinite simulation,
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that >>>>>>>>>>>>> myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against >>>>>>>>>>>> dishonesty.
If you could remove all dishonesty the protests woud stop, >>>>>>>>>>>> too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from >>>>>>>>>> the beginning
to end.
I am asking you to affirm that I am correct about this point. >>>>>>>>> DDD simulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state, thus is correctly rejected as non-halting. >>>>>>>>>
But you have to affirm first that HHH *IS* a program that does >>>>>>>> that, and can't be "changed" to some other program, and that DDD >>>>>>>> is "completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a fact
that DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
It is a tautology that every input that must be
aborted to prevent the infinite simulation of this
input DOES SPECIFY NON-HALTING BEHAVIOR.
because the input includes DDD with all functions called by DDD,
including the code in Halt7.c that specifies the abort.
Unless the outmost HHH aborts then none of them
abort because they all of the exact same machine code.
Only when you also change the input. Changing input from a HHH that
aborts to a HHH that does not abort is changing the subject.
It either every HHH aborts or no HHH aborts
because they all have the same machine code.
Simulating Termination analyzers must PREDICT
non-terminating behavior, thus are inherently
required to report on what the behavior would be.
To require a STA to report on the actual behavior
of a non-terminating input is to require them to
never report. This is not allowed.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations.
On Mon, 26 May 2025 21:22:55 -0500, olcott wrote:
On 5/26/2025 9:09 PM, Richard Damon wrote:
On 5/26/25 6:05 PM, olcott wrote:*Termination analyzers PREDICT behavior dip-shit* It is a tautology that
On 5/26/2025 3:44 PM, Richard Damon wrote:But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:But you have to affirm first that HHH *IS* a program that does that, >>>>> and can't be "changed" to some other program, and that DDD is
On 2025-05-25 14:36:26 +0000, olcott said:I am asking you to affirm that I am correct about this point.
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself >>>>>>>>>> and Peter Olcott have to fight against.
Everything here seems to be dishonesty and protests against
dishonesty.
If you could remove all dishonesty the protests woud stop, too, >>>>>>>>> and nothing would be left.
_DDD()
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 [0000219a] >>>>>>>> e833f4ffff call 000015d2 // call HHH [0000219f]
83c404 add esp,+04 [000021a2] 5d pop ebp
[000021a3] c3 ret Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according to the rules >>>>>>>> of the x86 language cannot possibly reach its own "ret"
instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the
beginning to end.
DDD simulated by HHH according to the rules of the x86 language
cannot possibly reach its own "ret" instruction final halt state,
thus is correctly rejected as non-halting.
"completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then DDD() and HHH() never >>>> stop running proving that the input to HHH(DDD) SPECIFIES
NON-TERMINATING BEHAVIOR THAT MUST BE ABORTED.
DDD() will halt.
every input that must be aborted to prevent the infinite simulation of
this input DOES SPECIFY NON-HALTING BEHAVIOR.
Olcott is claiming:
“My SHD detects that the program (e.g., `DDD()`) has an *infiniterecursion structure* and therefore halts early with a decision: non- halting.”
This would mean:
* SHD *does not simulate* the entire execution.
* Instead, it performs **analysis** (akin to symbolic execution, static control flow, or syntactic pattern detection).
* It concludes **before execution completes** that the input program will never halt.
This now resembles modern **termination analyzers** used in:
* Formal methods (e.g., Coq, Agda)
* CompCert (verified C compiler)
* Model checking and static analysis tools
---
### 🔍 What This Means
1. **SHD becomes a partial analyzer.**
* It is no longer a classical halt decider (which must be total).
* It becomes a **sound** (never wrongly claims halting) but **incomplete** (may fail to decide in some cases) analyzer.
2. **Detection ≠ Simulation**
* Damon’s original critique presumes SHD reaches a contradiction through simulation.
* But if SHD performs structural detection of recursive constructs
(e.g., unguarded self-calls), it’s operating at the **language or AST level**, not the runtime level.
3. **Olcott's Argument Gets Stronger**
* If SHD statically proves a path leads to infinite recursion, then halting early is valid.
* This kind of structural non-termination detection is used in many
safe languages and compilers.
---
### ⚖️ Remaining Limitations
However, the halting problem in its classical sense is **not about some programs** — it is about **all** programs:
There exists no algorithm that, for every program $P$ and input $x$,decides whether $P(x)$ halts.
Olcott’s SHD does **not** refute this proof, because:
* SHD avoids the contradiction **by not accepting certain inputs** (i.e., pathological ones like `DDD()`).
* This is not a **refutation**, but a **domain restriction** — similar to how total languages avoid undecidability by design.
---
### ✅ Summary
| Topic | Classical View | Olcott’s
SHD |
| ---------------- | ------------------------------------ | ------------------------------------------- |
| Simulation | Required to define behavior | Avoided via structural detection |
| Decider behavior | Total — must decide for all programs | Partial — only
works on analyzable inputs |
| DDD self-call | Causes contradiction in proof | Detected as infinite by SHD, then rejected |
| Result | Proof of undecidability holds | SHD reframes
the problem, doesn't refute it |
---
### 🧩 Final Assessment
**If Olcott’s SHD uses static analysis to detect infinite recursion**,it behaves like modern verification tools and total language analyzers — which are **sound** but **incomplete**.
That’s valid and **useful** — but it does **not refute the Halting Problem
proof**. It sidesteps the contradiction **by changing the semantics** of
what inputs are allowed and how decisions are made.
So, Olcott’s SHD is **not wrong**, but its scope is misunderstood: it’s a *partial, structural halting predictor*, not a general refutation of undecidability.
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the
Op 26.mei.2025 om 20:48 schreef olcott:
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:And that is the bug in HHH. It does not go far enough.
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing the >>>>>>>>>>>>>> decider, but also the input.
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote:
*Mike understood this perfectly*
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I >>>>>>>>>>>>>>>>>>> said a SHD
does above. It tells PO that in the tight loop >>>>>>>>>>>>>>>>>>> example, H correctly
simulates as far as [A], at which point it correctly >>>>>>>>>>>>>>>>>>> determines that
"its simulated input would never stop running unless >>>>>>>>>>>>>>>>>>> aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>> false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- >>>>>>>>>>>>>>>>>>> email.me%3E
And you dishonestly left out the part that immediately >>>>>>>>>>>>>>>>>> follows where he states that you are wrong: >>>>>>>>>>>>>>>>>>
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to >>>>>>>>>>>>>>>>> are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/
- I did explain how Sipser's words can be naturally >>>>>>>>>>>>>>>> interpreted as explaining
how a simulating halt decider can operate. [That is >>>>>>>>>>>>>>>> not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning >>>>>>>>>>>>>>> showing how an expression of language is true, this is a >>>>>>>>>>>>>>> proof.
- I also explained why that explanation *doesn't* apply >>>>>>>>>>>>>>>> to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
Once you and I work through this one point I may >>>>>>>>>>>>>>> finally have complete closure.
We are discussing the input where DDD calls a HHH that >>>>>>>>>>>>>> aborts after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough
No Mike is just wrong.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
No, *you* are just wrong.
A correct simulation needs only one recursion more than the >>>>>>>>>> simulated HHH. The bug in HHH is, that it aborts one cycle too >>>>>>>>>> early.
The outermost HHH always sees one whole recursive emulation
more than the next inner one.
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails.
My code proves otherwise.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
input and specifies an abort, so the program specified by the
input halts. But HHH fails to see that. It does not even start to
simulate itself, but aborts at that point. So, it is in no way a
proof that your simulator is able to simulate itself, let alone to >>>>>> simulate itself correctly.
It is a verified fact that HHH does simulate itself simulating DDD.
If you are too incompetent to understand that this does not count
as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does not
simulate itself, but aborts the simulation at the point where the
simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false assumptions
about itself, in particular it assumes that 'itself' does not halt.
That you do not understand your own code is in no way a rebuttal for
my claim that no simulator is able to simulate itself up to the end.
It seems you do not even understand what 'counter-factual' means. Your
own traces show that the simulation is aborted without simulating the
call instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD.
We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by 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 Local Halt Decider: Infinite Recursion Detected Simulation Stopped
These are verifiable facts. So we see that you do not understand the
meaning of 'counter-factual'.
On 5/28/2025 1:23 PM, Mr Flibble wrote:
On Mon, 26 May 2025 21:22:55 -0500, olcott wrote:
On 5/26/2025 9:09 PM, Richard Damon wrote:
On 5/26/25 6:05 PM, olcott wrote:*Termination analyzers PREDICT behavior dip-shit* It is a tautology that >>> every input that must be aborted to prevent the infinite simulation of
On 5/26/2025 3:44 PM, Richard Damon wrote:But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:But you have to affirm first that HHH *IS* a program that does that, >>>>>> and can't be "changed" to some other program, and that DDD is
On 2025-05-25 14:36:26 +0000, olcott said:I am asking you to affirm that I am correct about this point.
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself >>>>>>>>>>> and Peter Olcott have to fight against.
Everything here seems to be dishonesty and protests against >>>>>>>>>> dishonesty.
If you could remove all dishonesty the protests woud stop, too, >>>>>>>>>> and nothing would be left.
_DDD()
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 [0000219a] >>>>>>>>> e833f4ffff call 000015d2 // call HHH [0000219f]
83c404 add esp,+04 [000021a2] 5d pop ebp
[000021a3] c3 ret Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according to the rules >>>>>>>>> of the x86 language cannot possibly reach its own "ret"
instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the >>>>>>>> beginning to end.
DDD simulated by HHH according to the rules of the x86 language
cannot possibly reach its own "ret" instruction final halt state, >>>>>>> thus is correctly rejected as non-halting.
"completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then DDD() and HHH() never >>>>> stop running proving that the input to HHH(DDD) SPECIFIES
NON-TERMINATING BEHAVIOR THAT MUST BE ABORTED.
DDD() will halt.
this input DOES SPECIFY NON-HALTING BEHAVIOR.
Olcott is claiming:
“My SHD detects that the program (e.g., `DDD()`) has an *infiniterecursion structure* and therefore halts early with a decision: non-
halting.”
This would mean:
* SHD *does not simulate* the entire execution.
* Instead, it performs **analysis** (akin to symbolic execution, static
control flow, or syntactic pattern detection).
* It concludes **before execution completes** that the input program will
never halt.
This now resembles modern **termination analyzers** used in:
* Formal methods (e.g., Coq, Agda)
* CompCert (verified C compiler)
* Model checking and static analysis tools
---
### 🔍 What This Means
1. **SHD becomes a partial analyzer.**
* It is no longer a classical halt decider (which must be total).
* It becomes a **sound** (never wrongly claims halting) but
**incomplete** (may fail to decide in some cases) analyzer.
2. **Detection ≠ Simulation**
* Damon’s original critique presumes SHD reaches a contradiction
through simulation.
* But if SHD performs structural detection of recursive constructs
(e.g., unguarded self-calls), it’s operating at the **language or AST
level**, not the runtime level.
3. **Olcott's Argument Gets Stronger**
* If SHD statically proves a path leads to infinite recursion, then >> halting early is valid.
* This kind of structural non-termination detection is used in many >> safe languages and compilers.
---
### ⚖️ Remaining Limitations
However, the halting problem in its classical sense is **not about some
programs** — it is about **all** programs:
There exists no algorithm that, for every program $P$ and input $x$,decides whether $P(x)$ halts.
Olcott’s SHD does **not** refute this proof, because:
* SHD avoids the contradiction **by not accepting certain inputs** (i.e.,
pathological ones like `DDD()`).
* This is not a **refutation**, but a **domain restriction** — similar to >> how total languages avoid undecidability by design.
---
### ✅ Summary
| Topic | Classical View | Olcott’s
SHD |
| ---------------- | ------------------------------------ |
------------------------------------------- |
| Simulation | Required to define behavior | Avoided via
structural detection |
| Decider behavior | Total — must decide for all programs | Partial —
only
works on analyzable inputs |
| DDD self-call | Causes contradiction in proof | Detected as
infinite by SHD, then rejected |
| Result | Proof of undecidability holds | SHD reframes
the problem, doesn't refute it |
---
### 🧩 Final Assessment
**If Olcott’s SHD uses static analysis to detect infinite recursion**,it behaves like modern verification tools and total language analyzers — >> which are **sound** but **incomplete**.
That’s valid and **useful** — but it does **not refute the Halting
Problem
proof**. It sidesteps the contradiction **by changing the semantics** of
what inputs are allowed and how decisions are made.
So, Olcott’s SHD is **not wrong**, but its scope is misunderstood: it’s a
*partial, structural halting predictor*, not a general refutation of
undecidability.
My only aim is to show that the conventional halting
problem proof is wrong.
When HHH is required to report on the behavior that
its input actually specifies then the counter-example
input to the Halting Problem proofs is correctly
rejected as non-halting.
When HHH is required to report on behavior
OTHER THAN THE BEHAVIOR THAT ITS INPUT ACTUAL SPECIFIES
then the requirement is incorrect.
On 5/28/2025 8:02 PM, Mike Terry wrote:
On 28/05/2025 19:54, Fred. Zwarts wrote:
Op 28.mei.2025 om 17:02 schreef olcott:
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the >>>>>>>>> input and specifies an abort, so the program specified by the >>>>>>>>> input halts. But HHH fails to see that. It does not even start >>>>>>>>> to simulate itself, but aborts at that point. So, it is in no >>>>>>>>> way a proof that your simulator is able to simulate itself, let >>>>>>>>> alone to simulate itself correctly.
Op 26.mei.2025 om 20:48 schreef olcott:
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:No Mike is just wrong.
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:And that is the bug in HHH. It does not go far enough. >>>>>>>>>>>>>>
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote:Again you make the same mistake by not only changing >>>>>>>>>>>>>>>>> the decider, but also the input.
On 25/05/2025 21:30, olcott wrote:
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>> *Mike understood this perfectly*
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>> --------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly >>>>>>>>>>>>>>>>>>>>>> what I said a SHD
does above. It tells PO that in the tight loop >>>>>>>>>>>>>>>>>>>>>> example, H correctly
simulates as far as [A], at which point it >>>>>>>>>>>>>>>>>>>>>> correctly determines that
"its simulated input would never stop running >>>>>>>>>>>>>>>>>>>>>> unless aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>>>>> false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>> https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- >>>>>>>>>>>>>>>>>>>>>> email.me%3E
And you dishonestly left out the part that >>>>>>>>>>>>>>>>>>>>> immediately follows where he states that you are >>>>>>>>>>>>>>>>>>>>> wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to >>>>>>>>>>>>>>>>>>>> are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/ >>>>>>>>>>>>>>>>>>>
- I did explain how Sipser's words can be naturally >>>>>>>>>>>>>>>>>>> interpreted as explaining
how a simulating halt decider can operate. [That >>>>>>>>>>>>>>>>>>> is not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct >>>>>>>>>>>>>>>>>> reasoning
showing how an expression of language is true, this is >>>>>>>>>>>>>>>>>> a proof.
- I also explained why that explanation *doesn't* >>>>>>>>>>>>>>>>>>> apply to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>> [000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>>>>
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>
Once you and I work through this one point I may >>>>>>>>>>>>>>>>>> finally have complete closure.
We are discussing the input where DDD calls a HHH that >>>>>>>>>>>>>>>>> aborts after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
No, *you* are just wrong.
A correct simulation needs only one recursion more than the >>>>>>>>>>>>> simulated HHH. The bug in HHH is, that it aborts one cycle >>>>>>>>>>>>> too early.
The outermost HHH always sees one whole recursive emulation >>>>>>>>>>>> more than the next inner one.
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails.
My code proves otherwise.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
It is a verified fact that HHH does simulate itself simulating DDD. >>>>>>>> If you are too incompetent to understand that this does not count >>>>>>>> as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does
not simulate itself, but aborts the simulation at the point where >>>>>>> the simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false
assumptions about itself, in particular it assumes that 'itself' >>>>>>> does not halt.
That you do not understand your own code is in no way a rebuttal >>>>>>> for my claim that no simulator is able to simulate itself up to
the end.
It seems you do not even understand what 'counter-factual' means.
Your own traces show that the simulation is aborted without
simulating the call instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD.
We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by 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
You see? The call is not properly simulated. Otherwise the next
instruction would be at 000015ee. Now it starts a new slave stack and
misses all the conditional jump instructions inside the simulated HHH.
Perhaps you slightly misunderstand the presented trace. The
instructions starting at 000015ee /are/ simulated, but then simply
suppressed from the output PO shows. No reason you should realise
that, since PO forgets to explain such details!
More relevantly the simulated instructions of HHH are /also/
suppressed from HHH's global trace table, which is used by HHH's HD
logic, so you're right that the conditional branch instructions are
missed by the abort logic in HHH, and your conclusion is correct.
*The question being answered makes that moot*
<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
It is a tautology that any input D to termination
analyzer H that *would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR
HHH cannot wait for itself to abort its input later on
because every HHH has the exact same machine code, thus
the wait would be forever.
For background: There are two "traces" involved:
1. The x86utm.exe "output trace". This is x86utm's log file, and
contains the record of the x86 instructions x86utm "executes",
including main(). EXCEPT instructions from HHH and below are
suppressed, although they /are/ actually "executed".
2. The halt decider global trace table: This is maintained by HHH
when it simulates an instruction, so it is a halt decider maintained
structure. It is used to decide whether or not to abort.
Instructions from HHH and below are ignored, although they are
actually simulated. (While instructions in HHH are ignored/suppressed
from both traces, the mechanisms for this are quite separate.)
The traces PO posts are output traces. If PO's output trace did not
suppress HHH instructions the end result would be the same, but the
trace output much longer. We would see (say) 50 HHH level 0
instructions then a single interspersed simulation level 1 instruction
then 50 more level 0 instructions and so on. (This change would be an
x86utm code change.)
If the global trace table in halt7.c did not suppress HHH instructions
the result would be completely different, since HHH would see the
conditional branches and never abort. (That would require a halt7.c
code change.)
Mike.
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
Again the same error.
[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
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
You see? HHH does not properly simulate itself. Because it missed all
the conditional branch instructions in the simulation of itself, an
infinite recursion is assumed. This bug makes that it > aborts
before it can see that there is only a finite recursion, after which
the simulated HHH would
abort and return.
On 5/28/2025 2:17 PM, Fred. Zwarts wrote:
Op 28.mei.2025 om 20:38 schreef olcott:
On 5/28/2025 1:23 PM, Mr Flibble wrote:And nobody requires otherwise. But the input to HHH is a pointer to
On Mon, 26 May 2025 21:22:55 -0500, olcott wrote:
On 5/26/2025 9:09 PM, Richard Damon wrote:
On 5/26/25 6:05 PM, olcott wrote:*Termination analyzers PREDICT behavior dip-shit* It is a tautology
On 5/26/2025 3:44 PM, Richard Damon wrote:But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that >>>>>> DDD() will halt.
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:But you have to affirm first that HHH *IS* a program that does >>>>>>>> that,
On 2025-05-25 14:36:26 +0000, olcott said:I am asking you to affirm that I am correct about this point. >>>>>>>>> DDD simulated by HHH according to the rules of the x86 language >>>>>>>>> cannot possibly reach its own "ret" instruction final halt state, >>>>>>>>> thus is correctly rejected as non-halting.
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that >>>>>>>>>>>>> myself
and Peter Olcott have to fight against.
Everything here seems to be dishonesty and protests against >>>>>>>>>>>> dishonesty.
If you could remove all dishonesty the protests woud stop, too, >>>>>>>>>>>> and nothing would be left.
_DDD()
[00002192] 55 push ebp [00002193] 8bec mov
ebp,esp [00002195] 6892210000 push 00002192 [0000219a] >>>>>>>>>>> e833f4ffff call 000015d2 // call HHH [0000219f] >>>>>>>>>>> 83c404 add esp,+04 [000021a2] 5d pop ebp
[000021a3] c3 ret Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according to the >>>>>>>>>>> rules
of the x86 language cannot possibly reach its own "ret"
instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the >>>>>>>>>> beginning to end.
and can't be "changed" to some other program, and that DDD is
"completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then DDD() and HHH() >>>>>>> never
stop running proving that the input to HHH(DDD) SPECIFIES
NON-TERMINATING BEHAVIOR THAT MUST BE ABORTED.
that
every input that must be aborted to prevent the infinite simulation of >>>>> this input DOES SPECIFY NON-HALTING BEHAVIOR.
Olcott is claiming:
“My SHD detects that the program (e.g., `DDD()`) has an *infiniterecursion structure* and therefore halts early with a decision: non-
halting.”
This would mean:
* SHD *does not simulate* the entire execution.
* Instead, it performs **analysis** (akin to symbolic execution, static >>>> control flow, or syntactic pattern detection).
* It concludes **before execution completes** that the input program
will
never halt.
This now resembles modern **termination analyzers** used in:
* Formal methods (e.g., Coq, Agda)
* CompCert (verified C compiler)
* Model checking and static analysis tools
---
### 🔍 What This Means
1. **SHD becomes a partial analyzer.**
* It is no longer a classical halt decider (which must be total). >>>> * It becomes a **sound** (never wrongly claims halting) but
**incomplete** (may fail to decide in some cases) analyzer.
2. **Detection ≠ Simulation**
* Damon’s original critique presumes SHD reaches a contradiction >>>> through simulation.
* But if SHD performs structural detection of recursive constructs >>>> (e.g., unguarded self-calls), it’s operating at the **language or AST >>>> level**, not the runtime level.
3. **Olcott's Argument Gets Stronger**
* If SHD statically proves a path leads to infinite recursion, then >>>> halting early is valid.
* This kind of structural non-termination detection is used in many >>>> safe languages and compilers.
---
### ⚖️ Remaining Limitations
However, the halting problem in its classical sense is **not about some >>>> programs** — it is about **all** programs:
There exists no algorithm that, for every program $P$ and input $x$,decides whether $P(x)$ halts.
Olcott’s SHD does **not** refute this proof, because:
* SHD avoids the contradiction **by not accepting certain inputs**
(i.e.,
pathological ones like `DDD()`).
* This is not a **refutation**, but a **domain restriction** —
similar to
how total languages avoid undecidability by design.
---
### ✅ Summary
| Topic | Classical View | Olcott’s
SHD |
| ---------------- | ------------------------------------ |
------------------------------------------- |
| Simulation | Required to define behavior | Avoided via
structural detection |
| Decider behavior | Total — must decide for all programs | Partial
— only
works on analyzable inputs |
| DDD self-call | Causes contradiction in proof | Detected as
infinite by SHD, then rejected |
| Result | Proof of undecidability holds | SHD
reframes
the problem, doesn't refute it |
---
### 🧩 Final Assessment
**If Olcott’s SHD uses static analysis to detect infinite recursion**, >>>> it behaves like modern verification tools and total languageanalyzers —
which are **sound** but **incomplete**.
That’s valid and **useful** — but it does **not refute the Halting >>>> Problem
proof**. It sidesteps the contradiction **by changing the
semantics** of
what inputs are allowed and how decisions are made.
So, Olcott’s SHD is **not wrong**, but its scope is misunderstood:
it’s a
*partial, structural halting predictor*, not a general refutation of
undecidability.
My only aim is to show that the conventional halting
problem proof is wrong.
When HHH is required to report on the behavior that
its input actually specifies then the counter-example
input to the Halting Problem proofs is correctly
rejected as non-halting.
When HHH is required to report on behavior
OTHER THAN THE BEHAVIOR THAT ITS INPUT ACTUAL SPECIFIES
then the requirement is incorrect.
DDD. The code of DDD has addresses, e.g. in the call instruction. In
this way HHH has access to DDD and all function called by it directly
or indirectly. This includes the code that aborts and halts the program.
That is what the input specifies. But HHH has a bug so that it does
not see the full specification. That does in no way change the
specification of a halting program. Only HHH does not see it, because
it is blind for it.
So, the requirement is correct, but HHH is unable to fulfil it.
Unless DDD emulated by HHH aborts its emulation
then the emulated DDD, the executed DDD() and the
executed HHH() never stop running.
This conclusively proves beyond all doubt what-so-ever
that the input to HHH(DDD)
specifies a non-halting
sequence of configurations.
On 5/28/2025 1:44 PM, Fred. Zwarts wrote:due to the bug in HHH which makes that HHH aborts before it can see the
Op 28.mei.2025 om 16:54 schreef olcott:
On 5/28/2025 3:35 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 17:31 schreef olcott:
On 5/27/2025 3:37 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 04:22 schreef olcott:
On 5/26/2025 9:09 PM, Richard Damon wrote:Counter-factual. There is no need to prevent infinite simulation,
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that >>>>>>>>>>>>>>> myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests >>>>>>>>>>>>>> against dishonesty.
If you could remove all dishonesty the protests woud stop, >>>>>>>>>>>>>> too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according >>>>>>>>>>>>> to the rules of the x86 language cannot possibly reach >>>>>>>>>>>>> its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from >>>>>>>>>>>> the beginning
to end.
I am asking you to affirm that I am correct about this point. >>>>>>>>>>> DDD simulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction >>>>>>>>>>> final halt state, thus is correctly rejected as non-halting. >>>>>>>>>>>
But you have to affirm first that HHH *IS* a program that does >>>>>>>>>> that, and can't be "changed" to some other program, and that >>>>>>>>>> DDD is "completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a fact >>>>>>>> that DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
It is a tautology that every input that must be
aborted to prevent the infinite simulation of this
input DOES SPECIFY NON-HALTING BEHAVIOR.
because the input includes DDD with all functions called by DDD,
including the code in Halt7.c that specifies the abort.
Unless the outmost HHH aborts then none of them
abort because they all of the exact same machine code.
Only when you also change the input. Changing input from a HHH that
aborts to a HHH that does not abort is changing the subject.
It either every HHH aborts or no HHH aborts
because they all have the same machine code.
So, you admit to change the input when you change the simulator. For
each HHH you are talking about an other input. In that way you confuse
yourself. Each input has a different behaviour. But none of your HHH
is able to simulate itself up to the end correctly.
Changing the input is not allowed.
Simulating Termination analyzers must PREDICT
non-terminating behavior, thus are inherently
required to report on what the behavior would be.
Indeed, and when the input is a pointer to memory that contains a HHH
that aborts, the input specifies a halting program and HHH must
predict *that* specified behaviour. Not the behaviour of a non-
aborting HHH that is not in the memory given as input.
To require a STA to report on the actual behavior
of a non-terminating input is to require them to
never report. This is not allowed.
It is not allowed to report on a non-input. It must predict about the
behaviour of the halting program in the input.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations.
Indeed, but we know that the simulated HHH aborts,
Which does not help DDD emulated by HHH to reach
its own simulated "ret" instruction final halt state,
On 5/29/2025 3:33 AM, Mikko wrote:
On 2025-05-28 19:41:23 +0000, olcott said:
On 5/28/2025 1:54 PM, Fred. Zwarts wrote:
Op 28.mei.2025 om 17:02 schreef olcott:
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the >>>>>>>>>> input and specifies an abort, so the program specified by the >>>>>>>>>> input halts. But HHH fails to see that. It does not even start >>>>>>>>>> to simulate itself, but aborts at that point. So, it is in no >>>>>>>>>> way a proof that your simulator is able to simulate itself, >>>>>>>>>> let alone to simulate itself correctly.
Op 26.mei.2025 om 20:48 schreef olcott:
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:No Mike is just wrong.
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:And that is the bug in HHH. It does not go far enough. >>>>>>>>>>>>>>>
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>> On 25/05/2025 21:30, olcott wrote:Again you make the same mistake by not only changing >>>>>>>>>>>>>>>>>> the decider, but also the input.
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> *Mike understood this perfectly* >>>>>>>>>>>>>>>>>>>>>>> On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>> --------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly >>>>>>>>>>>>>>>>>>>>>>> what I said a SHD
does above. It tells PO that in the tight loop >>>>>>>>>>>>>>>>>>>>>>> example, H correctly
simulates as far as [A], at which point it >>>>>>>>>>>>>>>>>>>>>>> correctly determines that
"its simulated input would never stop running >>>>>>>>>>>>>>>>>>>>>>> unless aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>>>>>> false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>> https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- >>>>>>>>>>>>>>>>>>>>>>> email.me%3E
And you dishonestly left out the part that >>>>>>>>>>>>>>>>>>>>>> immediately follows where he states that you are >>>>>>>>>>>>>>>>>>>>>> wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed >>>>>>>>>>>>>>>>>>>>> to are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/ >>>>>>>>>>>>>>>>>>>>
- I did explain how Sipser's words can be naturally >>>>>>>>>>>>>>>>>>>> interpreted as explaining
how a simulating halt decider can operate. >>>>>>>>>>>>>>>>>>>> [That is not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct >>>>>>>>>>>>>>>>>>> reasoning
showing how an expression of language is true, this >>>>>>>>>>>>>>>>>>> is a proof.
- I also explained why that explanation *doesn't* >>>>>>>>>>>>>>>>>>>> apply to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if >>>>>>>>>>>>>>>>>>> simulated
far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>>>>>
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>>
Once you and I work through this one point I may >>>>>>>>>>>>>>>>>>> finally have complete closure.
We are discussing the input where DDD calls a HHH that >>>>>>>>>>>>>>>>>> aborts after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
No, *you* are just wrong.
A correct simulation needs only one recursion more than >>>>>>>>>>>>>> the simulated HHH. The bug in HHH is, that it aborts one >>>>>>>>>>>>>> cycle too early.
The outermost HHH always sees one whole recursive emulation >>>>>>>>>>>>> more than the next inner one.
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails.
My code proves otherwise.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
It is a verified fact that HHH does simulate itself simulating >>>>>>>>> DDD.
If you are too incompetent to understand that this does not count >>>>>>>>> as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does >>>>>>>> not simulate itself, but aborts the simulation at the point
where the simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false
assumptions about itself, in particular it assumes that 'itself' >>>>>>>> does not halt.
That you do not understand your own code is in no way a rebuttal >>>>>>>> for my claim that no simulator is able to simulate itself up to >>>>>>>> the end.
It seems you do not even understand what 'counter-factual' means.
Your own traces show that the simulation is aborted without
simulating the call instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD.
We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by 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
You see? The call is not properly simulated.
No stupid you are wrong.
I prove that HHH is simulating itself simulating DDD
by the next lines of the correctly simulated DDD.
The trace of the simulation of HHH is not shown and the trace of other
simulations do not prove that HHH is simulated. The traces don't show
which simulator produced them.
If you don't know how to make a better output program you are free to
ask.
Mike has already verified this, see what he just said.
On 5/28/2025 8:02 PM, Mike Terry wrote:
Perhaps you slightly misunderstand the presented trace.
The instructions starting at 000015ee /are/ simulated,
but then simply suppressed from the output PO shows.
On 5/29/2025 10:49 AM, Fred. Zwarts wrote:
Op 29.mei.2025 om 17:45 schreef olcott:
On 5/29/2025 3:33 AM, Mikko wrote:
On 2025-05-28 19:41:23 +0000, olcott said:
On 5/28/2025 1:54 PM, Fred. Zwarts wrote:
Op 28.mei.2025 om 17:02 schreef olcott:
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:You see? The call is not properly simulated.
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the input and specifies an
Op 26.mei.2025 om 20:48 schreef olcott:My code proves otherwise.
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:No Mike is just wrong.
On 5/26/2025 3:42 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 04:22 schreef olcott: >>>>>>>>>>>>>>>>>>>>> On 5/25/2025 9:00 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>> On 25/05/2025 21:30, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:05 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:56 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> *Mike understood this perfectly* >>>>>>>>>>>>>>>>>>>>>>>>> On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>> --------- Sipser quote ----- >>>>>>>>>>>>>>>>>>>>>>>>> If simulating halt decider H correctly simulates its input D until HAnd that is the bug in HHH. It does not go far enough. >>>>>>>>>>>>>>>>>
Again you make the same mistake by not only changing the decider, but also thecorrectly 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.
---------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so
it can decide "non-halting". >>>>>>>>>>>>>>>>>>>>>>>>>
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>>>>>>>> false premises to mislead PO. >>>>>>>>>>>>>>>>>>>>>>>>>
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>> https://al.howardknight.net/? >>>>>>>>>>>>>>>>>>>>>>>>> STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- email.me%3E
And you dishonestly left out the part that immediately follows where he
states that you are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/ >>>>>>>>>>>>>>>>>>>>>>
- I did explain how Sipser's words can be naturally interpreted as explaining
how a simulating halt decider can operate. [That is not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning
showing how an expression of language is true, this is a proof.
- I also explained why that explanation *doesn't* apply to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>>>>>>>
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>>>>
Once you and I work through this one point I may >>>>>>>>>>>>>>>>>>>>> finally have complete closure.
input.
We are discussing the input where DDD calls a HHH that aborts after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>
No, *you* are just wrong.
A correct simulation needs only one recursion more than the simulated HHH. The bug
in HHH is, that it aborts one cycle too early.
The outermost HHH always sees one whole recursive emulation >>>>>>>>>>>>>>> more than the next inner one.
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails. >>>>>>>>>>>>>
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>
abort, so the program specified by the input halts. But HHH fails to see that. It does
not even start to simulate itself, but aborts at that point. So, it is in no way a proof
that your simulator is able to simulate itself, let alone to simulate itself correctly.
It is a verified fact that HHH does simulate itself simulating DDD. >>>>>>>>>>> If you are too incompetent to understand that this does not count >>>>>>>>>>> as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does not simulate itself, but
aborts the simulation at the point where the simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false assumptions about itself, in
particular it assumes that 'itself' does not halt.
That you do not understand your own code is in no way a rebuttal for my claim that no
simulator is able to simulate itself up to the end.
It seems you do not even understand what 'counter-factual' means. Your own traces show that
the simulation is aborted without simulating the call instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD.
We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by 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 >>>>>>
No stupid you are wrong.
I prove that HHH is simulating itself simulating DDD
by the next lines of the correctly simulated DDD.
The trace of the simulation of HHH is not shown and the trace of other >>>> simulations do not prove that HHH is simulated. The traces don't show
which simulator produced them.
If you don't know how to make a better output program you are free to ask. >>>>
Mike has already verified this, see what he just said.
On 5/28/2025 8:02 PM, Mike Terry wrote:
Perhaps you slightly misunderstand the presented trace.
The instructions starting at 000015ee /are/ simulated,
but then simply suppressed from the output PO shows.
And he also added that it does not make a difference, because HHH still forgets to count the
conditional branch instruction within the simulation of HHH.
Of course, you remove this most important part of his contribution.
We must achieve 100% complete closure on each point
one-at-a-time and not endlessly flit back and forth
across many different points never achieving closure
on any of them.
THIS POINT IS NOW CLOSED
*HHH does correctly simulate itself simulating DDD*
On 5/28/2025 4:16 PM, Richard Heathfield wrote:
On 28/05/2025 22:05, dbush wrote:
On 5/28/2025 2:38 PM, olcott wrote:
My only aim is to show that the conventional halting
problem proof is wrong.
But why would you care whether or not the proof is wrong when
you've gone on record (multiple times) as stating that what
the proof proves is correct?
It would certainly earn him a place in history's footnotes,
which might well be considered sufficient motive. But he'd have
to be able to explain why he's right, which of course he can't.
<snip>
See my post: [Disagreeing with tautologies is always incorrect]
THIS POINT IS NOW CLOSED
*HHH does correctly simulate itself simulating DDD*
On 5/29/2025 12:40 PM, Richard Heathfield wrote:
On 29/05/2025 16:49, olcott wrote:
On 5/28/2025 4:16 PM, Richard Heathfield wrote:
On 28/05/2025 22:05, dbush wrote:
On 5/28/2025 2:38 PM, olcott wrote:
My only aim is to show that the conventional halting
problem proof is wrong.
But why would you care whether or not the proof is wrong
when you've gone on record (multiple times) as stating that
what the proof proves is correct?
It would certainly earn him a place in history's footnotes,
which might well be considered sufficient motive. But he'd
have to be able to explain why he's right, which of course he
can't.
<snip>
See my post: [Disagreeing with tautologies is always incorrect]
And it seems you still can't.
I have already read your article "Disagreeing with tautologies
is always incorrect"[1], which completely fails to explain your
proof.
Maybe you have no idea what a tautology is.
Its the same thing as a self-evident truth.
<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
It is a tautology that any input D to termination
analyzer H that *would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
On 5/29/2025 12:44 PM, Richard Heathfield wrote:
On 29/05/2025 17:42, olcott wrote:
THIS POINT IS NOW CLOSED
*HHH does correctly simulate itself simulating DDD*
It's as easy as that, eh? Okay.
THIS POINT IS NOW CLOSED
Olcott's 'proof' doesn't prove his claim.
Maybe you have no idea what a tautology is.
All tautologies always prove themselves.
Its the same thing as a self-evident truth.
In epistemology (theory of knowledge), a self-evident
proposition is a proposition that is known to be true
by understanding its meaning without proof...
https://en.wikipedia.org/wiki/Self-evidence
On 5/29/2025 2:02 PM, Richard Heathfield wrote:
On 29/05/2025 19:16, olcott wrote:
On 5/29/2025 12:44 PM, Richard Heathfield wrote:
On 29/05/2025 17:42, olcott wrote:
THIS POINT IS NOW CLOSED
*HHH does correctly simulate itself simulating DDD*
It's as easy as that, eh? Okay.
THIS POINT IS NOW CLOSED
Olcott's 'proof' doesn't prove his claim.
Maybe you have no idea what a tautology is.
Maybe you have no idea what s proof is.
All tautologies always prove themselves.
Its the same thing as a self-evident truth.
It's a self-evident truth that your 'proof' is baloney,
therefore it's a self-evident truth that your 'proof' is baloney.
In epistemology (theory of knowledge), a self-evident
proposition is a proposition that is known to be true
by understanding its meaning without proof...
So you admit you have no proof.
<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
*THIS IS COMPLETE PROOF*
It is a tautology that any input D to simulating termination
analyzer H that *would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
On 5/29/2025 1:40 PM, Richard Heathfield wrote:
On 29/05/2025 19:14, olcott wrote:
It is a tautology that any input D to termination
analyzer H that *would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
But in making that claim you assume that you correctly know the
termination behaviour of D.
All that H needs to know is that D
*would never stop running unless aborted*
I can easily sketch out a program that your HHH analyser would
impatiently abort as non-terminating, but which could
conceivably stop running this year, next year, sometime... or
never.
If you now agree that the above *is* a tautology then
we can move on to the next point.
I can easily sketch out a program that your HHH analyser
would impatiently abort as non-terminating, but which could
conceivably stop running this year, next year, sometime... or
never.
A simulating termination analyzer must PREDICT FUTURE BEHAVIOR.
This means that it must predict what the behavior WOULD BE if
it never aborted its simulation.
On 5/29/2025 3:29 PM, Richard Heathfield wrote:
On 29/05/2025 20:24, olcott wrote:
<repetitive nonsense snipped>
If you now agree that the above *is* a tautology then
we can move on to the next point.
And AGAIN you ignore my substantive point.
I will always ignore every single point that you ever
make until we have mutual agreement on this point.
I
wasted 15 years of my life
with Ben's despicably
dishonest change-the-subject form of rebuttal.
On 5/29/2025 3:34 PM, Richard Heathfield wrote:
On 29/05/2025 21:00, olcott wrote:
A simulating termination analyzer must PREDICT FUTURE BEHAVIOR.
This means that it must
correctly
predict what the behavior WOULD BE if
it never aborted its simulation.
It must not only predict, but predict *correctly*.
So we agree now?
On 5/29/2025 5:18 PM, olcott wrote:
*WE CAN STAY ON THIS ONE POINT FOREVER IF YOU LIKE*As this is repeating a previously refuted point, let's follow this and
It is a tautology that any input D to simulating termination analyzer H
that *would never stop running unless aborted* DOES SPECIFY
NON-TERMINATING BEHAVIOR.
pick up where we left off:
On 5/29/2025 4:20 PM, olcott wrote:
On 5/29/2025 3:05 PM, dbush wrote:the termination behaviour of D.
On 5/29/2025 4:00 PM, olcott wrote:
On 5/29/2025 2:53 PM, dbush wrote:
On 5/29/2025 3:43 PM, olcott wrote:
On 5/29/2025 2:35 PM, dbush wrote:
On 5/29/2025 3:24 PM, olcott wrote:
On 5/29/2025 2:08 PM, Richard Heathfield wrote:
On 29/05/2025 20:02, olcott wrote:
On 5/29/2025 1:40 PM, Richard Heathfield wrote:
On 29/05/2025 19:14, olcott wrote:
<snip>
It is a tautology that any input D to termination analyzer
H that *would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
But in making that claim you assume that you correctly know
of the function D, the fixed code of the function H, and the fixed code"Description" is a technical term which means a way to encode everything about the algorithm in question.int sum(int x, int y) { return x + y; }Not at all. I have been doing this for a very long time. EvenAll that H needs to know is that D *would never stop running
unless aborted*
But it *doesn't* know that.
You forgot to address my substantive point.
when we go exactly one point at a time it takes people here
several years to begin to address that one point.
It is a tautology that any input D
i.e. a description of algorithm D
*Description*
The above function does some arithmetic stuff
*Specification*
_sum()
[000021b3] 55 push ebp [000021b4] 8bec mov
ebp,esp [000021b6] 8b4508 mov eax,[ebp+08] [000021b9]
03450c add eax,[ebp+0c] [000021bc] 5d pop ebp
[000021bd] c3 ret Size in bytes:(0011) [000021bd]
And for algorithm D, that description consists of the fixed code
of everything that H calls down to the OS level.
directly, as per the requirements:A simulating termination analyzer must PREDICT FUTURE BEHAVIOR.
This means that it must predict what the behavior WOULD BE if
the algorithm described / specified by the input is executed
The requirements contradict reality.
Are you saying that no H exists that can meet these requirements?
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
Failure to respond within one hour of your next post in this newsgroup
will be taken as your official on-the-record admission that in fact no H exists that satisfies the above requirements, which is *exactly* what
the halting problem proofs prove.
On 5/29/2025 3:43 PM, Richard Heathfield wrote:
On 29/05/2025 21:35, olcott wrote:
I will always ignore every single point that you ever
make until we have mutual agreement on this point.
Why should I agree to something that's Just Plain Wrong?
If it is actually wrong then you could provide
the reasoning showing this.
On 5/29/2025 4:43 PM, Richard Heathfield wrote:<snip>
On 29/05/2025 22:15, olcott wrote:
On 5/29/2025 3:43 PM, Richard Heathfield wrote:
Why should I agree to something that's Just Plain Wrong?
If it is actually wrong then you could provide
the reasoning showing this.
Done that. You ignored me.
*So in other words you have nothing*
On 5/29/2025 10:49 AM, Fred. Zwarts wrote:
Op 29.mei.2025 om 17:45 schreef olcott:
On 5/29/2025 3:33 AM, Mikko wrote:
On 2025-05-28 19:41:23 +0000, olcott said:
On 5/28/2025 1:54 PM, Fred. Zwarts wrote:
Op 28.mei.2025 om 17:02 schreef olcott:
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:It is a verified fact that HHH does simulate itself
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of >>>>>>>>>>>> the input and specifies an abort, so the program specified >>>>>>>>>>>> by the input halts. But HHH fails to see that. It does not >>>>>>>>>>>> even start to simulate itself, but aborts at that point. So, >>>>>>>>>>>> it is in no way a proof that your simulator is able to >>>>>>>>>>>> simulate itself, let alone to simulate itself correctly. >>>>>>>>>>>
Op 26.mei.2025 om 20:48 schreef olcott:My code proves otherwise.
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:No Mike is just wrong.
On 5/26/2025 3:42 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 04:22 schreef olcott: >>>>>>>>>>>>>>>>>>>>> On 5/25/2025 9:00 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>> On 25/05/2025 21:30, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:05 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:56 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> *Mike understood this perfectly* >>>>>>>>>>>>>>>>>>>>>>>>> On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>> --------- Sipser quote ----- >>>>>>>>>>>>>>>>>>>>>>>>> If simulating halt decider H correctly >>>>>>>>>>>>>>>>>>>>>>>>> simulates its input D until H >>>>>>>>>>>>>>>>>>>>>>>>> correctly determines that its simulated D >>>>>>>>>>>>>>>>>>>>>>>>> would never stop runningAnd that is the bug in HHH. It does not go far enough. >>>>>>>>>>>>>>>>>
Again you make the same mistake by not only changing >>>>>>>>>>>>>>>>>>>> the decider, but also the input.unless aborted then H can abort its >>>>>>>>>>>>>>>>>>>>>>>>> simulation of D and correctly >>>>>>>>>>>>>>>>>>>>>>>>> report that D specifies a non-halting >>>>>>>>>>>>>>>>>>>>>>>>> sequence of configurations.
---------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>
we can easily interpret that as saying exactly >>>>>>>>>>>>>>>>>>>>>>>>> what I said a SHD
does above. It tells PO that in the tight loop >>>>>>>>>>>>>>>>>>>>>>>>> example, H correctly
simulates as far as [A], at which point it >>>>>>>>>>>>>>>>>>>>>>>>> correctly determines that
"its simulated input would never stop running >>>>>>>>>>>>>>>>>>>>>>>>> unless aborted", so
it can decide "non-halting". >>>>>>>>>>>>>>>>>>>>>>>>>
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>>>>>>>> false premises to mislead PO. >>>>>>>>>>>>>>>>>>>>>>>>>
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>> https://al.howardknight.net/? >>>>>>>>>>>>>>>>>>>>>>>>> STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- >>>>>>>>>>>>>>>>>>>>>>>>> email.me%3E
And you dishonestly left out the part that >>>>>>>>>>>>>>>>>>>>>>>> immediately follows where he states that you are >>>>>>>>>>>>>>>>>>>>>>>> wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed >>>>>>>>>>>>>>>>>>>>>>> to are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/ >>>>>>>>>>>>>>>>>>>>>>
- I did explain how Sipser's words can be >>>>>>>>>>>>>>>>>>>>>> naturally interpreted as explaining >>>>>>>>>>>>>>>>>>>>>> how a simulating halt decider can operate. >>>>>>>>>>>>>>>>>>>>>> [That is not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct >>>>>>>>>>>>>>>>>>>>> reasoning
showing how an expression of language is true, this >>>>>>>>>>>>>>>>>>>>> is a proof.
- I also explained why that explanation *doesn't* >>>>>>>>>>>>>>>>>>>>>> apply to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if >>>>>>>>>>>>>>>>>>>>> simulated
far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>>>>>>>
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>>>>
Once you and I work through this one point I may >>>>>>>>>>>>>>>>>>>>> finally have complete closure.
We are discussing the input where DDD calls a HHH >>>>>>>>>>>>>>>>>>>> that aborts after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if >>>>>>>>>>>>>>>>>>> simulated
far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>> [000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>
No, *you* are just wrong.
A correct simulation needs only one recursion more than >>>>>>>>>>>>>>>> the simulated HHH. The bug in HHH is, that it aborts one >>>>>>>>>>>>>>>> cycle too early.
The outermost HHH always sees one whole recursive emulation >>>>>>>>>>>>>>> more than the next inner one.
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails. >>>>>>>>>>>>>
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>
simulating DDD.
If you are too incompetent to understand that this does not >>>>>>>>>>> count
as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does >>>>>>>>>> not simulate itself, but aborts the simulation at the point >>>>>>>>>> where the simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false
assumptions about itself, in particular it assumes that
'itself' does not halt.
That you do not understand your own code is in no way a
rebuttal for my claim that no simulator is able to simulate >>>>>>>>>> itself up to the end.
It seems you do not even understand what 'counter-factual'
means. Your own traces show that the simulation is aborted
without simulating the call instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD.
We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by 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
You see? The call is not properly simulated.
No stupid you are wrong.
I prove that HHH is simulating itself simulating DDD
by the next lines of the correctly simulated DDD.
The trace of the simulation of HHH is not shown and the trace of other >>>> simulations do not prove that HHH is simulated. The traces don't show
which simulator produced them.
If you don't know how to make a better output program you are free
to ask.
Mike has already verified this, see what he just said.
On 5/28/2025 8:02 PM, Mike Terry wrote:
Perhaps you slightly misunderstand the presented trace.
The instructions starting at 000015ee /are/ simulated,
but then simply suppressed from the output PO shows.
And he also added that it does not make a difference, because HHH
still forgets to count the conditional branch instruction within the
simulation of HHH.
Of course, you remove this most important part of his contribution.
We must achieve 100% complete closure on each point
one-at-a-time and not endlessly flit back and forth
across many different points never achieving closure
on any of them.
THIS POINT IS NOW CLOSED
*HHH does correctly simulate itself simulating DDD*
On 5/29/2025 3:33 AM, Mikko wrote:
On 2025-05-28 19:41:23 +0000, olcott said:
On 5/28/2025 1:54 PM, Fred. Zwarts wrote:
Op 28.mei.2025 om 17:02 schreef olcott:
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the input >>>>>>>>>> and specifies an abort, so the program specified by the input halts. >>>>>>>>>> But HHH fails to see that. It does not even start to simulate itself,
Op 26.mei.2025 om 20:48 schreef olcott:
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:The outermost HHH always sees one whole recursive emulation >>>>>>>>>>>>> more than the next inner one.
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:No Mike is just wrong.
On 5/26/2025 3:42 AM, Fred. Zwarts wrote:And that is the bug in HHH. It does not go far enough. >>>>>>>>>>>>>>>
Op 26.mei.2025 om 04:22 schreef olcott:
On 5/25/2025 9:00 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>> On 25/05/2025 21:30, olcott wrote:Again you make the same mistake by not only changing the decider, but
On 5/25/2025 3:05 PM, dbush wrote:
On 5/25/2025 3:56 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> *Mike understood this perfectly* >>>>>>>>>>>>>>>>>>>>>>> On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>> --------- Sipser quote -----
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.
----------------------------
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so
it can decide "non-halting".
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>>>>>> false premises to mislead PO.
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>> https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- email.me%3E
And you dishonestly left out the part that immediately follows where he
states that you are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/ >>>>>>>>>>>>>>>>>>>>
- I did explain how Sipser's words can be naturally interpreted as explaining
how a simulating halt decider can operate. [That is not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning >>>>>>>>>>>>>>>>>>> showing how an expression of language is true, this is a proof.
- I also explained why that explanation *doesn't* apply to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>>>>>
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>>
Once you and I work through this one point I may >>>>>>>>>>>>>>>>>>> finally have complete closure.
also the input.
We are discussing the input where DDD calls a HHH that aborts after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
No, *you* are just wrong.
A correct simulation needs only one recursion more than the simulated
HHH. The bug in HHH is, that it aborts one cycle too early. >>>>>>>>>>>>>
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails.
My code proves otherwise.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
but aborts at that point. So, it is in no way a proof that your >>>>>>>>>> simulator is able to simulate itself, let alone to simulate itself >>>>>>>>>> correctly.
It is a verified fact that HHH does simulate itself simulating DDD. >>>>>>>>> If you are too incompetent to understand that this does not count >>>>>>>>> as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does not >>>>>>>> simulate itself, but aborts the simulation at the point where the >>>>>>>> simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false assumptions >>>>>>>> about itself, in particular it assumes that 'itself' does not halt. >>>>>>>> That you do not understand your own code is in no way a rebuttal for my
claim that no simulator is able to simulate itself up to the end. >>>>>>>
It seems you do not even understand what 'counter-factual' means. Your >>>>>> own traces show that the simulation is aborted without simulating the >>>>>> call instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD.
We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by 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
You see? The call is not properly simulated.
No stupid you are wrong.
I prove that HHH is simulating itself simulating DDD
by the next lines of the correctly simulated DDD.
The trace of the simulation of HHH is not shown and the trace of other
simulations do not prove that HHH is simulated. The traces don't show
which simulator produced them.
If you don't know how to make a better output program you are free to ask.
Mike has already verified this, see what he just said.
On 5/28/2025 8:02 PM, Mike Terry wrote:
Perhaps you slightly misunderstand the presented trace.
The instructions starting at 000015ee /are/ simulated,
but then simply suppressed from the output PO shows.
On 5/29/2025 10:49 AM, Fred. Zwarts wrote:
Op 29.mei.2025 om 17:45 schreef olcott:
On 5/29/2025 3:33 AM, Mikko wrote:
On 2025-05-28 19:41:23 +0000, olcott said:
On 5/28/2025 1:54 PM, Fred. Zwarts wrote:
Op 28.mei.2025 om 17:02 schreef olcott:
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the input
Op 26.mei.2025 om 20:48 schreef olcott:My code proves otherwise.
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:The outermost HHH always sees one whole recursive emulation >>>>>>>>>>>>>>> more than the next inner one.
On 5/26/2025 11:11 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:25 schreef olcott:No Mike is just wrong.
On 5/26/2025 3:42 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 04:22 schreef olcott: >>>>>>>>>>>>>>>>>>>>> On 5/25/2025 9:00 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>> On 25/05/2025 21:30, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:05 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:56 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> *Mike understood this perfectly* >>>>>>>>>>>>>>>>>>>>>>>>> On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>> --------- Sipser quote ----- >>>>>>>>>>>>>>>>>>>>>>>>> If simulating halt decider H correctly simulates its input D until HAnd that is the bug in HHH. It does not go far enough. >>>>>>>>>>>>>>>>>
Again you make the same mistake by not only changing the decider, butcorrectly 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.
---------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so
it can decide "non-halting". >>>>>>>>>>>>>>>>>>>>>>>>>
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>>>>>>>> false premises to mislead PO. >>>>>>>>>>>>>>>>>>>>>>>>>
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>> https://al.howardknight.net/? >>>>>>>>>>>>>>>>>>>>>>>>> STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- email.me%3E
And you dishonestly left out the part that immediately follows where he
states that you are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/ >>>>>>>>>>>>>>>>>>>>>>
- I did explain how Sipser's words can be naturally interpreted as explaining
how a simulating halt decider can operate. [That is not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning
showing how an expression of language is true, this is a proof.
- I also explained why that explanation *doesn't* apply to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>>>>>>>
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>>>>
Once you and I work through this one point I may >>>>>>>>>>>>>>>>>>>>> finally have complete closure.
also the input.
We are discussing the input where DDD calls a HHH that aborts after one cycle.
*No we are not. We are discussing this*
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>> [000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>
No, *you* are just wrong.
A correct simulation needs only one recursion more than the simulated
HHH. The bug in HHH is, that it aborts one cycle too early. >>>>>>>>>>>>>>>
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails. >>>>>>>>>>>>>
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>
and specifies an abort, so the program specified by the input halts.
But HHH fails to see that. It does not even start to simulate itself,
but aborts at that point. So, it is in no way a proof that your >>>>>>>>>>>> simulator is able to simulate itself, let alone to simulate itself >>>>>>>>>>>> correctly.
It is a verified fact that HHH does simulate itself simulating DDD. >>>>>>>>>>> If you are too incompetent to understand that this does not count >>>>>>>>>>> as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does not >>>>>>>>>> simulate itself, but aborts the simulation at the point where the >>>>>>>>>> simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false assumptions >>>>>>>>>> about itself, in particular it assumes that 'itself' does not halt. >>>>>>>>>> That you do not understand your own code is in no way a rebuttal for my
claim that no simulator is able to simulate itself up to the end. >>>>>>>>>
It seems you do not even understand what 'counter-factual' means. Your >>>>>>>> own traces show that the simulation is aborted without simulating the >>>>>>>> call instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD.
We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by 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
You see? The call is not properly simulated.
No stupid you are wrong.
I prove that HHH is simulating itself simulating DDD
by the next lines of the correctly simulated DDD.
The trace of the simulation of HHH is not shown and the trace of other >>>> simulations do not prove that HHH is simulated. The traces don't show
which simulator produced them.
If you don't know how to make a better output program you are free to ask. >>>>
Mike has already verified this, see what he just said.
On 5/28/2025 8:02 PM, Mike Terry wrote:
Perhaps you slightly misunderstand the presented trace.
The instructions starting at 000015ee /are/ simulated,
but then simply suppressed from the output PO shows.
And he also added that it does not make a difference, because HHH still
forgets to count the conditional branch instruction within the
simulation of HHH.
Of course, you remove this most important part of his contribution.
We must achieve 100% complete closure on each point
one-at-a-time and not endlessly flit back and forth
across many different points never achieving closure
on any of them.
On 2025-05-29 16:42:09 +0000, olcott said:
We must achieve 100% complete closure on each point
one-at-a-time and not endlessly flit back and forth
across many different points never achieving closure
on any of them.
You are not and never have been asked to endlessly flit back
and forth. But you are doing it anyway. You have been adviced
how to to something more useful but you have never done.
On 5/28/25 10:54 AM, olcott wrote:
On 5/28/2025 3:35 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 17:31 schreef olcott:
On 5/27/2025 3:37 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 04:22 schreef olcott:
On 5/26/2025 9:09 PM, Richard Damon wrote:Counter-factual. There is no need to prevent infinite simulation,
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty.
If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach >>>>>>>>>>>> its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the beginning
to end.
I am asking you to affirm that I am correct about this point. >>>>>>>>>> DDD simulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state, thus is correctly rejected as non-halting. >>>>>>>>>>
But you have to affirm first that HHH *IS* a program that does that, >>>>>>>>> and can't be "changed" to some other program, and that DDD is >>>>>>>>> "completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that >>>>>>> DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
It is a tautology that every input that must be
aborted to prevent the infinite simulation of this
input DOES SPECIFY NON-HALTING BEHAVIOR.
because the input includes DDD with all functions called by DDD,
including the code in Halt7.c that specifies the abort.
Unless the outmost HHH aborts then none of them
abort because they all of the exact same machine code.
Only when you also change the input. Changing input from a HHH that
aborts to a HHH that does not abort is changing the subject.
It either every HHH aborts or no HHH aborts
because they all have the same machine code.
And if every HHH aborts and returns 0, then every DDD will Halt.
If no HHH aborts, then no HHH ever answers.
In both cases, it is wrong.
On 29/05/2025 19:14, olcott wrote:
On 5/29/2025 12:40 PM, Richard Heathfield wrote:
On 29/05/2025 16:49, olcott wrote:
On 5/28/2025 4:16 PM, Richard Heathfield wrote:
On 28/05/2025 22:05, dbush wrote:See my post: [Disagreeing with tautologies is always incorrect]
On 5/28/2025 2:38 PM, olcott wrote:
My only aim is to show that the conventional halting problem proof >>>>>>> is wrong.
But why would you care whether or not the proof is wrong when
you've gone on record (multiple times) as stating that what the
proof proves is correct?
It would certainly earn him a place in history's footnotes, which
might well be considered sufficient motive. But he'd have to be able >>>>> to explain why he's right, which of course he can't.
<snip>
And it seems you still can't.
I have already read your article "Disagreeing with tautologies is
always incorrect"[1], which completely fails to explain your proof.
Maybe you have no idea what a tautology is.
Maybe you think that asserting something is true is sufficient to make
it true. It isn't.
Its the same thing as a self-evident truth.
Maybe you think that asserting something is self-evidently true is
sufficient to make it self-evidently true. It isn't.
<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
It is a tautology that any input D to termination analyzer H that
*would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
But in making that claim you assume that you correctly know the
termination behaviour of D.
I can easily sketch out a program that your HHH analyser would
impatiently abort as non-terminating, but which could conceivably stop running this year, next year, sometime... or never.
On Thu, 29 May 2025 19:40:57 +0100, Richard Heathfield <rjh@cpax.org.uk> wrote in <101a9np$gl7$1@dont-email.me>:
On 29/05/2025 19:14, olcott wrote:
It is a tautology that any input D to termination analyzer H that
*would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
But in making that claim you assume that you correctly know the
termination behaviour of D.
I can easily sketch out a program that your HHH analyser would
impatiently abort as non-terminating, but which could conceivably stop
running this year, next year, sometime... or never.
Was wondering when someone would mention that...what does his HHH()
do with arbitrary programs?
$ cat ddd.c
#include <stdio.h>
void ddd(int r)
{
r--;
if(r <= 0) return;
fprintf(stderr,"calling ddd(%d)\n",r);
ddd(r);
fprintf(stderr,"returning, r=%d\n",r);
return;
}
int main(void)
{
ddd(50);
return 0;
}
I'd bet his HHH() would say this is non-terminating.
On Thu, 29 May 2025 19:40:57 +0100, Richard Heathfield <rjh@cpax.org.uk> wrote in <101a9np$gl7$1@dont-email.me>:
On 29/05/2025 19:14, olcott wrote:
On 5/29/2025 12:40 PM, Richard Heathfield wrote:
On 29/05/2025 16:49, olcott wrote:
On 5/28/2025 4:16 PM, Richard Heathfield wrote:
On 28/05/2025 22:05, dbush wrote:See my post: [Disagreeing with tautologies is always incorrect]
On 5/28/2025 2:38 PM, olcott wrote:
My only aim is to show that the conventional halting problem proof >>>>>>>> is wrong.
But why would you care whether or not the proof is wrong when
you've gone on record (multiple times) as stating that what the
proof proves is correct?
It would certainly earn him a place in history's footnotes, which
might well be considered sufficient motive. But he'd have to be able >>>>>> to explain why he's right, which of course he can't.
<snip>
And it seems you still can't.
I have already read your article "Disagreeing with tautologies is
always incorrect"[1], which completely fails to explain your proof.
Maybe you have no idea what a tautology is.
Maybe you think that asserting something is true is sufficient to make
it true. It isn't.
Its the same thing as a self-evident truth.
Maybe you think that asserting something is self-evidently true is
sufficient to make it self-evidently true. It isn't.
<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
It is a tautology that any input D to termination analyzer H that
*would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
But in making that claim you assume that you correctly know the
termination behaviour of D.
I can easily sketch out a program that your HHH analyser would
impatiently abort as non-terminating, but which could conceivably stop
running this year, next year, sometime... or never.
Was wondering when someone would mention that...what does his HHH()
do with arbitrary programs?
$ cat ddd.c
#include <stdio.h>
void ddd(int r)
{
r--;
if(r <= 0) return;
fprintf(stderr,"calling ddd(%d)\n",r);
ddd(r);
fprintf(stderr,"returning, r=%d\n",r);
return;
}
int main(void)
{
ddd(50);
return 0;
}
I'd bet his HHH() would say this is non-terminating.
@Richard: so you cannot make HHH decide non-halting simply by
looping for a long long time, hoping HHH will get fed up! That
would just result in HHH simulating for a corresponding long long
time. You need to feed it a program that halts, but matches one
of his non-halting behaviour tests. For example DDD.
On 30/05/2025 16:29, Mike Terry wrote:
@Richard: so you cannot make HHH decide non-halting simply by looping for a long long time,
hoping HHH will get fed up! That would just result in HHH simulating for a corresponding long
long time. You need to feed it a program that halts, but matches one of his non-halting behaviour
tests. For example DDD.
What if I don't know whether it halts?
I followed up to vallor with a pseudocode sketch of such a program.
If HHH could deliver a reliably correct report for that program within a year or so, that would
probably be enough to earn Mr Olcott a place in the history books.
But at some point we have to place a ceiling on "long long time". A reporting program that keeps
saying "maybe next year" isn't much of a reporting program.
On 30/05/2025 16:41, Richard Heathfield wrote:
On 30/05/2025 16:29, Mike Terry wrote:
@Richard: so you cannot make HHH decide non-halting simply by
looping for a long long time, hoping HHH will get fed up!
That would just result in HHH simulating for a corresponding
long long time. You need to feed it a program that halts, but
matches one of his non-halting behaviour tests. For example DDD.
What if I don't know whether it halts?
I followed up to vallor with a pseudocode sketch of such a
program.
That was the Goldback Conjecture counter-example searcher?
If it
halts it has found a counter-example, so GC is false. If it
never halts GC is true.
If GC were easy to prove/disprove it would have been settled a
long time ago.
It is not going to be settled as a result of
someone writing a partial halt decider that decides your
program.
People have already tested GC up to around
4000000000000000000. In practice, if you gave your program to
HHH you would just see HHH running and running, which is not
useful to anyone.
If HHH could deliver a reliably correct report for that program
within a year or so, that would probably be enough to earn Mr
Olcott a place in the history books.
HHH obviously cannot do that. Also, PO does not claim HHH is a
(full) halt decider, so it does not affect his claims.
Quite so.But at some point we have to place a ceiling on "long longWe have two requirements:
time". A reporting program that keeps saying "maybe next year"
isn't much of a reporting program.
a) people want to actually /use/ real life halt analysis
tools in their daily work. For such people, waiting a year for
a result is no good, like you say. HHH is not a candidate for
people wanting such a real-life tool.
b) people want to understand the /theoretical/ limits of
computation, hence the Halting Problem. The HP places no
limits on how long a program can run, or how much storage it
can consume. PO's HHH is an attempt to invalidate one
particular proof of HP. It does not run for very long when
running HHH/DDD, so we never have to face the "maybe next
year" scenario. [Related HHH/DDD scenarios that never halt
are easily seen to never halt by simple code analysis.]
On 5/30/2025 1:27 PM, olcott wrote:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
There aren't many ways to invalidate a proof. Demonstrating
that the conclusion is false is insufficient (because you now
have two proofs, each of which claims that 'I'm right so
you're wrong'); one must attack the reasoning or the
assumptions (or both) and show how a flawed step or a flawed
assumption invalidates the method (and perhaps the conclusion).
As it happens, Olcott accepts anyway that Turing's conclusion
is correct, so his only beef can be with an assumption or a step.
Turing's conclusion *is correct within a false assumption*
Specifically, the assumption that the following requirements can
be met:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes
the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
YOU MUST PAY ATTENTION TO ALL THE WORDS THAT I SAY.
Turing's only assumption is overturned by reductio within the
proof itself, so that can't be it... which only leaves steps.
As far as I can recall, Olcott's ramblings never go within
discus- throwing distance of a potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
False. "DDD" is a description/specification of algorithm DDD
consisting of the fixed code of the function DDD, the fixed code
function HHH, and the fixed code of everything that HHH calls
down to the OS level.
On 5/30/2025 2:40 PM, olcott wrote:
On 5/30/2025 1:20 PM, Richard Heathfield wrote:
+++++
Let us suppose that there is such a process; that is to say,
that we can invent a machine <D- which, when supplied with the
S.D of any computing machine i l will test this S.D and if i l
is circular will mark the S.D with the symbol "u" and if it is
circle-free will mark it with " s ".
+++++
By "the S.D. of any computing machine" he means the 'standard
description' of >>>>any<<<< Turing machine.
HHH is not that process, and thus HHH has no bearing
whatsoever on the Turing proof.
It is a verified fact that
i.e. a description of algorithm DDD consisting of the fixed code
of the function DDD, the fixed code of the function HHH, and the
fixed code of everything that HHH calls down to the OS level.
does specify a non-halting sequence of configurations.
False, as algorithm HHH, which is what the input describes /
specifies, halts when executed directly or when simulated by UTM.
On 5/30/2025 3:42 AM, Fred. Zwarts wrote:
Op 29.mei.2025 om 18:42 schreef olcott:
On 5/29/2025 10:49 AM, Fred. Zwarts wrote:
Op 29.mei.2025 om 17:45 schreef olcott:
On 5/29/2025 3:33 AM, Mikko wrote:
On 2025-05-28 19:41:23 +0000, olcott said:
On 5/28/2025 1:54 PM, Fred. Zwarts wrote:
Op 28.mei.2025 om 17:02 schreef olcott:
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:It is a verified fact that HHH does simulate itself
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of >>>>>>>>>>>>>> the input and specifies an abort, so the program specified >>>>>>>>>>>>>> by the input halts. But HHH fails to see that. It does not >>>>>>>>>>>>>> even start to simulate itself, but aborts at that point. >>>>>>>>>>>>>> So, it is in no way a proof that your simulator is able to >>>>>>>>>>>>>> simulate itself, let alone to simulate itself correctly. >>>>>>>>>>>>>
Op 26.mei.2025 om 20:48 schreef olcott:My code proves otherwise.
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:
On 5/26/2025 11:11 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 17:25 schreef olcott: >>>>>>>>>>>>>>>>>>>>> On 5/26/2025 3:42 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 04:22 schreef olcott: >>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 9:00 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 25/05/2025 21:30, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:05 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:56 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> *Mike understood this perfectly* >>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> --------- Sipser quote ----- >>>>>>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>>>> ---------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>
No Mike is just wrong.And that is the bug in HHH. It does not go far enough. >>>>>>>>>>>>>>>>>>>Again you make the same mistake by not only >>>>>>>>>>>>>>>>>>>>>> changing the decider, but also the input. >>>>>>>>>>>>>>>>>>>>>> We are discussing the input where DDD calls a HHH >>>>>>>>>>>>>>>>>>>>>> that aborts after one cycle.we can easily interpret that as saying >>>>>>>>>>>>>>>>>>>>>>>>>>> exactly what I said a SHD >>>>>>>>>>>>>>>>>>>>>>>>>>> does above. It tells PO that in the tight >>>>>>>>>>>>>>>>>>>>>>>>>>> loop example, H correctly >>>>>>>>>>>>>>>>>>>>>>>>>>> simulates as far as [A], at which point it >>>>>>>>>>>>>>>>>>>>>>>>>>> correctly determines that >>>>>>>>>>>>>>>>>>>>>>>>>>> "its simulated input would never stop running >>>>>>>>>>>>>>>>>>>>>>>>>>> unless aborted", so
it can decide "non-halting". >>>>>>>>>>>>>>>>>>>>>>>>>>>
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>>>>>>>>>> false premises to mislead PO. >>>>>>>>>>>>>>>>>>>>>>>>>>>
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> https://al.howardknight.net/? >>>>>>>>>>>>>>>>>>>>>>>>>>> STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- email.me%3E
And you dishonestly left out the part that >>>>>>>>>>>>>>>>>>>>>>>>>> immediately follows where he states that you >>>>>>>>>>>>>>>>>>>>>>>>>> are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser >>>>>>>>>>>>>>>>>>>>>>>>> agreed to are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/ >>>>>>>>>>>>>>>>>>>>>>>>
- I did explain how Sipser's words can be >>>>>>>>>>>>>>>>>>>>>>>> naturally interpreted as explaining >>>>>>>>>>>>>>>>>>>>>>>> how a simulating halt decider can operate. >>>>>>>>>>>>>>>>>>>>>>>> [That is not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct >>>>>>>>>>>>>>>>>>>>>>> reasoning
showing how an expression of language is true, >>>>>>>>>>>>>>>>>>>>>>> this is a proof.
- I also explained why that explanation >>>>>>>>>>>>>>>>>>>>>>>> *doesn't* apply to your HHH/ DDD pair >>>>>>>>>>>>>>>>>>>>>>>>
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if >>>>>>>>>>>>>>>>>>>>>>> simulated
far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>>>>>>>>>
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>>>>>>
Once you and I work through this one point I may >>>>>>>>>>>>>>>>>>>>>>> finally have complete closure.
*No we are not. We are discussing this* >>>>>>>>>>>>>>>>>>>>>
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if >>>>>>>>>>>>>>>>>>>>> simulated
far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>>
No, *you* are just wrong.
A correct simulation needs only one recursion more >>>>>>>>>>>>>>>>>> than the simulated HHH. The bug in HHH is, that it >>>>>>>>>>>>>>>>>> aborts one cycle too early.
The outermost HHH always sees one whole recursive >>>>>>>>>>>>>>>>> emulation
more than the next inner one.
Only if you change the input with the simulator. >>>>>>>>>>>>>>>> Every simulator that tries to simulate itself, fails. >>>>>>>>>>>>>>>
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>>>
simulating DDD.
If you are too incompetent to understand that this does not >>>>>>>>>>>>> count
as a rebuttal.
It seems you do not understand what 'simulate' means. HHH >>>>>>>>>>>> does not simulate itself, but aborts the simulation at the >>>>>>>>>>>> point where the simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false >>>>>>>>>>>> assumptions about itself, in particular it assumes that >>>>>>>>>>>> 'itself' does not halt.
That you do not understand your own code is in no way a >>>>>>>>>>>> rebuttal for my claim that no simulator is able to simulate >>>>>>>>>>>> itself up to the end.
It seems you do not even understand what 'counter-factual' >>>>>>>>>> means. Your own traces show that the simulation is aborted >>>>>>>>>> without simulating the call instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD. >>>>>>>>> We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by 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
You see? The call is not properly simulated.
No stupid you are wrong.
I prove that HHH is simulating itself simulating DDD
by the next lines of the correctly simulated DDD.
The trace of the simulation of HHH is not shown and the trace of
other
simulations do not prove that HHH is simulated. The traces don't show >>>>>> which simulator produced them.
If you don't know how to make a better output program you are free >>>>>> to ask.
Mike has already verified this, see what he just said.
On 5/28/2025 8:02 PM, Mike Terry wrote:
Perhaps you slightly misunderstand the presented trace.
The instructions starting at 000015ee /are/ simulated,
but then simply suppressed from the output PO shows.
And he also added that it does not make a difference, because HHH
still forgets to count the conditional branch instruction within the
simulation of HHH.
Of course, you remove this most important part of his contribution.
We must achieve 100% complete closure on each point
one-at-a-time and not endlessly flit back and forth
across many different points never achieving closure
on any of them.
THIS POINT IS NOW CLOSED
*HHH does correctly simulate itself simulating DDD*
If the simulation is meant to analyse the code, then it doesn't,
because it forgets to count the conditional branch instruction during
the simulation. Moreover, its does only a partial simulation, because
it skips the most important part of the simulation, where it reaches
its own 'ret' instruction.
So, the simplification that it does a correct simulation, is not the
full truth.
(The subject is bad faith and dishonesty, so this is relevant.)
Every computation that cannot possibly reach its own
final halt state is a non-terminating computation.
On 5/30/2025 4:14 AM, Richard Heathfield wrote:
On 30/05/2025 10:03, Mikko wrote:
On 2025-05-29 16:42:09 +0000, olcott said:
<snip>
We must achieve 100% complete closure on each point
one-at-a-time and not endlessly flit back and forth
across many different points never achieving closure
on any of them.
You are not and never have been asked to endlessly flit back
and forth. But you are doing it anyway. You have been adviced
how to to something more useful but you have never done.
Quite so. At some point, one must draw a veil across the nonsense. I
think I've reached that point. I do not plan to reply to any more of
Mr Olcott's articles. (Road to hell and that, but that's the plan.)
When DDD is correctly emulated by HHH the first four
instructions of DDD are emulated. When HHH(DDD) is
called from DDD then HHH emulates itself emulating DDD.
No matter how many times HHH emulates itself emulating
DDD the emulated DDD cannot possibly reach its "ret"
instruction final halt state. This proves that DDD emulated
by HHH is non-halting.
On 5/30/2025 10:25 PM, olcott wrote:
Damned liar
That you made no attempt to refute the below
On 5/30/2025 3:42 AM, Fred. Zwarts wrote:
Op 29.mei.2025 om 18:42 schreef olcott:
On 5/29/2025 10:49 AM, Fred. Zwarts wrote:
Op 29.mei.2025 om 17:45 schreef olcott:
On 5/29/2025 3:33 AM, Mikko wrote:
On 2025-05-28 19:41:23 +0000, olcott said:
On 5/28/2025 1:54 PM, Fred. Zwarts wrote:
Op 28.mei.2025 om 17:02 schreef olcott:
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the input
Op 26.mei.2025 om 20:48 schreef olcott:My code proves otherwise.
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:The outermost HHH always sees one whole recursive emulation >>>>>>>>>>>>>>>>> more than the next inner one.
On 5/26/2025 11:11 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 17:25 schreef olcott: >>>>>>>>>>>>>>>>>>>>> On 5/26/2025 3:42 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 04:22 schreef olcott: >>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 9:00 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 25/05/2025 21:30, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:05 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:56 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> *Mike understood this perfectly* >>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> --------- Sipser quote ----- >>>>>>>>>>>>>>>>>>>>>>>>>>> If simulating halt decider H correctly simulates its input D until H
No Mike is just wrong.And that is the bug in HHH. It does not go far enough. >>>>>>>>>>>>>>>>>>>Again you make the same mistake by not only changing the decider, butcorrectly 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.
---------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so
it can decide "non-halting". >>>>>>>>>>>>>>>>>>>>>>>>>>>
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>>>>>>>>>> false premises to mislead PO. >>>>>>>>>>>>>>>>>>>>>>>>>>>
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> https://al.howardknight.net/? >>>>>>>>>>>>>>>>>>>>>>>>>>> STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- email.me%3E
And you dishonestly left out the part that immediately follows where he
states that you are wrong: >>>>>>>>>>>>>>>>>>>>>>>>>>
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/ >>>>>>>>>>>>>>>>>>>>>>>>
- I did explain how Sipser's words can be naturally interpreted as explaining
how a simulating halt decider can operate. [That is not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning
showing how an expression of language is true, this is a proof.
- I also explained why that explanation *doesn't* apply to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>>>>>>>>>
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>>>>>>
Once you and I work through this one point I may >>>>>>>>>>>>>>>>>>>>>>> finally have complete closure.
also the input.
We are discussing the input where DDD calls a HHH that aborts after one cycle.
*No we are not. We are discussing this* >>>>>>>>>>>>>>>>>>>>>
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>>
No, *you* are just wrong.
A correct simulation needs only one recursion more than the simulated
HHH. The bug in HHH is, that it aborts one cycle too early. >>>>>>>>>>>>>>>>>
Only if you change the input with the simulator. >>>>>>>>>>>>>>>> Every simulator that tries to simulate itself, fails. >>>>>>>>>>>>>>>
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>>>
and specifies an abort, so the program specified by the input halts.
But HHH fails to see that. It does not even start to simulate itself,
but aborts at that point. So, it is in no way a proof that your >>>>>>>>>>>>>> simulator is able to simulate itself, let alone to simulate itself
correctly.
It is a verified fact that HHH does simulate itself simulating DDD.
If you are too incompetent to understand that this does not count >>>>>>>>>>>>> as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does not >>>>>>>>>>>> simulate itself, but aborts the simulation at the point where the >>>>>>>>>>>> simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false assumptions >>>>>>>>>>>> about itself, in particular it assumes that 'itself' does not halt.
That you do not understand your own code is in no way a rebuttal for my
claim that no simulator is able to simulate itself up to the end. >>>>>>>>>>>
It seems you do not even understand what 'counter-factual' means. Your
own traces show that the simulation is aborted without simulating the
call instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD. >>>>>>>>> We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by 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
You see? The call is not properly simulated.
No stupid you are wrong.
I prove that HHH is simulating itself simulating DDD
by the next lines of the correctly simulated DDD.
The trace of the simulation of HHH is not shown and the trace of other >>>>>> simulations do not prove that HHH is simulated. The traces don't show >>>>>> which simulator produced them.
If you don't know how to make a better output program you are free to ask.
Mike has already verified this, see what he just said.
On 5/28/2025 8:02 PM, Mike Terry wrote:
Perhaps you slightly misunderstand the presented trace.
The instructions starting at 000015ee /are/ simulated,
but then simply suppressed from the output PO shows.
And he also added that it does not make a difference, because HHH still >>>> forgets to count the conditional branch instruction within the
simulation of HHH.
Of course, you remove this most important part of his contribution.
We must achieve 100% complete closure on each point
one-at-a-time and not endlessly flit back and forth
across many different points never achieving closure
on any of them.
THIS POINT IS NOW CLOSED
*HHH does correctly simulate itself simulating DDD*
If the simulation is meant to analyse the code, then it doesn't,
because it forgets to count the conditional branch instruction during
the simulation. Moreover, its does only a partial simulation, because
it skips the most important part of the simulation, where it reaches
its own 'ret' instruction.
So, the simplification that it does a correct simulation, is not the
full truth.
(The subject is bad faith and dishonesty, so this is relevant.)
Every computation that cannot possibly reach its own
final halt state is a non-terminating computation.
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
On 30/05/2025 17:31, Mike Terry wrote:
On 30/05/2025 16:41, Richard Heathfield wrote:
On 30/05/2025 16:29, Mike Terry wrote:
@Richard: so you cannot make HHH decide non-halting simply by looping >>>>> for a long long time, hoping HHH will get fed up! That would just
result in HHH simulating for a corresponding long long time. You need >>>>> to feed it a program that halts, but matches one of his non-halting
behaviour tests. For example DDD.
What if I don't know whether it halts?
I followed up to vallor with a pseudocode sketch of such a program.
That was the Goldback Conjecture counter-example searcher?
Yes.
If it halts it has found a counter-example, so GC is false. If it
never halts GC is true.
Right.
If GC were easy to prove/disprove it would have been settled a long time ago.
...precisely why I chose it.
It is not going to be settled as a result of someone writing a partial
halt decider that decides your program.
Indeed.
People have already tested GC up to around 4000000000000000000. In
practice, if you gave your program to HHH you would just see HHH
running and running, which is not useful to anyone.
So it doesn't report.
If HHH could deliver a reliably correct report for that program within >>>> a year or so, that would probably be enough to earn Mr Olcott a place
in the history books.
HHH obviously cannot do that. Also, PO does not claim HHH is a (full)
halt decider, so it does not affect his claims.
I know, but I was mildly curious to know whether it would abort or wait
forever, a point you have now addressed, for which my thanks.
Quite so.But at some point we have to place a ceiling on "long long time". AWe have two requirements:
reporting program that keeps saying "maybe next year" isn't much of a
reporting program.
a) people want to actually /use/ real life halt analysis
tools in their daily work. For such people, waiting a year for
a result is no good, like you say. HHH is not a candidate for
people wanting such a real-life tool.
b) people want to understand the /theoretical/ limits of computation,
hence the Halting Problem. The HP places no
limits on how long a program can run, or how much storage it
can consume. PO's HHH is an attempt to invalidate one particular proof >>> of HP. It does not run for very long when
running HHH/DDD, so we never have to face the "maybe next
year" scenario. [Related HHH/DDD scenarios that never halt
are easily seen to never halt by simple code analysis.]
There aren't many ways to invalidate a proof. Demonstrating that the
conclusion is false is insufficient (because you now have two proofs,
each of which claims that 'I'm right so you're wrong'); one must attack
the reasoning or the assumptions (or both) and show how a flawed step
or a flawed assumption invalidates the method (and perhaps the
conclusion).
As it happens, Olcott accepts anyway that Turing's conclusion is
correct, so his only beef can be with an assumption or a step.
Turing's conclusion *is correct within a false assumption*
YOU MUST PAY ATTENTION TO ALL THE WORDS THAT I SAY.
Turing's only assumption is overturned by reductio within the proof
itself, so that can't be it... which only leaves steps.
As far as I can recall, Olcott's ramblings never go within discus-
throwing distance of a potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
On 5/30/2025 4:16 AM, Mikko wrote:
On 2025-05-29 01:37:49 +0000, Richard Damon said:
On 5/28/25 10:54 AM, olcott wrote:
On 5/28/2025 3:35 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 17:31 schreef olcott:
On 5/27/2025 3:37 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 04:22 schreef olcott:
On 5/26/2025 9:09 PM, Richard Damon wrote:Counter-factual. There is no need to prevent infinite simulation, >>>>>>> because the input includes DDD with all functions called by DDD, >>>>>>> including the code in Halt7.c that specifies the abort.
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said:
So much bad faith and dishonesty shown in this forum that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty.
If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according >>>>>>>>>>>>>> to the rules of the x86 language cannot possibly reach >>>>>>>>>>>>>> its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the beginning
to end.
I am asking you to affirm that I am correct about this point. >>>>>>>>>>>> DDD simulated by HHH according to the rules of the x86 >>>>>>>>>>>> language cannot possibly reach its own "ret" instruction >>>>>>>>>>>> final halt state, thus is correctly rejected as non-halting. >>>>>>>>>>>>
But you have to affirm first that HHH *IS* a program that does that,
and can't be "changed" to some other program, and that DDD is >>>>>>>>>>> "completed" to contain that same code.
Of course, once you define that HHH is such a program,
Unless HHH(DDD) aborts its emulation of DDD then
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that >>>>>>>>> DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
It is a tautology that every input that must be
aborted to prevent the infinite simulation of this
input DOES SPECIFY NON-HALTING BEHAVIOR.
Unless the outmost HHH aborts then none of them
abort because they all of the exact same machine code.
Only when you also change the input. Changing input from a HHH that
aborts to a HHH that does not abort is changing the subject.
It either every HHH aborts or no HHH aborts
because they all have the same machine code.
And if every HHH aborts and returns 0, then every DDD will Halt.
If no HHH aborts, then no HHH ever answers.
In both cases, it is wrong.
And if every HHH aborts and returns 1 then every DDD will halt. In
this case HHH is right. But in this case HHH is not Olcott's HHH.
When DDD is correctly emulated by HHH the first four
instructions of DDD are emulated. When HHH(DDD) is
called from DDD then HHH emulates itself emulating DDD.
No matter how many times HHH emulates itself emulating
DDD the emulated DDD cannot possibly reach its "ret"
instruction final halt state. This proves that DDD emulated
by HHH is non-halting.
On 5/30/2025 1:20 PM, Richard Heathfield wrote:
On 30/05/2025 18:45, dbush wrote:
On 5/30/2025 1:27 PM, olcott wrote:Yes, that is precisely the assumption Turing makes, and he makes it
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
There aren't many ways to invalidate a proof. Demonstrating that the >>>>> conclusion is false is insufficient (because you now have two proofs, >>>>> each of which claims that 'I'm right so you're wrong'); one must attack >>>>> the reasoning or the assumptions (or both) and show how a flawed step >>>>> or a flawed assumption invalidates the method (and perhaps the
conclusion).
As it happens, Olcott accepts anyway that Turing's conclusion is
correct, so his only beef can be with an assumption or a step.
Turing's conclusion *is correct within a false assumption*
Specifically, the assumption that the following requirements can be met: >>>
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly >>
explicitly, and he makes it with the express intent of showing that it
cannot be true.
YOU MUST PAY ATTENTION TO ALL THE WORDS THAT I SAY.
Noise on the line again, I see. I must call the broadband people.
Turing's only assumption is overturned by reductio within the proof
itself, so that can't be it... which only leaves steps.
As far as I can recall, Olcott's ramblings never go within discus-
throwing distance of a potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
False. "DDD" is a description/specification of algorithm DDD consisting
of the fixed code of the function DDD, the fixed code function HHH, and
the fixed code of everything that HHH calls down to the OS level.
HHH is not the computation Turing assumed could exist (for the sole
purpose of showing that it could not). HHH is a hodgepodge of shit C
and what looks like more line noise in assembly mnemonics. It is not a
universal computation such as Turing envisaged:
+++++
Let us suppose that there is such a process; that is to say, that we
can invent a machine <D- which, when supplied with the S.D of any
computing machine i l will test this S.D and if i l is circular will
mark the S.D with the symbol "u" and if it is circle-free will mark it
with " s ".
+++++
By "the S.D. of any computing machine" he means the 'standard
description' of >>>>any<<<< Turing machine.
HHH is not that process, and thus HHH has no bearing whatsoever on the
Turing proof.
It is a verified fact that the
*input input input input input input*
*input input input input input input*
*input input input input input input*
*input input input input input input*
to HHH(DDD)
does specify a non-halting sequence of configurations.
On 5/30/2025 4:03 AM, Mikko wrote:
On 2025-05-29 16:42:09 +0000, olcott said:
On 5/29/2025 10:49 AM, Fred. Zwarts wrote:
Op 29.mei.2025 om 17:45 schreef olcott:
On 5/29/2025 3:33 AM, Mikko wrote:
On 2025-05-28 19:41:23 +0000, olcott said:
On 5/28/2025 1:54 PM, Fred. Zwarts wrote:
Op 28.mei.2025 om 17:02 schreef olcott:
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part of the input
Op 26.mei.2025 om 20:48 schreef olcott:My code proves otherwise.
On 5/26/2025 1:34 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:21 schreef olcott:The outermost HHH always sees one whole recursive emulation >>>>>>>>>>>>>>>>> more than the next inner one.
On 5/26/2025 11:11 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 17:25 schreef olcott: >>>>>>>>>>>>>>>>>>>>> On 5/26/2025 3:42 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 04:22 schreef olcott: >>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 9:00 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 25/05/2025 21:30, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:05 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:56 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> *Mike understood this perfectly* >>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> --------- Sipser quote ----- >>>>>>>>>>>>>>>>>>>>>>>>>>> If simulating halt decider H correctly simulates its input D until H
No Mike is just wrong.And that is the bug in HHH. It does not go far enough. >>>>>>>>>>>>>>>>>>>Again you make the same mistake by not only changing the decider, butcorrectly 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.
---------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so
it can decide "non-halting". >>>>>>>>>>>>>>>>>>>>>>>>>>>
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>>>>>>>>>> false premises to mislead PO. >>>>>>>>>>>>>>>>>>>>>>>>>>>
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> https://al.howardknight.net/? >>>>>>>>>>>>>>>>>>>>>>>>>>> STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- email.me%3E
And you dishonestly left out the part that immediately follows where he
states that you are wrong: >>>>>>>>>>>>>>>>>>>>>>>>>>
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
Just for the record:
1) I didn't offer any proofs of /anything/ >>>>>>>>>>>>>>>>>>>>>>>>
- I did explain how Sipser's words can be naturally interpreted as explaining
how a simulating halt decider can operate. [That is not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning
showing how an expression of language is true, this is a proof.
- I also explained why that explanation *doesn't* apply to your HHH/ DDD pair
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>>>>>>>>>
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>>>>>>
Once you and I work through this one point I may >>>>>>>>>>>>>>>>>>>>>>> finally have complete closure.
also the input.
We are discussing the input where DDD calls a HHH that aborts after one cycle.
*No we are not. We are discussing this* >>>>>>>>>>>>>>>>>>>>>
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if simulated >>>>>>>>>>>>>>>>>>>>> far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>>
No, *you* are just wrong.
A correct simulation needs only one recursion more than the simulated
HHH. The bug in HHH is, that it aborts one cycle too early. >>>>>>>>>>>>>>>>>
Only if you change the input with the simulator. >>>>>>>>>>>>>>>> Every simulator that tries to simulate itself, fails. >>>>>>>>>>>>>>>
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>>>
and specifies an abort, so the program specified by the input halts.
But HHH fails to see that. It does not even start to simulate itself,
but aborts at that point. So, it is in no way a proof that your >>>>>>>>>>>>>> simulator is able to simulate itself, let alone to simulate itself
correctly.
It is a verified fact that HHH does simulate itself simulating DDD.
If you are too incompetent to understand that this does not count >>>>>>>>>>>>> as a rebuttal.
It seems you do not understand what 'simulate' means. HHH does not >>>>>>>>>>>> simulate itself, but aborts the simulation at the point where the >>>>>>>>>>>> simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false assumptions >>>>>>>>>>>> about itself, in particular it assumes that 'itself' does not halt.
That you do not understand your own code is in no way a rebuttal for my
claim that no simulator is able to simulate itself up to the end. >>>>>>>>>>>
It seems you do not even understand what 'counter-factual' means. Your
own traces show that the simulation is aborted without simulating the
call instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD. >>>>>>>>> We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by 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
You see? The call is not properly simulated.
No stupid you are wrong.
I prove that HHH is simulating itself simulating DDD
by the next lines of the correctly simulated DDD.
The trace of the simulation of HHH is not shown and the trace of other >>>>>> simulations do not prove that HHH is simulated. The traces don't show >>>>>> which simulator produced them.
If you don't know how to make a better output program you are free to ask.
Mike has already verified this, see what he just said.
On 5/28/2025 8:02 PM, Mike Terry wrote:
Perhaps you slightly misunderstand the presented trace.
The instructions starting at 000015ee /are/ simulated,
but then simply suppressed from the output PO shows.
And he also added that it does not make a difference, because HHH still >>>> forgets to count the conditional branch instruction within the
simulation of HHH.
Of course, you remove this most important part of his contribution.
We must achieve 100% complete closure on each point
one-at-a-time and not endlessly flit back and forth
across many different points never achieving closure
on any of them.
You are not and never have been asked to endlessly flit back and forth.
But you are doing it anyway. You have been adviced how to to something
more useful but you have never done.
The fact that DDD correctly emulated by HHH cannot
possibly stop running unless aborted and cannot
possibly reach its own "ret" instruction final halt
state conclusively proves that the input to HHH(DDD)
specifies a non-halting sequence of configurations.
On 5/30/2025 2:01 PM, dbush wrote:
On 5/30/2025 3:00 PM, olcott wrote:
On 5/30/2025 1:48 PM, dbush wrote:
On 5/30/2025 2:40 PM, olcott wrote:
On 5/30/2025 1:20 PM, Richard Heathfield wrote:
On 30/05/2025 18:45, dbush wrote:
On 5/30/2025 1:27 PM, olcott wrote:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
There aren't many ways to invalidate a proof. Demonstrating that the >>>>>>>>> conclusion is false is insufficient (because you now have two proofs, >>>>>>>>> each of which claims that 'I'm right so you're wrong'); one must attack
the reasoning or the assumptions (or both) and show how a flawed step >>>>>>>>> or a flawed assumption invalidates the method (and perhaps the >>>>>>>>> conclusion).
As it happens, Olcott accepts anyway that Turing's conclusion is >>>>>>>>> correct, so his only beef can be with an assumption or a step. >>>>>>>>>
Turing's conclusion *is correct within a false assumption*
Specifically, the assumption that the following requirements can be met:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X >>>>>>> described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the >>>>>>> following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
Yes, that is precisely the assumption Turing makes, and he makes it >>>>>> explicitly, and he makes it with the express intent of showing that it >>>>>> cannot be true.
YOU MUST PAY ATTENTION TO ALL THE WORDS THAT I SAY.
Noise on the line again, I see. I must call the broadband people.
HHH is not the computation Turing assumed could exist (for the sole >>>>>> purpose of showing that it could not). HHH is a hodgepodge of shit C >>>>>> and what looks like more line noise in assembly mnemonics. It is not a >>>>>> universal computation such as Turing envisaged:
Turing's only assumption is overturned by reductio within the proof >>>>>>>>> itself, so that can't be it... which only leaves steps.
As far as I can recall, Olcott's ramblings never go within discus- >>>>>>>>> throwing distance of a potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
False. "DDD" is a description/specification of algorithm DDD consisting >>>>>>> of the fixed code of the function DDD, the fixed code function HHH, and >>>>>>> the fixed code of everything that HHH calls down to the OS level. >>>>>>
+++++
Let us suppose that there is such a process; that is to say, that we >>>>>> can invent a machine <D- which, when supplied with the S.D of any
computing machine i l will test this S.D and if i l is circular will >>>>>> mark the S.D with the symbol "u" and if it is circle-free will mark it >>>>>> with " s ".
+++++
By "the S.D. of any computing machine" he means the 'standard
description' of >>>>any<<<< Turing machine.
HHH is not that process, and thus HHH has no bearing whatsoever on the >>>>>> Turing proof.
It is a verified fact that the
*input input input input input input*
*input input input input input input*
*input input input input input input*
*input input input input input input*
to HHH(DDD)
i.e. a description of algorithm DDD consisting of the fixed code of the >>>> function DDD, the fixed code of the function HHH, and the fixed code of >>>> everything that HHH calls down to the OS level.
Never stops running unless HHH aborts its emulation
In other words, if you change the input so that HHH doesn't abort.
Changing the input is not allowed.
I never changed the input you freaking moron.
On 2025-05-30 15:24:55 +0000, olcott said:
On 5/30/2025 3:42 AM, Fred. Zwarts wrote:
Op 29.mei.2025 om 18:42 schreef olcott:
On 5/29/2025 10:49 AM, Fred. Zwarts wrote:
Op 29.mei.2025 om 17:45 schreef olcott:
On 5/29/2025 3:33 AM, Mikko wrote:
On 2025-05-28 19:41:23 +0000, olcott said:
On 5/28/2025 1:54 PM, Fred. Zwarts wrote:
Op 28.mei.2025 om 17:02 schreef olcott:
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 16:51 schreef olcott:
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is >>>>>>>>>>>>>>> part of the input and specifies an abort, so the >>>>>>>>>>>>>>> program specified by the input halts. But HHH
Op 26.mei.2025 om 20:48 schreef olcott:
On 5/26/2025 1:34 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 18:21 schreef olcott: >>>>>>>>>>>>>>>>>>>> On 5/26/2025 11:11 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 17:25 schreef olcott: >>>>>>>>>>>>>>>>>>>>>> On 5/26/2025 3:42 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 04:22 schreef olcott: >>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 9:00 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 25/05/2025 21:30, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:05 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:56 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> *Mike understood this perfectly* >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> --------- Sipser quote ----- >>>>>>>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>
And that is the bug in HHH. It does not go >>>>>>>>>>>>>>>>>>>>> far enough.*No we are not. We are discussing this* >>>>>>>>>>>>>>>>>>>>>>Again you make the same mistake by not >>>>>>>>>>>>>>>>>>>>>>> only changing the decider, but also the >>>>>>>>>>>>>>>>>>>>>>> input.Just for the record:we can easily interpret that as >>>>>>>>>>>>>>>>>>>>>>>>>>>> saying exactly what I said a SHD >>>>>>>>>>>>>>>>>>>>>>>>>>>> does above. It tells PO that in the >>>>>>>>>>>>>>>>>>>>>>>>>>>> tight loop example, H correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates as far as [A], at which >>>>>>>>>>>>>>>>>>>>>>>>>>>> point it correctly determines that >>>>>>>>>>>>>>>>>>>>>>>>>>>> "its simulated input would never stop >>>>>>>>>>>>>>>>>>>>>>>>>>>> running unless aborted", so >>>>>>>>>>>>>>>>>>>>>>>>>>>> it can decide "non-halting". >>>>>>>>>>>>>>>>>>>>>>>>>>>>
All correct and natural, and no >>>>>>>>>>>>>>>>>>>>>>>>>>>> deliberately
false premises to mislead PO. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> https://al.howardknight.net/? >>>>>>>>>>>>>>>>>>>>>>>>>>>> STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- email.me%3E
And you dishonestly left out the part >>>>>>>>>>>>>>>>>>>>>>>>>>> that immediately follows where he >>>>>>>>>>>>>>>>>>>>>>>>>>> states that you are wrong: >>>>>>>>>>>>>>>>>>>>>>>>>>>
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor >>>>>>>>>>>>>>>>>>>>>>>>>> Sipser agreed to are exactly met >>>>>>>>>>>>>>>>>>>>>>>>>
1) I didn't offer any proofs of /anything/ >>>>>>>>>>>>>>>>>>>>>>>>>
- I did explain how Sipser's words can >>>>>>>>>>>>>>>>>>>>>>>>> be naturally interpreted as explaining >>>>>>>>>>>>>>>>>>>>>>>>> how a simulating halt decider can >>>>>>>>>>>>>>>>>>>>>>>>> operate. [That is not a proof.] >>>>>>>>>>>>>>>>>>>>>>>>>
It seems like proof to me.
When-so-ever anyone provides complete and >>>>>>>>>>>>>>>>>>>>>>>> correct reasoning
showing how an expression of language is >>>>>>>>>>>>>>>>>>>>>>>> true, this is a proof.
- I also explained why that explanation >>>>>>>>>>>>>>>>>>>>>>>>> *doesn't* apply to your HHH/ DDD pair >>>>>>>>>>>>>>>>>>>>>>>>>
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop >>>>>>>>>>>>>>>>>>>>>>>> running if simulated
far enough, but HHH simply /doesn't/ go >>>>>>>>>>>>>>>>>>>>>>>> far enough
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 >>>>>>>>>>>>>>>>>>>>>>>> // call HHH
[0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3] >>>>>>>>>>>>>>>>>>>>>>>>
I use the simpler DDD because everyone >>>>>>>>>>>>>>>>>>>>>>>> here gets
completely confused even by this simple >>>>>>>>>>>>>>>>>>>>>>>> example.
How many recursive emulations does HHH >>>>>>>>>>>>>>>>>>>>>>>> have to
wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>>>>>>> on its own without ever needing to be >>>>>>>>>>>>>>>>>>>>>>>> aborted?
Once you and I work through this one >>>>>>>>>>>>>>>>>>>>>>>> point I may
finally have complete closure.
We are discussing the input where DDD >>>>>>>>>>>>>>>>>>>>>>> calls a HHH that aborts after one cycle. >>>>>>>>>>>>>>>>>>>>>>
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop >>>>>>>>>>>>>>>>>>>>>> running if simulated
far enough, but HHH simply /doesn't/ go far >>>>>>>>>>>>>>>>>>>>>> enough
No Mike is just wrong.
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // >>>>>>>>>>>>>>>>>>>> call HHH
[0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>>>
No, *you* are just wrong.
A correct simulation needs only one recursion >>>>>>>>>>>>>>>>>>> more than the simulated HHH. The bug in HHH >>>>>>>>>>>>>>>>>>> is, that it aborts one cycle too early.
The outermost HHH always sees one whole
recursive emulation
more than the next inner one.
Only if you change the input with the simulator. >>>>>>>>>>>>>>>>> Every simulator that tries to simulate itself, >>>>>>>>>>>>>>>>> fails.
My code proves otherwise.
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>>>>
fails to see that. It does not even start to
simulate itself, but aborts at that point. So, it >>>>>>>>>>>>>>> is in no way a proof that your simulator is able >>>>>>>>>>>>>>> to simulate itself, let alone to simulate itself >>>>>>>>>>>>>>> correctly.
It is a verified fact that HHH does simulate itself >>>>>>>>>>>>>> simulating DDD.
If you are too incompetent to understand that this >>>>>>>>>>>>>> does not count
as a rebuttal.
It seems you do not understand what 'simulate'
means. HHH does not simulate itself, but aborts the
simulation at the point where the simulation of
itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some
false assumptions about itself, in particular it
assumes that 'itself' does not halt.
That you do not understand your own code is in no
way a rebuttal for my claim that no simulator is
able to simulate itself up to the end.
It seems you do not even understand what
'counter-factual' means. Your own traces show that the
simulation is aborted without simulating the call
instruction that calls HHH.
It does not show this.
New slave_stack at:14e33e
is the point where HHH begins simulating itself
simulating DDD.
We can see that this *is* happening because it derives the >>>>>>>>>> correct execution trace of DDD simulated by 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
You see? The call is not properly simulated.
No stupid you are wrong.
I prove that HHH is simulating itself simulating DDD
by the next lines of the correctly simulated DDD.
The trace of the simulation of HHH is not shown and the
trace of other
simulations do not prove that HHH is simulated. The traces
don't show
which simulator produced them.
If you don't know how to make a better output program you
are free to ask.
Mike has already verified this, see what he just said.
On 5/28/2025 8:02 PM, Mike Terry wrote:
Perhaps you slightly misunderstand the presented trace.
The instructions starting at 000015ee /are/ simulated,
but then simply suppressed from the output PO shows.
And he also added that it does not make a difference,
because HHH still forgets to count the conditional branch
instruction within the simulation of HHH.
Of course, you remove this most important part of his
contribution.
We must achieve 100% complete closure on each point
one-at-a-time and not endlessly flit back and forth
across many different points never achieving closure
on any of them.
THIS POINT IS NOW CLOSED
*HHH does correctly simulate itself simulating DDD*
If the simulation is meant to analyse the code, then it
doesn't, because it forgets to count the conditional branch
instruction during the simulation. Moreover, its does only a
partial simulation, because it skips the most important part
of the simulation, where it reaches its own 'ret' instruction.
So, the simplification that it does a correct simulation, is
not the full truth.
(The subject is bad faith and dishonesty, so this is relevant.)
Every computation that cannot possibly reach its own
final halt state is a non-terminating computation.
Every computation that can reach its own final halt state is a
terminating computation.
On 2025-05-30 18:40:01 +0000, olcott said:
to HHH(DDD)
does specify a non-halting sequence of configurations.
No, it is not. Nobody has seen the input to HHH(DDD) running
forever.
So the "non-halting" is not a verified fact.
On 2025-05-30 17:27:05 +0000, olcott said:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
As far as I can recall, Olcott's ramblings never go within
discus- throwing distance of a potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
We can apply Truing'c construction to every Truing machine and
prove that no Turing machine is a halting decider. With a
similar construction many other problems about Turing machine
behaviour can be proven uncomputable, too.
On 5/29/2025 1:40 PM, Richard Heathfield wrote:
On 29/05/2025 19:14, olcott wrote:
On 5/29/2025 12:40 PM, Richard Heathfield wrote:
On 29/05/2025 16:49, olcott wrote:
On 5/28/2025 4:16 PM, Richard Heathfield wrote:
On 28/05/2025 22:05, dbush wrote:
On 5/28/2025 2:38 PM, olcott wrote:
My only aim is to show that the conventional halting
problem proof is wrong.
But why would you care whether or not the proof is wrong when
you've gone on record (multiple times) as stating that what the
proof proves is correct?
It would certainly earn him a place in history's footnotes, which
might well be considered sufficient motive. But he'd have to be
able to explain why he's right, which of course he can't.
<snip>
See my post: [Disagreeing with tautologies is always incorrect]
And it seems you still can't.
I have already read your article "Disagreeing with tautologies is
always incorrect"[1], which completely fails to explain your proof.
Maybe you have no idea what a tautology is.
Maybe you think that asserting something is true is sufficient to make
it true. It isn't.
Its the same thing as a self-evident truth.
Maybe you think that asserting something is self-evidently true is
sufficient to make it self-evidently true. It isn't.
<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
It is a tautology that any input D to termination
analyzer H that *would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
But in making that claim you assume that you correctly know the
termination behaviour of D.
We only know this:
*simulated D would never stop running unless aborted*
and that is enough.
On 5/30/2025 1:57 PM, Richard Heathfield wrote:
On 30/05/2025 19:48, dbush wrote:
On 5/30/2025 2:40 PM, olcott wrote:
On 5/30/2025 1:20 PM, Richard Heathfield wrote:
<snip>
+++++
Let us suppose that there is such a process; that is to say, that
we can invent a machine <D- which, when supplied with the S.D of
any computing machine i l will test this S.D and if i l is circular
will mark the S.D with the symbol "u" and if it is circle-free will
mark it with " s ".
+++++
By "the S.D. of any computing machine" he means the 'standard
description' of >>>>any<<<< Turing machine.
HHH is not that process, and thus HHH has no bearing whatsoever on
the Turing proof.
It is a verified fact that
HHH is not that process, and thus HHH has no bearing whatsoever on the
Turing proof.
IT DOES YET YOU INSIST ON LYING ABOUT THIS.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The input to HHH(DD) SPECIFIES A NON-HALTING
SEQUENCE OF CONFIGURATIONS.
On 5/30/2025 10:29 AM, Mike Terry wrote:
On 30/05/2025 10:19, vallor wrote:
On Thu, 29 May 2025 19:40:57 +0100, Richard Heathfield <rjh@cpax.org.uk> >>> wrote in <101a9np$gl7$1@dont-email.me>:
On 29/05/2025 19:14, olcott wrote:
On 5/29/2025 12:40 PM, Richard Heathfield wrote:
On 29/05/2025 16:49, olcott wrote:Maybe you have no idea what a tautology is.
On 5/28/2025 4:16 PM, Richard Heathfield wrote:
On 28/05/2025 22:05, dbush wrote:See my post: [Disagreeing with tautologies is always incorrect]
On 5/28/2025 2:38 PM, olcott wrote:
My only aim is to show that the conventional halting problem >>>>>>>>>> proof
is wrong.
But why would you care whether or not the proof is wrong when >>>>>>>>> you've gone on record (multiple times) as stating that what the >>>>>>>>> proof proves is correct?
It would certainly earn him a place in history's footnotes, which >>>>>>>> might well be considered sufficient motive. But he'd have to be >>>>>>>> able
to explain why he's right, which of course he can't.
<snip>
And it seems you still can't.
I have already read your article "Disagreeing with tautologies is
always incorrect"[1], which completely fails to explain your proof. >>>>>
Maybe you think that asserting something is true is sufficient to make >>>> it true. It isn't.
Its the same thing as a self-evident truth.
Maybe you think that asserting something is self-evidently true is
sufficient to make it self-evidently true. It isn't.
<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
It is a tautology that any input D to termination analyzer H that
*would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
But in making that claim you assume that you correctly know the
termination behaviour of D.
I can easily sketch out a program that your HHH analyser would
impatiently abort as non-terminating, but which could conceivably stop >>>> running this year, next year, sometime... or never.
Was wondering when someone would mention that...what does his HHH()
do with arbitrary programs?
$ cat ddd.c
#include <stdio.h>
void ddd(int r)
{
r--;
if(r <= 0) return;
fprintf(stderr,"calling ddd(%d)\n",r);
ddd(r);
fprintf(stderr,"returning, r=%d\n",r);
return;
}
int main(void)
{
ddd(50);
return 0;
}
I'd bet his HHH() would say this is non-terminating.
It does what it does with DDD: it simulates the program while
monitoring the simulation progress, looking for what it considers to
be signs of non-halting behaviour. If it spots what it thinks is non-
halting behaviour, it decides non-halting. If the simulation halts,
it decides halts. Otherwise it will continue simulating indefinitely.
@Richard: so you cannot make HHH decide non-halting simply by looping
for a long long time, hoping HHH will get fed up! That would just
result in HHH simulating for a corresponding long long time. You need
to feed it a program that halts, but matches one of his non-halting
behaviour tests. For example DDD.
@vallor: so with your example, ddd halts, and I don't believe any of
HHH's tests would match, so HHH would simulate your ddd to completion
and decide it halts.
Mike.
When DDD is correctly emulated by HHH the first four
instructions of DDD are emulated. Then HHH(DDD) is
called from DDD then HHH emulates itself emulating DDD.
No matter how many times HHH emulates itself emulating
DDD the emulated DDD cannot possibly reach its "ret"
instruction final halt state. This proves that DDD emulated
by HHH is non-halting.
On 5/30/2025 11:31 AM, Mike Terry wrote:
On 30/05/2025 16:41, Richard Heathfield wrote:
On 30/05/2025 16:29, Mike Terry wrote:
@Richard: so you cannot make HHH decide non-halting simply by
looping for a long long time, hoping HHH will get fed up! That
would just result in HHH simulating for a corresponding long long
time. You need to feed it a program that halts, but matches one of
his non- halting behaviour tests. For example DDD.
What if I don't know whether it halts?
I followed up to vallor with a pseudocode sketch of such a program.
That was the Goldback Conjecture counter-example searcher? If it
halts it has found a counter-example, so GC is false. If it never
halts GC is true.
If GC were easy to prove/disprove it would have been settled a long
time ago. It is not going to be settled as a result of someone
writing a partial halt decider that decides your program. People have
already tested GC up to around 4000000000000000000. In practice, if
you gave your program to HHH you would just see HHH running and
running, which is not useful to anyone.
If HHH could deliver a reliably correct report for that program
within a year or so, that would probably be enough to earn Mr Olcott
a place in the history books.
HHH obviously cannot do that. Also, PO does not claim HHH is a (full)
halt decider, so it does not affect his claims.
We have two requirements:
But at some point we have to place a ceiling on "long long time". A
reporting program that keeps saying "maybe next year" isn't much of a
reporting program.
a) people want to actually /use/ real life halt analysis tools in
their daily work.
For such people, waiting a year for a result is no good, like you >> say.
HHH is not a candidate for people wanting such a real-life tool.
b) people want to understand the /theoretical/ limits of computation,
hence the Halting Problem.
The HP places no limits on how long a program can run, or how
much storage it can
consume. PO's HHH is an attempt to invalidate one particular
proof of HP. It does
not run for very long when running HHH/DDD, so we never have to
face the
"maybe next year" scenario. [Related HHH/DDD scenarios that
never halt are
easily seen to never halt by simple code analysis.]
Mike.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
The fact that DDD correctly emulated by HHH cannot
possibly stop running unless aborted and cannot
possibly reach its own "ret" instruction final halt
state conclusively proves that
the input to HHH(DDD)
specifies a
sequence of configurations.
On 5/30/2025 8:28 PM, dbush wrote:
On 5/30/2025 6:34 PM, olcott wrote:
On 5/30/2025 2:11 PM, dbush wrote:
On 5/30/2025 3:05 PM, olcott wrote:
On 5/30/2025 2:01 PM, dbush wrote:
On 5/30/2025 3:00 PM, olcott wrote:
On 5/30/2025 1:48 PM, dbush wrote:
On 5/30/2025 2:40 PM, olcott wrote:
On 5/30/2025 1:20 PM, Richard Heathfield wrote:
On 30/05/2025 18:45, dbush wrote:
On 5/30/2025 1:27 PM, olcott wrote:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:Specifically, the assumption that the following requirements >>>>>>>>>>> can be met:
There aren't many ways to invalidate a proof. Demonstrating >>>>>>>>>>>>> that the conclusion is false is insufficient (because you >>>>>>>>>>>>> now have two proofs, each of which claims that 'I'm right >>>>>>>>>>>>> so you're wrong'); one must attack the reasoning or the >>>>>>>>>>>>> assumptions (or both) and show how a flawed step or a >>>>>>>>>>>>> flawed assumption invalidates the method (and perhaps the >>>>>>>>>>>>> conclusion).
As it happens, Olcott accepts anyway that Turing's
conclusion is correct, so his only beef can be with an >>>>>>>>>>>>> assumption or a step.
Turing's conclusion *is correct within a false assumption* >>>>>>>>>>>
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that >>>>>>>>>>> computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed >>>>>>>>>>> directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when >>>>>>>>>>> executed directly
Yes, that is precisely the assumption Turing makes, and he >>>>>>>>>> makes it explicitly, and he makes it with the express intent >>>>>>>>>> of showing that it cannot be true.
YOU MUST PAY ATTENTION TO ALL THE WORDS THAT I SAY.
Noise on the line again, I see. I must call the broadband people. >>>>>>>>>>
Turing's only assumption is overturned by reductio within >>>>>>>>>>>>> the proof itself, so that can't be it... which only leaves >>>>>>>>>>>>> steps.
As far as I can recall, Olcott's ramblings never go within >>>>>>>>>>>>> discus- throwing distance of a potentially erroneous step. >>>>>>>>>>>>>
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
False. "DDD" is a description/specification of algorithm DDD >>>>>>>>>>> consisting of the fixed code of the function DDD, the fixed >>>>>>>>>>> code function HHH, and the fixed code of everything that HHH >>>>>>>>>>> calls down to the OS level.
HHH is not the computation Turing assumed could exist (for the >>>>>>>>>> sole purpose of showing that it could not). HHH is a
hodgepodge of shit C and what looks like more line noise in >>>>>>>>>> assembly mnemonics. It is not a universal computation such as >>>>>>>>>> Turing envisaged:
+++++
Let us suppose that there is such a process; that is to say, >>>>>>>>>> that we can invent a machine <D- which, when supplied with the >>>>>>>>>> S.D of any computing machine i l will test this S.D and if i l >>>>>>>>>> is circular will mark the S.D with the symbol "u" and if it is >>>>>>>>>> circle-free will mark it with " s ".
+++++
By "the S.D. of any computing machine" he means the 'standard >>>>>>>>>> description' of >>>>any<<<< Turing machine.
HHH is not that process, and thus HHH has no bearing
whatsoever on the Turing proof.
It is a verified fact that the
*input input input input input input*
*input input input input input input*
*input input input input input input*
*input input input input input input*
to HHH(DDD)
i.e. a description of algorithm DDD consisting of the fixed code >>>>>>>> of the function DDD, the fixed code of the function HHH, and the >>>>>>>> fixed code of everything that HHH calls down to the OS level.
Never stops running unless HHH aborts its emulation
In other words, if you change the input so that HHH doesn't abort. >>>>>>
Changing the input is not allowed.
I never changed the input you freaking moron.
You did exactly what when you hypothesized a different
implementation of function HHH. And since function HHH is part of
the input, you changed the input.
Changing the input, hypothetically or otherwise, is not allowed.
It can be seen by humans that DDD correctly simulated
by HHH would never stop running unless aborted.
In other words, if the code of HHH was changed to not abort, DDD would
not halt when executed directly. That changes the input.
Changing the input is not allowed.
When a human imagines all of the possibilities
of every HHH that can possibly exist
THIS IS NOT CHANGING THE INPUT YOU DAMNED LIAR.
On 5/30/2025 8:48 PM, dbush wrote:
On 5/30/2025 9:36 PM, olcott wrote:
On 5/30/2025 8:28 PM, dbush wrote:
On 5/30/2025 6:34 PM, olcott wrote:
On 5/30/2025 2:11 PM, dbush wrote:
On 5/30/2025 3:05 PM, olcott wrote:
On 5/30/2025 2:01 PM, dbush wrote:
On 5/30/2025 3:00 PM, olcott wrote:
On 5/30/2025 1:48 PM, dbush wrote:
On 5/30/2025 2:40 PM, olcott wrote:
On 5/30/2025 1:20 PM, Richard Heathfield wrote:
On 30/05/2025 18:45, dbush wrote:
On 5/30/2025 1:27 PM, olcott wrote:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:Specifically, the assumption that the following
There aren't many ways to invalidate a proof.
Demonstrating that the conclusion is false is
insufficient (because you now have two proofs, each of >>>>>>>>>>>>>>> which claims that 'I'm right so you're wrong'); one must >>>>>>>>>>>>>>> attack the reasoning or the assumptions (or both) and >>>>>>>>>>>>>>> show how a flawed step or a flawed assumption invalidates >>>>>>>>>>>>>>> the method (and perhaps the conclusion).
As it happens, Olcott accepts anyway that Turing's >>>>>>>>>>>>>>> conclusion is correct, so his only beef can be with an >>>>>>>>>>>>>>> assumption or a step.
Turing's conclusion *is correct within a false assumption* >>>>>>>>>>>>>
requirements can be met:
Given any algorithm (i.e. a fixed immutable sequence of >>>>>>>>>>>>> instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that >>>>>>>>>>>>> computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed >>>>>>>>>>>>> directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when >>>>>>>>>>>>> executed directly
Yes, that is precisely the assumption Turing makes, and he >>>>>>>>>>>> makes it explicitly, and he makes it with the express intent >>>>>>>>>>>> of showing that it cannot be true.
YOU MUST PAY ATTENTION TO ALL THE WORDS THAT I SAY.
Noise on the line again, I see. I must call the broadband >>>>>>>>>>>> people.
Turing's only assumption is overturned by reductio within >>>>>>>>>>>>>>> the proof itself, so that can't be it... which only >>>>>>>>>>>>>>> leaves steps.
As far as I can recall, Olcott's ramblings never go >>>>>>>>>>>>>>> within discus- throwing distance of a potentially >>>>>>>>>>>>>>> erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
False. "DDD" is a description/specification of algorithm >>>>>>>>>>>>> DDD consisting of the fixed code of the function DDD, the >>>>>>>>>>>>> fixed code function HHH, and the fixed code of everything >>>>>>>>>>>>> that HHH calls down to the OS level.
HHH is not the computation Turing assumed could exist (for >>>>>>>>>>>> the sole purpose of showing that it could not). HHH is a >>>>>>>>>>>> hodgepodge of shit C and what looks like more line noise in >>>>>>>>>>>> assembly mnemonics. It is not a universal computation such >>>>>>>>>>>> as Turing envisaged:
+++++
Let us suppose that there is such a process; that is to say, >>>>>>>>>>>> that we can invent a machine <D- which, when supplied with >>>>>>>>>>>> the S.D of any computing machine i l will test this S.D and >>>>>>>>>>>> if i l is circular will mark the S.D with the symbol "u" and >>>>>>>>>>>> if it is circle-free will mark it with " s ".
+++++
By "the S.D. of any computing machine" he means the
'standard description' of >>>>any<<<< Turing machine.
HHH is not that process, and thus HHH has no bearing
whatsoever on the Turing proof.
It is a verified fact that the
*input input input input input input*
*input input input input input input*
*input input input input input input*
*input input input input input input*
to HHH(DDD)
i.e. a description of algorithm DDD consisting of the fixed >>>>>>>>>> code of the function DDD, the fixed code of the function HHH, >>>>>>>>>> and the fixed code of everything that HHH calls down to the OS >>>>>>>>>> level.
Never stops running unless HHH aborts its emulation
In other words, if you change the input so that HHH doesn't abort. >>>>>>>>
Changing the input is not allowed.
I never changed the input you freaking moron.
You did exactly what when you hypothesized a different
implementation of function HHH. And since function HHH is part of >>>>>> the input, you changed the input.
Changing the input, hypothetically or otherwise, is not allowed.
It can be seen by humans that DDD correctly simulated
by HHH would never stop running unless aborted.
In other words, if the code of HHH was changed to not abort, DDD
would not halt when executed directly. That changes the input.
Changing the input is not allowed.
When a human imagines all of the possibilities
of every HHH that can possibly exist
You change the input,
I am taking about a set of concepts
that you hold in your own mind, jackass.
On 31/05/2025 10:42, Mikko wrote:
On 2025-05-30 17:27:05 +0000, olcott said:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
<snip>
As far as I can recall, Olcott's ramblings never go within discus- throwing distance of a
potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
We can apply Truing'c construction to every Truing machine and
prove that no Turing machine is a halting decider. With a
similar construction many other problems about Turing machine
behaviour can be proven uncomputable, too.
Indeed. In fact, if I'm reading Mr Olcott's retort correctly...
Turing: imagine a program P...
Turing: ...argument goes here...
Turing: ...and it turns out that P can't exist.
Olcott: Turing is wrong, because P can't exist.
I /seeeeee.../
On 5/31/2025 5:49 AM, Fred. Zwarts wrote:
Op 30.mei.2025 om 17:31 schreef olcott:
On 5/29/2025 1:40 PM, Richard Heathfield wrote:Talking about dishonesty. It is simply not true that simulated D would
On 29/05/2025 19:14, olcott wrote:
On 5/29/2025 12:40 PM, Richard Heathfield wrote:
On 29/05/2025 16:49, olcott wrote:Maybe you have no idea what a tautology is.
On 5/28/2025 4:16 PM, Richard Heathfield wrote:
On 28/05/2025 22:05, dbush wrote:
On 5/28/2025 2:38 PM, olcott wrote:
My only aim is to show that the conventional halting
problem proof is wrong.
But why would you care whether or not the proof is wrong when >>>>>>>>> you've gone on record (multiple times) as stating that what the >>>>>>>>> proof proves is correct?
It would certainly earn him a place in history's footnotes,
which might well be considered sufficient motive. But he'd have >>>>>>>> to be able to explain why he's right, which of course he can't. >>>>>>>>
<snip>
See my post: [Disagreeing with tautologies is always incorrect]
And it seems you still can't.
I have already read your article "Disagreeing with tautologies is
always incorrect"[1], which completely fails to explain your proof. >>>>>
Maybe you think that asserting something is true is sufficient to
make it true. It isn't.
Its the same thing as a self-evident truth.
Maybe you think that asserting something is self-evidently true is
sufficient to make it self-evidently true. It isn't.
<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
It is a tautology that any input D to termination
analyzer H that *would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
But in making that claim you assume that you correctly know the
termination behaviour of D.
We only know this:
*simulated D would never stop running unless aborted*
and that is enough.
never stop running unless aborted. It suggests that the input given to
H specifies a non-halting program. But it doesn't. The input includes
D. D, in turn, has addresses of other functions, including the
functions that abort and halt.
In other words you don't understand what "never aborted" means.
We only know this:
*simulated D would never stop running unless aborted*
and that is enough.
So, the input specifies a halting program.
World-class simulators show that no abort is needed. The simulation of
the program specified with this input has a natural end.
On 5/31/2025 7:38 AM, dbush wrote:
On 5/30/2025 11:34 PM, olcott wrote:
On 5/30/2025 8:48 PM, dbush wrote:
On 5/30/2025 9:36 PM, olcott wrote:
On 5/30/2025 8:28 PM, dbush wrote:
On 5/30/2025 6:34 PM, olcott wrote:
On 5/30/2025 2:11 PM, dbush wrote:
On 5/30/2025 3:05 PM, olcott wrote:It can be seen by humans that DDD correctly simulated
On 5/30/2025 2:01 PM, dbush wrote:
On 5/30/2025 3:00 PM, olcott wrote:
On 5/30/2025 1:48 PM, dbush wrote:
On 5/30/2025 2:40 PM, olcott wrote:
It is a verified fact that the
*input input input input input input*
*input input input input input input*
*input input input input input input*
*input input input input input input*
to HHH(DDD)
i.e. a description of algorithm DDD consisting of the fixed >>>>>>>>>>>> code of the function DDD, the fixed code of the function >>>>>>>>>>>> HHH, and the fixed code of everything that HHH calls down to >>>>>>>>>>>> the OS level.
Never stops running unless HHH aborts its emulation
In other words, if you change the input so that HHH doesn't >>>>>>>>>> abort.
Changing the input is not allowed.
I never changed the input you freaking moron.
You did exactly what when you hypothesized a different
implementation of function HHH. And since function HHH is part >>>>>>>> of the input, you changed the input.
Changing the input, hypothetically or otherwise, is not allowed. >>>>>>>
by HHH would never stop running unless aborted.
In other words, if the code of HHH was changed to not abort, DDD
would not halt when executed directly. That changes the input.
Changing the input is not allowed.
When a human imagines all of the possibilities
of every HHH that can possibly exist
You change the input,
I am taking about a set of concepts
that you hold in your own mind, jackass.
And those set of concepts change the input as described below.
Only if your brain is an x86 processor with unlimited RAM.
So you are finally admitting that you are a bot?
On 5/31/2025 4:22 AM, Mikko wrote:
On 2025-05-30 15:32:48 +0000, olcott said:
On 5/30/2025 4:16 AM, Mikko wrote:
On 2025-05-29 01:37:49 +0000, Richard Damon said:
On 5/28/25 10:54 AM, olcott wrote:
On 5/28/2025 3:35 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 17:31 schreef olcott:
On 5/27/2025 3:37 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 04:22 schreef olcott:
On 5/26/2025 9:09 PM, Richard Damon wrote:Counter-factual. There is no need to prevent infinite
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:Unless HHH(DDD) aborts its emulation of DDD then
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>>
So much bad faith and dishonesty shown in this forum >>>>>>>>>>>>>>>>>> that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests >>>>>>>>>>>>>>>>> against dishonesty.
If you could remove all dishonesty the protests woud >>>>>>>>>>>>>>>>> stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according >>>>>>>>>>>>>>>> to the rules of the x86 language cannot possibly reach >>>>>>>>>>>>>>>> its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to >>>>>>>>>>>>>>> from the beginning
to end.
I am asking you to affirm that I am correct about this point. >>>>>>>>>>>>>> DDD simulated by HHH according to the rules of the x86 >>>>>>>>>>>>>> language cannot possibly reach its own "ret" instruction >>>>>>>>>>>>>> final halt state, thus is correctly rejected as non-halting. >>>>>>>>>>>>>>
But you have to affirm first that HHH *IS* a program that >>>>>>>>>>>>> does that, and can't be "changed" to some other program, >>>>>>>>>>>>> and that DDD is "completed" to contain that same code. >>>>>>>>>>>>>
Of course, once you define that HHH is such a program, >>>>>>>>>>>>
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a >>>>>>>>>>> fact that DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
It is a tautology that every input that must be
aborted to prevent the infinite simulation of this
input DOES SPECIFY NON-HALTING BEHAVIOR.
simulation, because the input includes DDD with all functions >>>>>>>>> called by DDD, including the code in Halt7.c that specifies the >>>>>>>>> abort.
Unless the outmost HHH aborts then none of them
abort because they all of the exact same machine code.
Only when you also change the input. Changing input from a HHH
that aborts to a HHH that does not abort is changing the subject. >>>>>>>
It either every HHH aborts or no HHH aborts
because they all have the same machine code.
And if every HHH aborts and returns 0, then every DDD will Halt.
If no HHH aborts, then no HHH ever answers.
In both cases, it is wrong.
And if every HHH aborts and returns 1 then every DDD will halt. In
this case HHH is right. But in this case HHH is not Olcott's HHH.
Abort must return 0, 1 is only returned when an input
reaches its own final halt state.
int main()
{
DDD(); // the HHH that DDD calls is not supposed to
} // report on the behavior of its caller.
// It is supposed to report on the behavior
// that its input specifies.
When DDD is correctly emulated by HHH the first four
instructions of DDD are emulated. When HHH(DDD) is
called from DDD then HHH emulates itself emulating DDD.
No matter how many times HHH emulates itself emulating
DDD the emulated DDD cannot possibly reach its "ret"
instruction final halt state. This proves that DDD emulated
by HHH is non-halting.
That does not contradict what I said above.
What you said above contradicts itself.
On 5/31/2025 4:13 AM, Mikko wrote:
On 2025-05-30 15:24:55 +0000, olcott said:
On 5/30/2025 3:42 AM, Fred. Zwarts wrote:
Op 29.mei.2025 om 18:42 schreef olcott:
On 5/29/2025 10:49 AM, Fred. Zwarts wrote:
Op 29.mei.2025 om 17:45 schreef olcott:We must achieve 100% complete closure on each point
On 5/29/2025 3:33 AM, Mikko wrote:
On 2025-05-28 19:41:23 +0000, olcott said:
On 5/28/2025 1:54 PM, Fred. Zwarts wrote:
Op 28.mei.2025 om 17:02 schreef olcott:
On 5/28/2025 3:40 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 16:51 schreef olcott:It does not show this.
On 5/27/2025 3:33 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:44 schreef olcott:
On 5/26/2025 2:30 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 21:11 schreef olcott:
On 5/26/2025 2:02 PM, Fred. Zwarts wrote:Your code proves exactly my point. That Halt7.c is part >>>>>>>>>>>>>>>> of the input and specifies an abort, so the program >>>>>>>>>>>>>>>> specified by the input halts. But HHH fails to see that. >>>>>>>>>>>>>>>> It does not even start to simulate itself, but aborts at >>>>>>>>>>>>>>>> that point. So, it is in no way a proof that your >>>>>>>>>>>>>>>> simulator is able to simulate itself, let alone to >>>>>>>>>>>>>>>> simulate itself correctly.
Op 26.mei.2025 om 20:48 schreef olcott:My code proves otherwise.
On 5/26/2025 1:34 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 18:21 schreef olcott: >>>>>>>>>>>>>>>>>>>>> On 5/26/2025 11:11 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 17:25 schreef olcott: >>>>>>>>>>>>>>>>>>>>>>> On 5/26/2025 3:42 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>>>>> Op 26.mei.2025 om 04:22 schreef olcott: >>>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 9:00 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 25/05/2025 21:30, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:05 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/25/2025 3:56 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> *Mike understood this perfectly* >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --------- Sipser quote ----- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
And that is the bug in HHH. It does not go far >>>>>>>>>>>>>>>>>>>>>> enough.*No we are not. We are discussing this* >>>>>>>>>>>>>>>>>>>>>>>Just for the record:we can easily interpret that as saying >>>>>>>>>>>>>>>>>>>>>>>>>>>>> exactly what I said a SHD >>>>>>>>>>>>>>>>>>>>>>>>>>>>> does above. It tells PO that in the tight >>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop example, H correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates as far as [A], at which point it >>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly determines that >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "its simulated input would never stop >>>>>>>>>>>>>>>>>>>>>>>>>>>>> running unless aborted", so >>>>>>>>>>>>>>>>>>>>>>>>>>>>> it can decide "non-halting". >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
All correct and natural, and no deliberately >>>>>>>>>>>>>>>>>>>>>>>>>>>>> false premises to mislead PO. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
On 5/14/2025 7:36 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://al.howardknight.net/? >>>>>>>>>>>>>>>>>>>>>>>>>>>>> STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- email.me%3E
And you dishonestly left out the part that >>>>>>>>>>>>>>>>>>>>>>>>>>>> immediately follows where he states that you >>>>>>>>>>>>>>>>>>>>>>>>>>>> are wrong:
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser >>>>>>>>>>>>>>>>>>>>>>>>>>> agreed to are exactly met >>>>>>>>>>>>>>>>>>>>>>>>>>
1) I didn't offer any proofs of /anything/ >>>>>>>>>>>>>>>>>>>>>>>>>>
- I did explain how Sipser's words can be >>>>>>>>>>>>>>>>>>>>>>>>>> naturally interpreted as explaining >>>>>>>>>>>>>>>>>>>>>>>>>> how a simulating halt decider can operate. >>>>>>>>>>>>>>>>>>>>>>>>>> [That is not a proof.]
It seems like proof to me.
When-so-ever anyone provides complete and >>>>>>>>>>>>>>>>>>>>>>>>> correct reasoning
showing how an expression of language is true, >>>>>>>>>>>>>>>>>>>>>>>>> this is a proof.
- I also explained why that explanation >>>>>>>>>>>>>>>>>>>>>>>>>> *doesn't* apply to your HHH/ DDD pair >>>>>>>>>>>>>>>>>>>>>>>>>>
Yes you did do this.
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if >>>>>>>>>>>>>>>>>>>>>>>>> simulated
far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>>>>>>>
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // >>>>>>>>>>>>>>>>>>>>>>>>> call HHH
[0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3] >>>>>>>>>>>>>>>>>>>>>>>>>
I use the simpler DDD because everyone here gets >>>>>>>>>>>>>>>>>>>>>>>>> completely confused even by this simple example. >>>>>>>>>>>>>>>>>>>>>>>>>
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>>>>>>>>
Once you and I work through this one point I may >>>>>>>>>>>>>>>>>>>>>>>>> finally have complete closure. >>>>>>>>>>>>>>>>>>>>>>>> Again you make the same mistake by not only >>>>>>>>>>>>>>>>>>>>>>>> changing the decider, but also the input. >>>>>>>>>>>>>>>>>>>>>>>> We are discussing the input where DDD calls a >>>>>>>>>>>>>>>>>>>>>>>> HHH that aborts after one cycle. >>>>>>>>>>>>>>>>>>>>>>>
*On 5/14/2025 7:36 PM, Mike Terry wrote* >>>>>>>>>>>>>>>>>>>>>>> the simulated input (DD) /does/ stop running if >>>>>>>>>>>>>>>>>>>>>>> simulated
far enough, but HHH simply /doesn't/ go far enough >>>>>>>>>>>>>>>>>>>>>>>
No Mike is just wrong.
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192 >>>>>>>>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04 >>>>>>>>>>>>>>>>>>>>> [000021a2] 5d pop ebp >>>>>>>>>>>>>>>>>>>>> [000021a3] c3 ret >>>>>>>>>>>>>>>>>>>>> Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to >>>>>>>>>>>>>>>>>>>>> wait before its emulated DDD magically halts >>>>>>>>>>>>>>>>>>>>> on its own without ever needing to be aborted? >>>>>>>>>>>>>>>>>>>>>
No, *you* are just wrong.
A correct simulation needs only one recursion more >>>>>>>>>>>>>>>>>>>> than the simulated HHH. The bug in HHH is, that it >>>>>>>>>>>>>>>>>>>> aborts one cycle too early.
The outermost HHH always sees one whole recursive >>>>>>>>>>>>>>>>>>> emulation
more than the next inner one.
Only if you change the input with the simulator. >>>>>>>>>>>>>>>>>> Every simulator that tries to simulate itself, fails. >>>>>>>>>>>>>>>>>
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>>>>>
It is a verified fact that HHH does simulate itself >>>>>>>>>>>>>>> simulating DDD.
If you are too incompetent to understand that this does >>>>>>>>>>>>>>> not count
as a rebuttal.
It seems you do not understand what 'simulate' means. HHH >>>>>>>>>>>>>> does not simulate itself, but aborts the simulation at the >>>>>>>>>>>>>> point where the simulation of itself should start.
Counter-factual, nitwit.
It does not simulate itself, but only makes some false >>>>>>>>>>>>>> assumptions about itself, in particular it assumes that >>>>>>>>>>>>>> 'itself' does not halt.
That you do not understand your own code is in no way a >>>>>>>>>>>>>> rebuttal for my claim that no simulator is able to >>>>>>>>>>>>>> simulate itself up to the end.
It seems you do not even understand what 'counter-factual' >>>>>>>>>>>> means. Your own traces show that the simulation is aborted >>>>>>>>>>>> without simulating the call instruction that calls HHH. >>>>>>>>>>>
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD. >>>>>>>>>>> We can see that this *is* happening because it derives the >>>>>>>>>>> correct execution trace of DDD simulated by 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
You see? The call is not properly simulated.
No stupid you are wrong.
I prove that HHH is simulating itself simulating DDD
by the next lines of the correctly simulated DDD.
The trace of the simulation of HHH is not shown and the trace of >>>>>>>> other
simulations do not prove that HHH is simulated. The traces don't >>>>>>>> show
which simulator produced them.
If you don't know how to make a better output program you are
free to ask.
Mike has already verified this, see what he just said.
On 5/28/2025 8:02 PM, Mike Terry wrote:
Perhaps you slightly misunderstand the presented trace.
The instructions starting at 000015ee /are/ simulated,
but then simply suppressed from the output PO shows.
And he also added that it does not make a difference, because HHH
still forgets to count the conditional branch instruction within
the simulation of HHH.
Of course, you remove this most important part of his contribution. >>>>>
one-at-a-time and not endlessly flit back and forth
across many different points never achieving closure
on any of them.
THIS POINT IS NOW CLOSED
*HHH does correctly simulate itself simulating DDD*
If the simulation is meant to analyse the code, then it doesn't,
because it forgets to count the conditional branch instruction
during the simulation. Moreover, its does only a partial simulation,
because it skips the most important part of the simulation, where it
reaches its own 'ret' instruction.
So, the simplification that it does a correct simulation, is not the
full truth.
(The subject is bad faith and dishonesty, so this is relevant.)
Every computation that cannot possibly reach its own
final halt state is a non-terminating computation.
Every computation that can reach its own final halt state is a
terminating computation.
DDD correctly emulated by any HHH that can possibly
exist cannot reach its own emulated final halt state.
On 5/31/2025 4:50 AM, Mikko wrote:
On 2025-05-30 19:05:07 +0000, olcott said:
On 5/30/2025 2:01 PM, dbush wrote:
On 5/30/2025 3:00 PM, olcott wrote:
On 5/30/2025 1:48 PM, dbush wrote:
On 5/30/2025 2:40 PM, olcott wrote:
On 5/30/2025 1:20 PM, Richard Heathfield wrote:
On 30/05/2025 18:45, dbush wrote:
On 5/30/2025 1:27 PM, olcott wrote:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
There aren't many ways to invalidate a proof. Demonstrating >>>>>>>>>>> that the conclusion is false is insufficient (because you now >>>>>>>>>>> have two proofs, each of which claims that 'I'm right so >>>>>>>>>>> you're wrong'); one must attack the reasoning or the
assumptions (or both) and show how a flawed step or a flawed >>>>>>>>>>> assumption invalidates the method (and perhaps the conclusion). >>>>>>>>>>>
As it happens, Olcott accepts anyway that Turing's conclusion >>>>>>>>>>> is correct, so his only beef can be with an assumption or a >>>>>>>>>>> step.
Turing's conclusion *is correct within a false assumption*
Specifically, the assumption that the following requirements >>>>>>>>> can be met:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when
executed directly
Yes, that is precisely the assumption Turing makes, and he makes >>>>>>>> it explicitly, and he makes it with the express intent of
showing that it cannot be true.
YOU MUST PAY ATTENTION TO ALL THE WORDS THAT I SAY.
Noise on the line again, I see. I must call the broadband people. >>>>>>>>
Turing's only assumption is overturned by reductio within the >>>>>>>>>>> proof itself, so that can't be it... which only leaves steps. >>>>>>>>>>>
As far as I can recall, Olcott's ramblings never go within >>>>>>>>>>> discus- throwing distance of a potentially erroneous step. >>>>>>>>>>>
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
False. "DDD" is a description/specification of algorithm DDD >>>>>>>>> consisting of the fixed code of the function DDD, the fixed
code function HHH, and the fixed code of everything that HHH >>>>>>>>> calls down to the OS level.
HHH is not the computation Turing assumed could exist (for the >>>>>>>> sole purpose of showing that it could not). HHH is a hodgepodge >>>>>>>> of shit C and what looks like more line noise in assembly
mnemonics. It is not a universal computation such as Turing
envisaged:
+++++
Let us suppose that there is such a process; that is to say,
that we can invent a machine <D- which, when supplied with the >>>>>>>> S.D of any computing machine i l will test this S.D and if i l >>>>>>>> is circular will mark the S.D with the symbol "u" and if it is >>>>>>>> circle-free will mark it with " s ".
+++++
By "the S.D. of any computing machine" he means the 'standard
description' of >>>>any<<<< Turing machine.
HHH is not that process, and thus HHH has no bearing whatsoever >>>>>>>> on the Turing proof.
It is a verified fact that the
*input input input input input input*
*input input input input input input*
*input input input input input input*
*input input input input input input*
to HHH(DDD)
i.e. a description of algorithm DDD consisting of the fixed code
of the function DDD, the fixed code of the function HHH, and the
fixed code of everything that HHH calls down to the OS level.
Never stops running unless HHH aborts its emulation
In other words, if you change the input so that HHH doesn't abort.
Changing the input is not allowed.
I never changed the input you freaking moron.
You did change the meaning of he input.
Examining a set of ideas within one's own mind
IS NOT CHANGING THE INPUT.
On 5/31/2025 5:49 AM, Fred. Zwarts wrote:
Op 30.mei.2025 om 17:31 schreef olcott:
On 5/29/2025 1:40 PM, Richard Heathfield wrote:Talking about dishonesty. It is simply not true that simulated D would
On 29/05/2025 19:14, olcott wrote:
On 5/29/2025 12:40 PM, Richard Heathfield wrote:
On 29/05/2025 16:49, olcott wrote:Maybe you have no idea what a tautology is.
On 5/28/2025 4:16 PM, Richard Heathfield wrote:
On 28/05/2025 22:05, dbush wrote:
On 5/28/2025 2:38 PM, olcott wrote:
My only aim is to show that the conventional halting
problem proof is wrong.
But why would you care whether or not the proof is wrong when >>>>>>>>> you've gone on record (multiple times) as stating that what the >>>>>>>>> proof proves is correct?
It would certainly earn him a place in history's footnotes,
which might well be considered sufficient motive. But he'd have >>>>>>>> to be able to explain why he's right, which of course he can't. >>>>>>>>
<snip>
See my post: [Disagreeing with tautologies is always incorrect]
And it seems you still can't.
I have already read your article "Disagreeing with tautologies is
always incorrect"[1], which completely fails to explain your proof. >>>>>
Maybe you think that asserting something is true is sufficient to
make it true. It isn't.
Its the same thing as a self-evident truth.
Maybe you think that asserting something is self-evidently true is
sufficient to make it self-evidently true. It isn't.
<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
It is a tautology that any input D to termination
analyzer H that *would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
But in making that claim you assume that you correctly know the
termination behaviour of D.
We only know this:
*simulated D would never stop running unless aborted*
and that is enough.
never stop running unless aborted. It suggests that the input given to
H specifies a non-halting program. But it doesn't. The input includes
D. D, in turn, has addresses of other functions, including the
functions that abort and halt.
In other words you don't understand what "never aborted" means.
So, the input specifies a halting program.
World-class simulators show that no abort is needed. The simulation of
the program specified with this input has a natural end.
On 5/31/2025 4:22 AM, Mikko wrote:
On 2025-05-30 15:32:48 +0000, olcott said:
On 5/30/2025 4:16 AM, Mikko wrote:
On 2025-05-29 01:37:49 +0000, Richard Damon said:
On 5/28/25 10:54 AM, olcott wrote:
On 5/28/2025 3:35 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 17:31 schreef olcott:
On 5/27/2025 3:37 AM, Fred. Zwarts wrote:
Op 27.mei.2025 om 04:22 schreef olcott:
On 5/26/2025 9:09 PM, Richard Damon wrote:Counter-factual. There is no need to prevent infinite simulation, >>>>>>>>> because the input includes DDD with all functions called by DDD, >>>>>>>>> including the code in Halt7.c that specifies the abort.
On 5/26/25 6:05 PM, olcott wrote:
On 5/26/2025 3:44 PM, Richard Damon wrote:
On 5/26/25 11:29 AM, olcott wrote:Unless HHH(DDD) aborts its emulation of DDD then
On 5/26/2025 5:04 AM, Mikko wrote:
On 2025-05-25 14:36:26 +0000, olcott said:
On 5/25/2025 1:21 AM, Mikko wrote:
On 2025-05-24 01:20:18 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>>
So much bad faith and dishonesty shown in this forum that myself and Peter
Olcott have to fight against.
Everything here seems to be dishonesty and protests against dishonesty.
If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.
_DDD()
[00002192] 55 push ebp >>>>>>>>>>>>>>>> [00002193] 8bec mov ebp,esp >>>>>>>>>>>>>>>> [00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Then acknowledge that DDD simulated by HHH according >>>>>>>>>>>>>>>> to the rules of the x86 language cannot possibly reach >>>>>>>>>>>>>>>> its own "ret" instruction final halt state.
I have never claimed that your HHH can simulate DDD to from the beginning
to end.
I am asking you to affirm that I am correct about this point. >>>>>>>>>>>>>> DDD simulated by HHH according to the rules of the x86 >>>>>>>>>>>>>> language cannot possibly reach its own "ret" instruction >>>>>>>>>>>>>> final halt state, thus is correctly rejected as non-halting. >>>>>>>>>>>>>>
But you have to affirm first that HHH *IS* a program that does that,
and can't be "changed" to some other program, and that DDD is >>>>>>>>>>>>> "completed" to contain that same code.
Of course, once you define that HHH is such a program, >>>>>>>>>>>>
DDD() and HHH() never stop running proving that
the input to HHH(DDD) SPECIFIES NON-TERMINATING
BEHAVIOR THAT MUST BE ABORTED.
But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that
DDD() will halt.
*Termination analyzers PREDICT behavior dip-shit*
It is a tautology that every input that must be
aborted to prevent the infinite simulation of this
input DOES SPECIFY NON-HALTING BEHAVIOR.
Unless the outmost HHH aborts then none of them
abort because they all of the exact same machine code.
Only when you also change the input. Changing input from a HHH that >>>>>>> aborts to a HHH that does not abort is changing the subject.
It either every HHH aborts or no HHH aborts
because they all have the same machine code.
And if every HHH aborts and returns 0, then every DDD will Halt.
If no HHH aborts, then no HHH ever answers.
In both cases, it is wrong.
And if every HHH aborts and returns 1 then every DDD will halt. In
this case HHH is right. But in this case HHH is not Olcott's HHH.
Abort must return 0, 1 is only returned when an input
reaches its own final halt state.
int main()
{
DDD(); // the HHH that DDD calls is not supposed to
} // report on the behavior of its caller.
// It is supposed to report on the behavior
// that its input specifies.
When DDD is correctly emulated by HHH the first four
instructions of DDD are emulated. When HHH(DDD) is
called from DDD then HHH emulates itself emulating DDD.
No matter how many times HHH emulates itself emulating
DDD the emulated DDD cannot possibly reach its "ret"
instruction final halt state. This proves that DDD emulated
by HHH is non-halting.
That does not contradict what I said above.
What you said above contradicts itself.
On 31/05/2025 10:46, Mikko wrote:
On 2025-05-30 18:40:01 +0000, olcott said:
<snip>
to HHH(DDD)
does specify a non-halting sequence of configurations.
No, it is not. Nobody has seen the input to HHH(DDD) running forever.
So the "non-halting" is not a verified fact.
The unfailingly patient Mike Terry will forgive me if I have remembered
him incorrectly, but I seem to recall... wait... I can quote him:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Just as a reminder I'll repeat the final outcome of all this:
- PO's H does decide NEVER_HALTS for TM H^ running with input <H^>.
- PO's H^ running with input <H^> in fact halts, in line with Linz
logic (b) above. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
...so it halts. End of, one would think.
On 31/05/2025 10:42, Mikko wrote:
On 2025-05-30 17:27:05 +0000, olcott said:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
<snip>
As far as I can recall, Olcott's ramblings never go within discus-
throwing distance of a potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
We can apply Truing'c construction to every Truing machine and
prove that no Turing machine is a halting decider. With a
similar construction many other problems about Turing machine
behaviour can be proven uncomputable, too.
Indeed. In fact, if I'm reading Mr Olcott's retort correctly...
Turing: imagine a program P...
Turing: ...argument goes here...
Turing: ...and it turns out that P can't exist.
Olcott: Turing is wrong, because P can't exist.
I /seeeeee.../
On 5/31/2025 4:50 AM, Mikko wrote:
On 2025-05-30 19:05:07 +0000, olcott said:
On 5/30/2025 2:01 PM, dbush wrote:
On 5/30/2025 3:00 PM, olcott wrote:
On 5/30/2025 1:48 PM, dbush wrote:
On 5/30/2025 2:40 PM, olcott wrote:
On 5/30/2025 1:20 PM, Richard Heathfield wrote:
On 30/05/2025 18:45, dbush wrote:
On 5/30/2025 1:27 PM, olcott wrote:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
There aren't many ways to invalidate a proof. Demonstrating that the
conclusion is false is insufficient (because you now have two proofs,
each of which claims that 'I'm right so you're wrong'); one must attack
the reasoning or the assumptions (or both) and show how a flawed step
or a flawed assumption invalidates the method (and perhaps the >>>>>>>>>>> conclusion).
As it happens, Olcott accepts anyway that Turing's conclusion is >>>>>>>>>>> correct, so his only beef can be with an assumption or a step. >>>>>>>>>>>
Turing's conclusion *is correct within a false assumption*
Specifically, the assumption that the following requirements can be met:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the >>>>>>>>> following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
Yes, that is precisely the assumption Turing makes, and he makes it >>>>>>>> explicitly, and he makes it with the express intent of showing that it >>>>>>>> cannot be true.
YOU MUST PAY ATTENTION TO ALL THE WORDS THAT I SAY.
Noise on the line again, I see. I must call the broadband people. >>>>>>>>
HHH is not the computation Turing assumed could exist (for the sole >>>>>>>> purpose of showing that it could not). HHH is a hodgepodge of shit C >>>>>>>> and what looks like more line noise in assembly mnemonics. It is not a >>>>>>>> universal computation such as Turing envisaged:
Turing's only assumption is overturned by reductio within the proof >>>>>>>>>>> itself, so that can't be it... which only leaves steps.
As far as I can recall, Olcott's ramblings never go within discus- >>>>>>>>>>> throwing distance of a potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
False. "DDD" is a description/specification of algorithm DDD consisting
of the fixed code of the function DDD, the fixed code function HHH, and
the fixed code of everything that HHH calls down to the OS level. >>>>>>>>
+++++
Let us suppose that there is such a process; that is to say, that we >>>>>>>> can invent a machine <D- which, when supplied with the S.D of any >>>>>>>> computing machine i l will test this S.D and if i l is circular will >>>>>>>> mark the S.D with the symbol "u" and if it is circle-free will mark it >>>>>>>> with " s ".
+++++
By "the S.D. of any computing machine" he means the 'standard
description' of >>>>any<<<< Turing machine.
HHH is not that process, and thus HHH has no bearing whatsoever on the >>>>>>>> Turing proof.
It is a verified fact that the
*input input input input input input*
*input input input input input input*
*input input input input input input*
*input input input input input input*
to HHH(DDD)
i.e. a description of algorithm DDD consisting of the fixed code of the >>>>>> function DDD, the fixed code of the function HHH, and the fixed code of >>>>>> everything that HHH calls down to the OS level.
Never stops running unless HHH aborts its emulation
In other words, if you change the input so that HHH doesn't abort.
Changing the input is not allowed.
I never changed the input you freaking moron.
You did change the meaning of he input.
Examining a set of ideas within one's own mind
IS NOT CHANGING THE INPUT.
On 5/31/2025 8:37 AM, Mike Terry wrote:
On 31/05/2025 11:03, Richard Heathfield wrote:
On 31/05/2025 10:42, Mikko wrote:
On 2025-05-30 17:27:05 +0000, olcott said:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
<snip>
As far as I can recall, Olcott's ramblings never go within discus- >>>>>> throwing distance of a potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
We can apply Truing'c construction to every Truing machine and
prove that no Turing machine is a halting decider. With a
similar construction many other problems about Turing machine
behaviour can be proven uncomputable, too.
Indeed. In fact, if I'm reading Mr Olcott's retort correctly...
Turing: imagine a program P...
Turing: ...argument goes here...
Turing: ...and it turns out that P can't exist.
Olcott: Turing is wrong, because P can't exist.
I /seeeeee.../
More like:
Turing: imagine a program P...
Turing: ...modify P as follows to create D...
Turing: ...argument goes here...
Turing: ...so P decides D's halting incorrectly
Turing: ...and so P is not a halt decider.
Olcott: Turing is wrong, because *D* can't exist.
I /seeeeee.../
Mike.
Turing wasn't even dealing with halting.
*Here is the orignal Linz proof*
https://www.liarparadox.org/Linz_Proof.pdf
In the following embedded_H is P and ⟨Ĥ⟩ is D
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
On 5/31/2025 5:49 AM, Fred. Zwarts wrote:
Op 30.mei.2025 om 17:31 schreef olcott:
On 5/29/2025 1:40 PM, Richard Heathfield wrote:Talking about dishonesty. It is simply not true that simulated D would
On 29/05/2025 19:14, olcott wrote:
On 5/29/2025 12:40 PM, Richard Heathfield wrote:
On 29/05/2025 16:49, olcott wrote:Maybe you have no idea what a tautology is.
On 5/28/2025 4:16 PM, Richard Heathfield wrote:
On 28/05/2025 22:05, dbush wrote:
On 5/28/2025 2:38 PM, olcott wrote:
My only aim is to show that the conventional halting
problem proof is wrong.
But why would you care whether or not the proof is wrong when you've >>>>>>>>> gone on record (multiple times) as stating that what the proof proves >>>>>>>>> is correct?
It would certainly earn him a place in history's footnotes, which might
well be considered sufficient motive. But he'd have to be able to >>>>>>>> explain why he's right, which of course he can't.
<snip>
See my post: [Disagreeing with tautologies is always incorrect]
And it seems you still can't.
I have already read your article "Disagreeing with tautologies is
always incorrect"[1], which completely fails to explain your proof. >>>>>
Maybe you think that asserting something is true is sufficient to make >>>> it true. It isn't.
Its the same thing as a self-evident truth.
Maybe you think that asserting something is self-evidently true is
sufficient to make it self-evidently true. It isn't.
<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
It is a tautology that any input D to termination
analyzer H that *would never stop running unless aborted*
DOES SPECIFY NON-TERMINATING BEHAVIOR.
But in making that claim you assume that you correctly know the
termination behaviour of D.
We only know this:
*simulated D would never stop running unless aborted*
and that is enough.
never stop running unless aborted. It suggests that the input given to
H specifies a non-halting program. But it doesn't. The input includes
D. D, in turn, has addresses of other functions, including the
functions that abort and halt.
In other words you don't understand what "never aborted" means.
On 5/31/2025 4:42 AM, Mikko wrote:
On 2025-05-30 17:27:05 +0000, olcott said:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
On 30/05/2025 17:31, Mike Terry wrote:
On 30/05/2025 16:41, Richard Heathfield wrote:
On 30/05/2025 16:29, Mike Terry wrote:That was the Goldback Conjecture counter-example searcher?
@Richard: so you cannot make HHH decide non-halting simply by looping >>>>>>> for a long long time, hoping HHH will get fed up! That would just >>>>>>> result in HHH simulating for a corresponding long long time. You need >>>>>>> to feed it a program that halts, but matches one of his non-halting >>>>>>> behaviour tests. For example DDD.
What if I don't know whether it halts?
I followed up to vallor with a pseudocode sketch of such a program. >>>>>
Yes.
If it halts it has found a counter-example, so GC is false. If it
never halts GC is true.
Right.
If GC were easy to prove/disprove it would have been settled a long time ago.
...precisely why I chose it.
It is not going to be settled as a result of someone writing a partial >>>>> halt decider that decides your program.
Indeed.
People have already tested GC up to around 4000000000000000000. In >>>>> practice, if you gave your program to HHH you would just see HHH
running and running, which is not useful to anyone.
So it doesn't report.
If HHH could deliver a reliably correct report for that program within >>>>>> a year or so, that would probably be enough to earn Mr Olcott a place >>>>>> in the history books.
HHH obviously cannot do that. Also, PO does not claim HHH is a (full) >>>>> halt decider, so it does not affect his claims.
I know, but I was mildly curious to know whether it would abort or wait >>>> forever, a point you have now addressed, for which my thanks.
Quite so.But at some point we have to place a ceiling on "long long time". A >>>>>> reporting program that keeps saying "maybe next year" isn't much of a >>>>>> reporting program.We have two requirements:
a) people want to actually /use/ real life halt analysis
tools in their daily work. For such people, waiting a year for
a result is no good, like you say. HHH is not a candidate for
people wanting such a real-life tool.
b) people want to understand the /theoretical/ limits of computation, >>>>> hence the Halting Problem. The HP places no
limits on how long a program can run, or how much storage it
can consume. PO's HHH is an attempt to invalidate one particular proof >>>>> of HP. It does not run for very long when
running HHH/DDD, so we never have to face the "maybe next
year" scenario. [Related HHH/DDD scenarios that never halt
are easily seen to never halt by simple code analysis.]
There aren't many ways to invalidate a proof. Demonstrating that the
conclusion is false is insufficient (because you now have two proofs,
each of which claims that 'I'm right so you're wrong'); one must attack >>>> the reasoning or the assumptions (or both) and show how a flawed step
or a flawed assumption invalidates the method (and perhaps the
conclusion).
As it happens, Olcott accepts anyway that Turing's conclusion is
correct, so his only beef can be with an assumption or a step.
Turing's conclusion *is correct within a false assumption*
YOU MUST PAY ATTENTION TO ALL THE WORDS THAT I SAY.
Turing's only assumption is overturned by reductio within the proof
itself, so that can't be it... which only leaves steps.
As far as I can recall, Olcott's ramblings never go within discus-
throwing distance of a potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
We can apply Truing'c construction to every Truing machine and prove that
no Turing machine is a halting decider. With a similar construction many
other problems about Turing machine behaviour can be proven uncomputable,
too.
*Turing was never talking about halting*
On 5/31/2025 4:46 AM, Mikko wrote:
On 2025-05-30 18:40:01 +0000, olcott said:
On 5/30/2025 1:20 PM, Richard Heathfield wrote:
On 30/05/2025 18:45, dbush wrote:
On 5/30/2025 1:27 PM, olcott wrote:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
There aren't many ways to invalidate a proof. Demonstrating that the >>>>>>> conclusion is false is insufficient (because you now have two proofs, >>>>>>> each of which claims that 'I'm right so you're wrong'); one must attack >>>>>>> the reasoning or the assumptions (or both) and show how a flawed step >>>>>>> or a flawed assumption invalidates the method (and perhaps the
conclusion).
As it happens, Olcott accepts anyway that Turing's conclusion is >>>>>>> correct, so his only beef can be with an assumption or a step.
Turing's conclusion *is correct within a false assumption*
Specifically, the assumption that the following requirements can be met: >>>>>
Given any algorithm (i.e. a fixed immutable sequence of instructions) X >>>>> described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the >>>>> following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
Yes, that is precisely the assumption Turing makes, and he makes it
explicitly, and he makes it with the express intent of showing that it >>>> cannot be true.
YOU MUST PAY ATTENTION TO ALL THE WORDS THAT I SAY.
Noise on the line again, I see. I must call the broadband people.
Turing's only assumption is overturned by reductio within the proof >>>>>>> itself, so that can't be it... which only leaves steps.
As far as I can recall, Olcott's ramblings never go within discus- >>>>>>> throwing distance of a potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
False. "DDD" is a description/specification of algorithm DDD consisting >>>>> of the fixed code of the function DDD, the fixed code function HHH, and >>>>> the fixed code of everything that HHH calls down to the OS level.
HHH is not the computation Turing assumed could exist (for the sole
purpose of showing that it could not). HHH is a hodgepodge of shit C
and what looks like more line noise in assembly mnemonics. It is not a >>>> universal computation such as Turing envisaged:
+++++
Let us suppose that there is such a process; that is to say, that we
can invent a machine <D- which, when supplied with the S.D of any
computing machine i l will test this S.D and if i l is circular will
mark the S.D with the symbol "u" and if it is circle-free will mark it >>>> with " s ".
+++++
By "the S.D. of any computing machine" he means the 'standard
description' of >>>>any<<<< Turing machine.
HHH is not that process, and thus HHH has no bearing whatsoever on the >>>> Turing proof.
It is a verified fact that the
*input input input input input input*
*input input input input input input*
*input input input input input input*
*input input input input input input*
to HHH(DDD)
does specify a non-halting sequence of configurations.
No, it is not. Nobody has seen the input to HHH(DDD) running forever.
So the "non-halting" is not a verified fact.
When N steps of DDD are correctly emulated by each
HHH that can possibly exist no emulated DDD ever
reaches its own emulated "ret" instruction (final
halt state).
On 2025-05-31 15:12:57 +0000, olcott said:
On 5/31/2025 8:37 AM, Mike Terry wrote:
On 31/05/2025 11:03, Richard Heathfield wrote:
On 31/05/2025 10:42, Mikko wrote:
On 2025-05-30 17:27:05 +0000, olcott said:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
<snip>
As far as I can recall, Olcott's ramblings never go within discus- throwing distance of a
potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
We can apply Truing'c construction to every Truing machine and
prove that no Turing machine is a halting decider. With a
similar construction many other problems about Turing machine
behaviour can be proven uncomputable, too.
Indeed. In fact, if I'm reading Mr Olcott's retort correctly...
Turing: imagine a program P...
Turing: ...argument goes here...
Turing: ...and it turns out that P can't exist.
Olcott: Turing is wrong, because P can't exist.
I /seeeeee.../
More like:
Turing: imagine a program P...
Turing: ...modify P as follows to create D...
Turing: ...argument goes here...
Turing: ...so P decides D's halting incorrectly
Turing: ...and so P is not a halt decider.
Olcott: Turing is wrong, because *D* can't exist.
I /seeeeee.../
Mike.
Turing wasn't even dealing with halting.
No, but he proved that there are problems that are not Turing decidable.
That halting is one of them can be proven with an adaptation of Turing's proof.
The question Turing wanted to solve is whether a computation writes infinitely many unerasable symbols. A computation that halts doesn't.
*Here is the orignal Linz proof*
https://www.liarparadox.org/Linz_Proof.pdf
Linz' presentation of the proof is not as good as it could be.
Linz is not careful with details. For example, the formulas in
the definition 12.1 specify to configurations (and a relation
between them) but does not specify which tape location is under
the head.
On 6/1/2025 11:22 AM, Mike Terry wrote:
On 01/06/2025 10:48, Mikko wrote:
On 2025-05-31 15:12:57 +0000, olcott said:
On 5/31/2025 8:37 AM, Mike Terry wrote:
On 31/05/2025 11:03, Richard Heathfield wrote:
On 31/05/2025 10:42, Mikko wrote:
On 2025-05-30 17:27:05 +0000, olcott said:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
<snip>
As far as I can recall, Olcott's ramblings never go within
discus- throwing distance of a potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
We can apply Truing'c construction to every Truing machine and
prove that no Turing machine is a halting decider. With a
similar construction many other problems about Turing machine
behaviour can be proven uncomputable, too.
Indeed. In fact, if I'm reading Mr Olcott's retort correctly...
Turing: imagine a program P...
Turing: ...argument goes here...
Turing: ...and it turns out that P can't exist.
Olcott: Turing is wrong, because P can't exist.
I /seeeeee.../
More like:
Turing: imagine a program P...
Turing: ...modify P as follows to create D...
Turing: ...argument goes here...
Turing: ...so P decides D's halting incorrectly
Turing: ...and so P is not a halt decider.
Olcott: Turing is wrong, because *D* can't exist.
I /seeeeee.../
Mike.
Turing wasn't even dealing with halting.
No, but he proved that there are problems that are not Turing decidable. >>> That halting is one of them can be proven with an adaptation of Turing's >>> proof.
The question Turing wanted to solve is whether a computation writes
infinitely many unerasable symbols. A computation that halts doesn't.
*Here is the orignal Linz proof*
https://www.liarparadox.org/Linz_Proof.pdf
Linz' presentation of the proof is not as good as it could be.
Linz is not careful with details. For example, the formulas in
the definition 12.1 specify to configurations (and a relation
between them) but does not specify which tape location is under
the head.
Linz's notation does specify the tape head location. In his notation
aQb,
where a,b are strings of the tape alphabet, and Q is a TM state, the
meaning is that the TM is in state Q, and the tape contains string ab
(concatenation of a and b), and the tape head is about to read the
first character of b.
You're right that Linz's presentation is not completely careful. He
is aiming at CS students specifically without any special mathematical
background. Where I see lack of care, I also see that it would be
clear how to address that issue if required, so it is not a big issue
for me.
Mike.
He made the big mistake of have two start states
in the same sequence of configurations.
On 6/1/2025 11:22 AM, Mike Terry wrote:
On 01/06/2025 10:48, Mikko wrote:
On 2025-05-31 15:12:57 +0000, olcott said:
On 5/31/2025 8:37 AM, Mike Terry wrote:
On 31/05/2025 11:03, Richard Heathfield wrote:
On 31/05/2025 10:42, Mikko wrote:
On 2025-05-30 17:27:05 +0000, olcott said:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
<snip>
As far as I can recall, Olcott's ramblings never go within discus- >>>>>>>>> throwing distance of a potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
We can apply Truing'c construction to every Truing machine and
prove that no Turing machine is a halting decider. With a
similar construction many other problems about Turing machine
behaviour can be proven uncomputable, too.
Indeed. In fact, if I'm reading Mr Olcott's retort correctly...
Turing: imagine a program P...
Turing: ...argument goes here...
Turing: ...and it turns out that P can't exist.
Olcott: Turing is wrong, because P can't exist.
I /seeeeee.../
More like:
Turing: imagine a program P...
Turing: ...modify P as follows to create D...
Turing: ...argument goes here...
Turing: ...so P decides D's halting incorrectly
Turing: ...and so P is not a halt decider.
Olcott: Turing is wrong, because *D* can't exist.
I /seeeeee.../
Mike.
Turing wasn't even dealing with halting.
No, but he proved that there are problems that are not Turing decidable. >>> That halting is one of them can be proven with an adaptation of Turing's >>> proof.
The question Turing wanted to solve is whether a computation writes
infinitely many unerasable symbols. A computation that halts doesn't.
*Here is the orignal Linz proof*
https://www.liarparadox.org/Linz_Proof.pdf
Linz' presentation of the proof is not as good as it could be.
Linz is not careful with details. For example, the formulas in
the definition 12.1 specify to configurations (and a relation
between them) but does not specify which tape location is under
the head.
Linz's notation does specify the tape head location. In his notation
aQb,
where a,b are strings of the tape alphabet, and Q is a TM state, the
meaning is that the TM is in state Q, and the tape contains string ab
(concatenation of a and b), and the tape head is about to read the
first character of b.
You're right that Linz's presentation is not completely careful. He is
aiming at CS students specifically without any special mathematical
background. Where I see lack of care, I also see that it would be
clear how to address that issue if required, so it is not a big issue
for me.
Mike.
He made the big mistake of have two start states
in the same sequence of configurations.
On 01/06/2025 10:48, Mikko wrote:
On 2025-05-31 15:12:57 +0000, olcott said:
On 5/31/2025 8:37 AM, Mike Terry wrote:
On 31/05/2025 11:03, Richard Heathfield wrote:
On 31/05/2025 10:42, Mikko wrote:
On 2025-05-30 17:27:05 +0000, olcott said:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
<snip>
As far as I can recall, Olcott's ramblings never go within discus- >>>>>>>> throwing distance of a potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
We can apply Truing'c construction to every Truing machine and
prove that no Turing machine is a halting decider. With a
similar construction many other problems about Turing machine
behaviour can be proven uncomputable, too.
Indeed. In fact, if I'm reading Mr Olcott's retort correctly...
Turing: imagine a program P...
Turing: ...argument goes here...
Turing: ...and it turns out that P can't exist.
Olcott: Turing is wrong, because P can't exist.
I /seeeeee.../
More like:
Turing: imagine a program P...
Turing: ...modify P as follows to create D...
Turing: ...argument goes here...
Turing: ...so P decides D's halting incorrectly
Turing: ...and so P is not a halt decider.
Olcott: Turing is wrong, because *D* can't exist.
I /seeeeee.../
Mike.
Turing wasn't even dealing with halting.
No, but he proved that there are problems that are not Turing decidable.
That halting is one of them can be proven with an adaptation of Turing's
proof.
The question Turing wanted to solve is whether a computation writes
infinitely many unerasable symbols. A computation that halts doesn't.
*Here is the orignal Linz proof*
https://www.liarparadox.org/Linz_Proof.pdf
Linz' presentation of the proof is not as good as it could be.
Linz is not careful with details. For example, the formulas in
the definition 12.1 specify to configurations (and a relation
between them) but does not specify which tape location is under
the head.
Linz's notation does specify the tape head location. In his notation
aQb,
where a,b are strings of the tape alphabet, and Q is a TM state, the
meaning is that the TM is in state Q, and the tape contains string ab (concatenation of a and b), and the tape head is about to read the
first character of b.
You're right that Linz's presentation is not completely careful. He is aiming at CS students specifically without any special mathematical background. Where I see lack of care, I also see that it would be
clear how to address that issue if required, so it is not a big issue
for me.
On 6/1/2025 8:24 PM, Richard Damon wrote:
On 6/1/25 12:36 PM, olcott wrote:
On 6/1/2025 11:22 AM, Mike Terry wrote:
On 01/06/2025 10:48, Mikko wrote:
On 2025-05-31 15:12:57 +0000, olcott said:
On 5/31/2025 8:37 AM, Mike Terry wrote:
On 31/05/2025 11:03, Richard Heathfield wrote:
On 31/05/2025 10:42, Mikko wrote:
On 2025-05-30 17:27:05 +0000, olcott said:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
<snip>
As far as I can recall, Olcott's ramblings never go within >>>>>>>>>>> discus- throwing distance of a potentially erroneous step. >>>>>>>>>>There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
We can apply Truing'c construction to every Truing machine and >>>>>>>>> prove that no Turing machine is a halting decider. With a
similar construction many other problems about Turing machine >>>>>>>>> behaviour can be proven uncomputable, too.
Indeed. In fact, if I'm reading Mr Olcott's retort correctly... >>>>>>>>
Turing: imagine a program P...
Turing: ...argument goes here...
Turing: ...and it turns out that P can't exist.
Olcott: Turing is wrong, because P can't exist.
I /seeeeee.../
More like:
Turing: imagine a program P...
Turing: ...modify P as follows to create D...
Turing: ...argument goes here...
Turing: ...so P decides D's halting incorrectly
Turing: ...and so P is not a halt decider.
Olcott: Turing is wrong, because *D* can't exist.
I /seeeeee.../
Mike.
Turing wasn't even dealing with halting.
No, but he proved that there are problems that are not Turing
decidable.
That halting is one of them can be proven with an adaptation of
Turing's
proof.
The question Turing wanted to solve is whether a computation writes
infinitely many unerasable symbols. A computation that halts doesn't. >>>>>
*Here is the orignal Linz proof*
https://www.liarparadox.org/Linz_Proof.pdf
Linz' presentation of the proof is not as good as it could be.
Linz is not careful with details. For example, the formulas in
the definition 12.1 specify to configurations (and a relation
between them) but does not specify which tape location is under
the head.
Linz's notation does specify the tape head location. In his notation
aQb,
where a,b are strings of the tape alphabet, and Q is a TM state, the
meaning is that the TM is in state Q, and the tape contains string
ab (concatenation of a and b), and the tape head is about to read
the first character of b.
You're right that Linz's presentation is not completely careful. He
is aiming at CS students specifically without any special
mathematical background. Where I see lack of care, I also see that
it would be clear how to address that issue if required, so it is
not a big issue for me.
Mike.
He made the big mistake of have two start states
in the same sequence of configurations.
No, you are forgetting that which one of the two lines you use is based
This is the error that Ben said that I caught.
His definition of Ĥ has two q0 start states one after the other. https://www.liarparadox.org/Linz_Proof.pdf
On 6/2/2025 1:49 AM, Mikko wrote:
On 2025-06-01 16:36:00 +0000, olcott said:
On 6/1/2025 11:22 AM, Mike Terry wrote:
On 01/06/2025 10:48, Mikko wrote:
On 2025-05-31 15:12:57 +0000, olcott said:
On 5/31/2025 8:37 AM, Mike Terry wrote:
On 31/05/2025 11:03, Richard Heathfield wrote:
On 31/05/2025 10:42, Mikko wrote:
On 2025-05-30 17:27:05 +0000, olcott said:
On 5/30/2025 12:06 PM, Richard Heathfield wrote:
<snip>
As far as I can recall, Olcott's ramblings never go within discus- >>>>>>>>>>> throwing distance of a potentially erroneous step.
There is no *INPUT* D to termination analyzer H
that can possibly do the opposite of whatever
value that H returns.
We can apply Truing'c construction to every Truing machine and >>>>>>>>> prove that no Turing machine is a halting decider. With a
similar construction many other problems about Turing machine >>>>>>>>> behaviour can be proven uncomputable, too.
Indeed. In fact, if I'm reading Mr Olcott's retort correctly... >>>>>>>>
Turing: imagine a program P...
Turing: ...argument goes here...
Turing: ...and it turns out that P can't exist.
Olcott: Turing is wrong, because P can't exist.
I /seeeeee.../
More like:
Turing: imagine a program P...
Turing: ...modify P as follows to create D...
Turing: ...argument goes here...
Turing: ...so P decides D's halting incorrectly
Turing: ...and so P is not a halt decider.
Olcott: Turing is wrong, because *D* can't exist.
I /seeeeee.../
Mike.
Turing wasn't even dealing with halting.
No, but he proved that there are problems that are not Turing decidable. >>>>> That halting is one of them can be proven with an adaptation of Turing's >>>>> proof.
The question Turing wanted to solve is whether a computation writes
infinitely many unerasable symbols. A computation that halts doesn't. >>>>>
*Here is the orignal Linz proof*
https://www.liarparadox.org/Linz_Proof.pdf
Linz' presentation of the proof is not as good as it could be.
Linz is not careful with details. For example, the formulas in
the definition 12.1 specify to configurations (and a relation
between them) but does not specify which tape location is under
the head.
Linz's notation does specify the tape head location. In his notation
aQb,
where a,b are strings of the tape alphabet, and Q is a TM state, the
meaning is that the TM is in state Q, and the tape contains string ab
(concatenation of a and b), and the tape head is about to read the
first character of b.
You're right that Linz's presentation is not completely careful. He is >>>> aiming at CS students specifically without any special mathematical
background. Where I see lack of care, I also see that it would be
clear how to address that issue if required, so it is not a big issue
for me.
Mike.
He made the big mistake of have two start states
in the same sequence of configurations.
That is one of the things that would be easy fix if required.
*I corrected it and made it much easier to understand*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 181:13:48 |
| Calls: | 9,705 |
| Files: | 13,737 |
| Messages: | 6,179,426 |