On 6/6/2024 9:08 PM, Richard Damon wrote:
On 6/6/24 9:06 AM, olcott wrote:
On 6/6/2024 6:11 AM, Richard Damon wrote:
On 6/6/24 12:14 AM, olcott wrote:
On 6/5/2024 11:06 PM, Richard Damon wrote:
On 6/6/24 12:04 AM, olcott wrote:
On 6/5/2024 10:58 PM, Richard Damon wrote:
On 6/5/24 11:44 PM, olcott wrote:
On 6/5/2024 10:41 PM, Richard Damon wrote:
On 6/5/24 11:11 PM, olcott wrote:
On 6/5/2024 10:05 PM, Richard Damon wrote:
On 6/5/24 10:43 PM, olcott wrote:
On 6/5/2024 9:25 PM, Richard Damon wrote:
On 6/5/24 9:31 PM, olcott wrote:
On 6/5/2024 8:27 PM, Richard Damon wrote:
On 6/5/24 9:18 PM, olcott wrote:
On 6/5/2024 8:07 PM, Richard Damon wrote:
Nopoe, because it is based on the LIE that a partial >>>>>>>>>>>>>>>>>> simulation of a machine indicates what it will do >>>>>>>>>>>>>>>>>> after the simulation stopped, and that the simulation >>>>>>>>>>>>>>>>>> of a DIFFERENT machine tells you of the behavior of a >>>>>>>>>>>>>>>>>> different machine then simulated.
*I will dumb it down for you some more*
Try any show how this DD can be correctly simulated by >>>>>>>>>>>>>>>>> any HH
such that this DD reaches past its machine address >>>>>>>>>>>>>>>>> [00001dbe]
I never said it could, you just are stuck in a bad >>>>>>>>>>>>>>>> question.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>> THAT I AM INCORRECT
Then you aren't going to get anywhere, because I just >>>>>>>>>>>>>> don't care about that worthless claim. Only when you cross >>>>>>>>>>>>>> the line from talking about the SUBJECTIVE answer that HH >>>>>>>>>>>>>> saw, to the OBJECTIVE behavior of the machine the input >>>>>>>>>>>>>> represents to a Halt Decider, will you get me caring, and >>>>>>>>>>>>>> slapping you down hard with a factual rebuttal.
*I will dumb it down for you some more*
Try any show how this DD can be correctly simulated by >>>>>>>>>>>>>>> any HH
such that this DD reaches past its machine address >>>>>>>>>>>>>>> [00001dbe]
But I don't claim that it can. I won't go to the effort to >>>>>>>>>>>>>> confirm that it can't, because, frankly, I don't give a >>>>>>>>>>>>>> damn because it is MEANINGLESS.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, >>>>>>>>>>>> because I am not willing to put that effort into your
worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT
UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE
THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct,
because I am not willing to put that effort into your
worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT
UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE
THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct,
because I am not willing to put that effort into your worthless >>>>>>>> claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT
UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE
THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, because
I am not willing to put that effort into your worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT
UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE
THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, because I
am not willing to put that effort into your worthless claim.
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
THUS THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT UNTIL
YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, because I am
not willing to put that effort into your worthless claim.
Then I am no longer willing to talk to you.
It is not a worthless claim it is the validation of the
essence of my life's work.
On 6/6/2024 10:29 PM, Richard Damon wrote:
On 6/6/24 11:04 PM, olcott wrote:
On 6/6/2024 9:56 PM, olcott wrote:
On 6/6/2024 9:08 PM, Richard Damon wrote:
On 6/6/24 9:06 AM, olcott wrote:
On 6/6/2024 6:11 AM, Richard Damon wrote:
On 6/6/24 12:14 AM, olcott wrote:
On 6/5/2024 11:06 PM, Richard Damon wrote:
On 6/6/24 12:04 AM, olcott wrote:
On 6/5/2024 10:58 PM, Richard Damon wrote:
On 6/5/24 11:44 PM, olcott wrote:
On 6/5/2024 10:41 PM, Richard Damon wrote:
On 6/5/24 11:11 PM, olcott wrote:
On 6/5/2024 10:05 PM, Richard Damon wrote:
On 6/5/24 10:43 PM, olcott wrote:
On 6/5/2024 9:25 PM, Richard Damon wrote:
On 6/5/24 9:31 PM, olcott wrote:
On 6/5/2024 8:27 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 6/5/24 9:18 PM, olcott wrote:
On 6/5/2024 8:07 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> Nopoe, because it is based on the LIE that a >>>>>>>>>>>>>>>>>>>>> partial simulation of a machine indicates what it >>>>>>>>>>>>>>>>>>>>> will do after the simulation stopped, and that the >>>>>>>>>>>>>>>>>>>>> simulation of a DIFFERENT machine tells you of the >>>>>>>>>>>>>>>>>>>>> behavior of a different machine then simulated. >>>>>>>>>>>>>>>>>>>>
*I will dumb it down for you some more* >>>>>>>>>>>>>>>>>>>> Try any show how this DD can be correctly simulated >>>>>>>>>>>>>>>>>>>> by any HH
such that this DD reaches past its machine address >>>>>>>>>>>>>>>>>>>> [00001dbe]
I never said it could, you just are stuck in a bad >>>>>>>>>>>>>>>>>>> question.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>>>>> THAT I AM INCORRECT
Then you aren't going to get anywhere, because I just >>>>>>>>>>>>>>>>> don't care about that worthless claim. Only when you >>>>>>>>>>>>>>>>> cross the line from talking about the SUBJECTIVE answer >>>>>>>>>>>>>>>>> that HH saw, to the OBJECTIVE behavior of the machine >>>>>>>>>>>>>>>>> the input represents to a Halt Decider, will you get me >>>>>>>>>>>>>>>>> caring, and slapping you down hard with a factual >>>>>>>>>>>>>>>>> rebuttal.
*I will dumb it down for you some more*
Try any show how this DD can be correctly simulated by >>>>>>>>>>>>>>>>>> any HH
such that this DD reaches past its machine address >>>>>>>>>>>>>>>>>> [00001dbe]
But I don't claim that it can. I won't go to the effort >>>>>>>>>>>>>>>>> to confirm that it can't, because, frankly, I don't >>>>>>>>>>>>>>>>> give a damn because it is MEANINGLESS.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, >>>>>>>>>>>>>>> because I am not willing to put that effort into your >>>>>>>>>>>>>>> worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, >>>>>>>>>>>>> because I am not willing to put that effort into your >>>>>>>>>>>>> worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE
THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, >>>>>>>>>>> because I am not willing to put that effort into your
worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT
UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE
THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct,
because I am not willing to put that effort into your worthless >>>>>>>>> claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT
UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE
THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, because >>>>>>> I am not willing to put that effort into your worthless claim.
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
THUS THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT UNTIL
YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, because I
am not willing to put that effort into your worthless claim.
Then I am no longer willing to talk to you.
It is not a worthless claim it is the validation of the
essence of my life's work.
My relentless pursuit did eventually wear you down so that
you finally admitted that you have been simply dodging the
point for three years with CHANGE-THE-SUBJECT strawman deception
fake rebuttals.
Nope, I guess you are just admitting via projection that your
arguement have no real basis of facts to work with.
You lie about this. You say right above that you insist
on refusing to look at these verified facts thus showing
your true colors for all the world to see.
Try any show how this DD can be correctly simulated by any HH
such that this DD reaches past its machine address [00001dbe]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
On 6/7/2024 10:14 AM, Richard Damon wrote:
On 6/6/24 11:53 PM, olcott wrote:
On 6/6/2024 10:29 PM, Richard Damon wrote:
On 6/6/24 11:04 PM, olcott wrote:
On 6/6/2024 9:56 PM, olcott wrote:
On 6/6/2024 9:08 PM, Richard Damon wrote:
On 6/6/24 9:06 AM, olcott wrote:
On 6/6/2024 6:11 AM, Richard Damon wrote:But, as I said, I won't acknowledge that you are correct, because >>>>>>> I am not willing to put that effort into your worthless claim.
On 6/6/24 12:14 AM, olcott wrote:
On 6/5/2024 11:06 PM, Richard Damon wrote:
On 6/6/24 12:04 AM, olcott wrote:
On 6/5/2024 10:58 PM, Richard Damon wrote:
On 6/5/24 11:44 PM, olcott wrote:
On 6/5/2024 10:41 PM, Richard Damon wrote:
On 6/5/24 11:11 PM, olcott wrote:
On 6/5/2024 10:05 PM, Richard Damon wrote:
On 6/5/24 10:43 PM, olcott wrote:
On 6/5/2024 9:25 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 6/5/24 9:31 PM, olcott wrote:
On 6/5/2024 8:27 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 6/5/24 9:18 PM, olcott wrote:
On 6/5/2024 8:07 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> Nopoe, because it is based on the LIE that a >>>>>>>>>>>>>>>>>>>>>>> partial simulation of a machine indicates what it >>>>>>>>>>>>>>>>>>>>>>> will do after the simulation stopped, and that >>>>>>>>>>>>>>>>>>>>>>> the simulation of a DIFFERENT machine tells you >>>>>>>>>>>>>>>>>>>>>>> of the behavior of a different machine then >>>>>>>>>>>>>>>>>>>>>>> simulated.
*I will dumb it down for you some more* >>>>>>>>>>>>>>>>>>>>>> Try any show how this DD can be correctly >>>>>>>>>>>>>>>>>>>>>> simulated by any HH
such that this DD reaches past its machine address >>>>>>>>>>>>>>>>>>>>>> [00001dbe]
I never said it could, you just are stuck in a bad >>>>>>>>>>>>>>>>>>>>> question.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>>>>>>> THAT I AM INCORRECT
Then you aren't going to get anywhere, because I just >>>>>>>>>>>>>>>>>>> don't care about that worthless claim. Only when you >>>>>>>>>>>>>>>>>>> cross the line from talking about the SUBJECTIVE >>>>>>>>>>>>>>>>>>> answer that HH saw, to the OBJECTIVE behavior of the >>>>>>>>>>>>>>>>>>> machine the input represents to a Halt Decider, will >>>>>>>>>>>>>>>>>>> you get me caring, and slapping you down hard with a >>>>>>>>>>>>>>>>>>> factual rebuttal.
*I will dumb it down for you some more* >>>>>>>>>>>>>>>>>>>> Try any show how this DD can be correctly simulated >>>>>>>>>>>>>>>>>>>> by any HH
such that this DD reaches past its machine address >>>>>>>>>>>>>>>>>>>> [00001dbe]
But I don't claim that it can. I won't go to the >>>>>>>>>>>>>>>>>>> effort to confirm that it can't, because, frankly, I >>>>>>>>>>>>>>>>>>> don't give a damn because it is MEANINGLESS. >>>>>>>>>>>>>>>>>>>
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are >>>>>>>>>>>>>>>>> correct, because I am not willing to put that effort >>>>>>>>>>>>>>>>> into your worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, >>>>>>>>>>>>>>> because I am not willing to put that effort into your >>>>>>>>>>>>>>> worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, >>>>>>>>>>>>> because I am not willing to put that effort into your >>>>>>>>>>>>> worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE
THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, >>>>>>>>>>> because I am not willing to put that effort into your
worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT
UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE
THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct,
because I am not willing to put that effort into your worthless >>>>>>>>> claim.
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
THUS THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT UNTIL >>>>>>>> YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE THAT I AM INCORRECT >>>>>>>
Then I am no longer willing to talk to you.
It is not a worthless claim it is the validation of the
essence of my life's work.
My relentless pursuit did eventually wear you down so that
you finally admitted that you have been simply dodging the
point for three years with CHANGE-THE-SUBJECT strawman deception
fake rebuttals.
Nope, I guess you are just admitting via projection that your
arguement have no real basis of facts to work with.
You lie about this. You say right above that you insist
on refusing to look at these verified facts thus showing
your true colors for all the world to see.
But they are worthless "facts",
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of
the above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
On 6/7/2024 10:14 AM, Richard Damon wrote:
On 6/7/24 9:09 AM, olcott wrote:I conclusively prove my point and you finally admit that your whole CHANGE-THE-SUBJECT strawman deception fake rebuttal has always simply
On 6/6/2024 10:29 PM, Richard Damon wrote:
On 6/6/24 10:56 PM, olcott wrote:
On 6/6/2024 9:08 PM, Richard Damon wrote:
On 6/6/24 9:06 AM, olcott wrote:
On 6/6/2024 6:11 AM, Richard Damon wrote:But, as I said, I won't acknowledge that you are correct, because
On 6/6/24 12:14 AM, olcott wrote:
On 6/5/2024 11:06 PM, Richard Damon wrote:
On 6/6/24 12:04 AM, olcott wrote:
On 6/5/2024 10:58 PM, Richard Damon wrote:
On 6/5/24 11:44 PM, olcott wrote:
On 6/5/2024 10:41 PM, Richard Damon wrote:
On 6/5/24 11:11 PM, olcott wrote:
On 6/5/2024 10:05 PM, Richard Damon wrote:
On 6/5/24 10:43 PM, olcott wrote:
On 6/5/2024 9:25 PM, Richard Damon wrote:
On 6/5/24 9:31 PM, olcott wrote:
On 6/5/2024 8:27 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 6/5/24 9:18 PM, olcott wrote:
On 6/5/2024 8:07 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> Nopoe, because it is based on the LIE that a >>>>>>>>>>>>>>>>>>>>>> partial simulation of a machine indicates what it >>>>>>>>>>>>>>>>>>>>>> will do after the simulation stopped, and that the >>>>>>>>>>>>>>>>>>>>>> simulation of a DIFFERENT machine tells you of the >>>>>>>>>>>>>>>>>>>>>> behavior of a different machine then simulated. >>>>>>>>>>>>>>>>>>>>>
*I will dumb it down for you some more* >>>>>>>>>>>>>>>>>>>>> Try any show how this DD can be correctly simulated >>>>>>>>>>>>>>>>>>>>> by any HH
such that this DD reaches past its machine address >>>>>>>>>>>>>>>>>>>>> [00001dbe]
I never said it could, you just are stuck in a bad >>>>>>>>>>>>>>>>>>>> question.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>>>>>> THAT I AM INCORRECT
Then you aren't going to get anywhere, because I just >>>>>>>>>>>>>>>>>> don't care about that worthless claim. Only when you >>>>>>>>>>>>>>>>>> cross the line from talking about the SUBJECTIVE >>>>>>>>>>>>>>>>>> answer that HH saw, to the OBJECTIVE behavior of the >>>>>>>>>>>>>>>>>> machine the input represents to a Halt Decider, will >>>>>>>>>>>>>>>>>> you get me caring, and slapping you down hard with a >>>>>>>>>>>>>>>>>> factual rebuttal.
*I will dumb it down for you some more*
Try any show how this DD can be correctly simulated >>>>>>>>>>>>>>>>>>> by any HH
such that this DD reaches past its machine address >>>>>>>>>>>>>>>>>>> [00001dbe]
But I don't claim that it can. I won't go to the >>>>>>>>>>>>>>>>>> effort to confirm that it can't, because, frankly, I >>>>>>>>>>>>>>>>>> don't give a damn because it is MEANINGLESS. >>>>>>>>>>>>>>>>>>
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are >>>>>>>>>>>>>>>> correct, because I am not willing to put that effort >>>>>>>>>>>>>>>> into your worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, >>>>>>>>>>>>>> because I am not willing to put that effort into your >>>>>>>>>>>>>> worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, >>>>>>>>>>>> because I am not willing to put that effort into your
worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT
UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE
THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct,
because I am not willing to put that effort into your
worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT
UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE
THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct,
because I am not willing to put that effort into your worthless >>>>>>>> claim.
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
THUS THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT UNTIL >>>>>>> YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE THAT I AM INCORRECT >>>>>>
I am not willing to put that effort into your worthless claim.
Then I am no longer willing to talk to you.
It is not a worthless claim it is the validation of the
essence of my life's work.
If the essence of your life's work is that you came up with a way to
not-prove the thing you were trying to prove
No you are just a Liar
Then try to show it.
ignored the proof that I am correct shown below:
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
On 6/7/2024 10:14 AM, Richard Damon wrote:
On 6/7/24 9:09 AM, olcott wrote:I conclusively prove my point and you finally admit that your whole CHANGE-THE-SUBJECT strawman deception fake rebuttal has always simply
On 6/6/2024 10:29 PM, Richard Damon wrote:
On 6/6/24 10:56 PM, olcott wrote:
On 6/6/2024 9:08 PM, Richard Damon wrote:
On 6/6/24 9:06 AM, olcott wrote:
On 6/6/2024 6:11 AM, Richard Damon wrote:But, as I said, I won't acknowledge that you are correct, because
On 6/6/24 12:14 AM, olcott wrote:
On 6/5/2024 11:06 PM, Richard Damon wrote:
On 6/6/24 12:04 AM, olcott wrote:
On 6/5/2024 10:58 PM, Richard Damon wrote:
On 6/5/24 11:44 PM, olcott wrote:
On 6/5/2024 10:41 PM, Richard Damon wrote:
On 6/5/24 11:11 PM, olcott wrote:
On 6/5/2024 10:05 PM, Richard Damon wrote:
On 6/5/24 10:43 PM, olcott wrote:
On 6/5/2024 9:25 PM, Richard Damon wrote:
On 6/5/24 9:31 PM, olcott wrote:
On 6/5/2024 8:27 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 6/5/24 9:18 PM, olcott wrote:
On 6/5/2024 8:07 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> Nopoe, because it is based on the LIE that a >>>>>>>>>>>>>>>>>>>>>> partial simulation of a machine indicates what it >>>>>>>>>>>>>>>>>>>>>> will do after the simulation stopped, and that the >>>>>>>>>>>>>>>>>>>>>> simulation of a DIFFERENT machine tells you of the >>>>>>>>>>>>>>>>>>>>>> behavior of a different machine then simulated. >>>>>>>>>>>>>>>>>>>>>
*I will dumb it down for you some more* >>>>>>>>>>>>>>>>>>>>> Try any show how this DD can be correctly simulated >>>>>>>>>>>>>>>>>>>>> by any HH
such that this DD reaches past its machine address >>>>>>>>>>>>>>>>>>>>> [00001dbe]
I never said it could, you just are stuck in a bad >>>>>>>>>>>>>>>>>>>> question.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>>>>>> THAT I AM INCORRECT
Then you aren't going to get anywhere, because I just >>>>>>>>>>>>>>>>>> don't care about that worthless claim. Only when you >>>>>>>>>>>>>>>>>> cross the line from talking about the SUBJECTIVE >>>>>>>>>>>>>>>>>> answer that HH saw, to the OBJECTIVE behavior of the >>>>>>>>>>>>>>>>>> machine the input represents to a Halt Decider, will >>>>>>>>>>>>>>>>>> you get me caring, and slapping you down hard with a >>>>>>>>>>>>>>>>>> factual rebuttal.
*I will dumb it down for you some more*
Try any show how this DD can be correctly simulated >>>>>>>>>>>>>>>>>>> by any HH
such that this DD reaches past its machine address >>>>>>>>>>>>>>>>>>> [00001dbe]
But I don't claim that it can. I won't go to the >>>>>>>>>>>>>>>>>> effort to confirm that it can't, because, frankly, I >>>>>>>>>>>>>>>>>> don't give a damn because it is MEANINGLESS. >>>>>>>>>>>>>>>>>>
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are >>>>>>>>>>>>>>>> correct, because I am not willing to put that effort >>>>>>>>>>>>>>>> into your worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, >>>>>>>>>>>>>> because I am not willing to put that effort into your >>>>>>>>>>>>>> worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, >>>>>>>>>>>> because I am not willing to put that effort into your
worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT
UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE
THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct,
because I am not willing to put that effort into your
worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT
UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE
THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct,
because I am not willing to put that effort into your worthless >>>>>>>> claim.
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
THUS THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT UNTIL >>>>>>> YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE THAT I AM INCORRECT >>>>>>
I am not willing to put that effort into your worthless claim.
Then I am no longer willing to talk to you.
It is not a worthless claim it is the validation of the
essence of my life's work.
If the essence of your life's work is that you came up with a way to
not-prove the thing you were trying to prove
No you are just a Liar
Then try to show it.
ignored the proof that I am correct shown below:
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
The proof that you have lied about this is your above admission
that you have always ignored the following proof that I am correct
by using the strawman deception CHANGE-THE-SUBJECT fake rebuttal.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 6/7/2024 10:46 AM, Richard Damon wrote:
On 6/7/24 11:29 AM, olcott wrote:
On 6/7/2024 10:14 AM, Richard Damon wrote:
On 6/7/24 9:09 AM, olcott wrote:I conclusively prove my point and you finally admit that your whole
On 6/6/2024 10:29 PM, Richard Damon wrote:
If the essence of your life's work is that you came up with a way
to not-prove the thing you were trying to prove
No you are just a Liar
Then try to show it.
CHANGE-THE-SUBJECT strawman deception fake rebuttal has always simply
ignored the proof that I am correct shown below:
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And your last statement proves why you have the problem.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
On 6/7/2024 10:14 AM, Richard Damon wrote:
On 6/7/24 9:09 AM, olcott wrote:
On 6/6/2024 10:29 PM, Richard Damon wrote:
On 6/6/24 10:56 PM, olcott wrote:
On 6/6/2024 9:08 PM, Richard Damon wrote:
But, as I said, I won't acknowledge that you are correct, because
I am not willing to put that effort into your worthless claim.
Then I am no longer willing to talk to you.
It is not a worthless claim it is the validation of the
essence of my life's work.
If the essence of your life's work is that you came up with a way to
not-prove the thing you were trying to prove
No you are just a Liar
Then try to show it.
The proof that you have lied about this is your above admission
that you have always ignored the following proof that I am correct
by using the strawman deception CHANGE-THE-SUBJECT fake rebuttal.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
On 6/7/2024 10:57 AM, Fred. Zwarts wrote:
Op 07.jun.2024 om 17:29 schreef olcott:
On 6/7/2024 10:14 AM, Richard Damon wrote:
On 6/7/24 9:09 AM, olcott wrote:I conclusively prove my point and you finally admit that your whole
On 6/6/2024 10:29 PM, Richard Damon wrote:
On 6/6/24 10:56 PM, olcott wrote:
On 6/6/2024 9:08 PM, Richard Damon wrote:
On 6/6/24 9:06 AM, olcott wrote:
On 6/6/2024 6:11 AM, Richard Damon wrote:But, as I said, I won't acknowledge that you are correct,
On 6/6/24 12:14 AM, olcott wrote:
On 6/5/2024 11:06 PM, Richard Damon wrote:
On 6/6/24 12:04 AM, olcott wrote:
On 6/5/2024 10:58 PM, Richard Damon wrote:
On 6/5/24 11:44 PM, olcott wrote:
On 6/5/2024 10:41 PM, Richard Damon wrote:
On 6/5/24 11:11 PM, olcott wrote:
On 6/5/2024 10:05 PM, Richard Damon wrote:
On 6/5/24 10:43 PM, olcott wrote:
On 6/5/2024 9:25 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 6/5/24 9:31 PM, olcott wrote:
On 6/5/2024 8:27 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 6/5/24 9:18 PM, olcott wrote:
On 6/5/2024 8:07 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> Nopoe, because it is based on the LIE that a >>>>>>>>>>>>>>>>>>>>>>>> partial simulation of a machine indicates what >>>>>>>>>>>>>>>>>>>>>>>> it will do after the simulation stopped, and >>>>>>>>>>>>>>>>>>>>>>>> that the simulation of a DIFFERENT machine tells >>>>>>>>>>>>>>>>>>>>>>>> you of the behavior of a different machine then >>>>>>>>>>>>>>>>>>>>>>>> simulated.
*I will dumb it down for you some more* >>>>>>>>>>>>>>>>>>>>>>> Try any show how this DD can be correctly >>>>>>>>>>>>>>>>>>>>>>> simulated by any HH
such that this DD reaches past its machine >>>>>>>>>>>>>>>>>>>>>>> address [00001dbe]
I never said it could, you just are stuck in a bad >>>>>>>>>>>>>>>>>>>>>> question.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>>>>>>>> THAT I AM INCORRECT
Then you aren't going to get anywhere, because I >>>>>>>>>>>>>>>>>>>> just don't care about that worthless claim. Only >>>>>>>>>>>>>>>>>>>> when you cross the line from talking about the >>>>>>>>>>>>>>>>>>>> SUBJECTIVE answer that HH saw, to the OBJECTIVE >>>>>>>>>>>>>>>>>>>> behavior of the machine the input represents to a >>>>>>>>>>>>>>>>>>>> Halt Decider, will you get me caring, and slapping >>>>>>>>>>>>>>>>>>>> you down hard with a factual rebuttal. >>>>>>>>>>>>>>>>>>>>
*I will dumb it down for you some more* >>>>>>>>>>>>>>>>>>>>> Try any show how this DD can be correctly simulated >>>>>>>>>>>>>>>>>>>>> by any HH
such that this DD reaches past its machine address >>>>>>>>>>>>>>>>>>>>> [00001dbe]
But I don't claim that it can. I won't go to the >>>>>>>>>>>>>>>>>>>> effort to confirm that it can't, because, frankly, I >>>>>>>>>>>>>>>>>>>> don't give a damn because it is MEANINGLESS. >>>>>>>>>>>>>>>>>>>>
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are >>>>>>>>>>>>>>>>>> correct, because I am not willing to put that effort >>>>>>>>>>>>>>>>>> into your worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are >>>>>>>>>>>>>>>> correct, because I am not willing to put that effort >>>>>>>>>>>>>>>> into your worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, >>>>>>>>>>>>>> because I am not willing to put that effort into your >>>>>>>>>>>>>> worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT >>>>>>>>>>>>> UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE >>>>>>>>>>>>> THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct, >>>>>>>>>>>> because I am not willing to put that effort into your
worthless claim.
THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT
UNTIL YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE
THAT I AM INCORRECT
But, as I said, I won't acknowledge that you are correct,
because I am not willing to put that effort into your
worthless claim.
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
*THE MOST IMPORTANT ASPECT OF MY PROOF*
THUS THIS IS ALL THAT YOU WILL EVER GET TO TALK TO ME ABOUT UNTIL >>>>>>>>> YOU ACKNOWLEDGE THAT I AM CORRECT OR YOU PROVE THAT I AM INCORRECT >>>>>>>>
because I am not willing to put that effort into your worthless >>>>>>>> claim.
Then I am no longer willing to talk to you.
It is not a worthless claim it is the validation of the
essence of my life's work.
If the essence of your life's work is that you came up with a way
to not-prove the thing you were trying to prove
No you are just a Liar
Then try to show it.
CHANGE-THE-SUBJECT strawman deception fake rebuttal has always simply
ignored the proof that I am correct shown below:
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Does that imply that you think that the direct execution does not
execute the instructions of the x86 machine language of DD correctly
and in correct order?
If both the simulation and the direct execution process the
instructions of the x86 machine language of DD correctly and in
correct order, then why should they differ?
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
I the claim is that HH does not report about the real behaviour, then
you could show how DD correctly simulated by any HH
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
On 6/7/2024 11:25 AM, Richard Damon wrote:
On 6/7/24 11:56 AM, olcott wrote:
On 6/7/2024 10:46 AM, Richard Damon wrote:
On 6/7/24 11:29 AM, olcott wrote:
On 6/7/2024 10:14 AM, Richard Damon wrote:
On 6/7/24 9:09 AM, olcott wrote:I conclusively prove my point and you finally admit that your whole
On 6/6/2024 10:29 PM, Richard Damon wrote:
If the essence of your life's work is that you came up with a
way to not-prove the thing you were trying to prove
No you are just a Liar
Then try to show it.
CHANGE-THE-SUBJECT strawman deception fake rebuttal has always simply >>>>> ignored the proof that I am correct shown below:
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And your last statement proves why you have the problem.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
And for this, "Correct Simulation" means a simulation that accurated
reflects that actual behavior of the dirrectly executed machine,
I provide conclusive proof otherwise and your "rebuttal" is
that you are unwilling to examine my proof, after three years
of misleading strawman deception fake "rebuttals".
On 6/6/2024 9:08 PM, Richard Damon wrote:
But, as I said, I won't acknowledge that you are correct, because I am
not willing to put that effort into your worthless claim.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
After three years of "rebuttal" of my proof using the dishonest
dodge of the strawman deception shows a reckless disregard for
the truth of defamation cases.
a reckless laf attention to the truth that misleads
or deceives another https://dictionary.findlaw.com/definition/reckless-disregard-of-the-truth.html
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? Less than a few >> days ago, you were defining a correct simulation as "1 to N instructions"
simulated (without ever specifying what you meant by N). It seems that
the simulation of exactly one instruction would have met your criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
On 6/7/2024 12:11 PM, Richard Damon wrote:
On 6/7/24 12:46 PM, olcott wrote:
On 6/7/2024 11:25 AM, Richard Damon wrote:
On 6/7/24 11:56 AM, olcott wrote:
On 6/7/2024 10:46 AM, Richard Damon wrote:And for this, "Correct Simulation" means a simulation that accurated
On 6/7/24 11:29 AM, olcott wrote:
On 6/7/2024 10:14 AM, Richard Damon wrote:
On 6/7/24 9:09 AM, olcott wrote:I conclusively prove my point and you finally admit that your whole >>>>>>> CHANGE-THE-SUBJECT strawman deception fake rebuttal has always
On 6/6/2024 10:29 PM, Richard Damon wrote:
If the essence of your life's work is that you came up with a >>>>>>>>>> way to not-prove the thing you were trying to prove
No you are just a Liar
Then try to show it.
simply
ignored the proof that I am correct shown below:
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And your last statement proves why you have the problem.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>
reflects that actual behavior of the dirrectly executed machine,
I provide conclusive proof otherwise and your "rebuttal" is
that you are unwilling to examine my proof, after three years
of misleading strawman deception fake "rebuttals".
No, you don't.
It seems
On 6/6/2024 9:08 PM, Richard Damon wrote:
But, as I said, I won't acknowledge that you are correct, becauseI am
not willing to put that effort into your worthless claim.
;
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
Why? I have shown that is a useless question for the problem.
*I have proven it thousands of times in the last three years*
2,000 times would only be an average of less than two proofs
per day.
Richard has finally admitted that he never looked at
any of these proofs thus finally admitting that his
dishonest dodge CHANGE-THE-SUBJECT strawman deception
fake rebuttal was always dishonest and deceptive.
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? Less than
a few
days ago, you were defining a correct simulation as "1 to N
instructions"
simulated (without ever specifying what you meant by N). It seems that >>>> the simulation of exactly one instruction would have met your
criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman
deception as a fake rebuttal is the I just proved that DD is correctly simulated by HH and this is not the same behavior as the directly
executed DD(DD).
The Halting Problem asks for a program H (precisely a TM) that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
You keep solving POOH !!! and made lots of lies.
Surrender to my GUR, son.
On 6/7/2024 1:22 PM, Richard Damon wrote:
On 6/7/24 1:14 PM, olcott wrote:
On 6/7/2024 12:11 PM, Richard Damon wrote:
On 6/7/24 12:46 PM, olcott wrote:
On 6/7/2024 11:25 AM, Richard Damon wrote:
On 6/7/24 11:56 AM, olcott wrote:
On 6/7/2024 10:46 AM, Richard Damon wrote:
On 6/7/24 11:29 AM, olcott wrote:
On 6/7/2024 10:14 AM, Richard Damon wrote:
On 6/7/24 9:09 AM, olcott wrote:I conclusively prove my point and you finally admit that your >>>>>>>>> whole
On 6/6/2024 10:29 PM, Richard Damon wrote:
If the essence of your life's work is that you came up with >>>>>>>>>>>> a way to not-prove the thing you were trying to prove
No you are just a Liar
Then try to show it.
CHANGE-THE-SUBJECT strawman deception fake rebuttal has always >>>>>>>>> simply
ignored the proof that I am correct shown below:
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And your last statement proves why you have the problem.
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>> until H correctly determines that its simulated D would never >>>>>>> stop running unless aborted then
H can abort its simulation of D and correctly report that D >>>>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
And for this, "Correct Simulation" means a simulation that
accurated reflects that actual behavior of the dirrectly executed
machine,
I provide conclusive proof otherwise and your "rebuttal" is
that you are unwilling to examine my proof, after three years
of misleading strawman deception fake "rebuttals".
No, you don't.
It seems
On 6/6/2024 9:08 PM, Richard Damon wrote:
But, as I said, I won't acknowledge that you are correct,because I am
not willing to put that effort into your worthless claim.
;
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
Why? I have shown that is a useless question for the problem.
*I have proven it thousands of times in the last three years*
2,000 times would only be an average of less than two proofs
per day.
No, you haven't PROVEN it, but argued it must be true.
You don't seem to know what a formal proof actually is.
I don't care about your claim, because it is, by defintion, a dead
end, as far as halting is concerned, as partial simulation do not show
non-halting behavior by themselves.
Richard has finally admitted that he never looked at
any of these proofs thus finally admitting that his
dishonest dodge CHANGE-THE-SUBJECT strawman deception
fake rebuttal was always dishonest and deceptive.
That is NOT what I have said, som you just prove yourself to be a LIAR.
On 6/5/2024 10:58 PM, Richard Damon wrote:
On 6/5/24 11:44 PM, olcott wrote:
THIS IS ALL THAT YOU WILL EVER GET TO TALK
TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
But, as I said, I won't acknowledge that you
are correct, because I am not willing to put
that effort into your worthless claim.
In other words you finally admitted that you have been intentionally
dodging this same point for three years. The actual way that you dodged
this point was the deflection of the strawman deception.
If people are going to be dishonest about simple things such as the
actual behavior of actual x86 code where they consistently deny
verified facts ....
.... then we certainly cannot trust these people with more difficult
issues that require at least some slight degree of judgment call.
When we can show that even in the halting problem HH
is only required to report on the behavior of DD correctly
simulated by HH these dishonest people merely use that
as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently
focused one one single point until the dishonest people
finally admit that they have simply ignored all the proofs
for three solid years.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 6/7/2024 2:28 PM, Richard Damon wrote:
On 6/7/24 2:41 PM, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? Less
than a few
days ago, you were defining a correct simulation as "1 to N
instructions"
simulated (without ever specifying what you meant by N). It seems >>>>>> that
the simulation of exactly one instruction would have met your
criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman
deception as a fake rebuttal is the I just proved that DD is correctly
simulated by HH and this is not the same behavior as the directly
executed DD(DD).
And thus, your idea of "Correct Simulation" fails to meet the
fundamental definition of the Correct Simulaiton of the machine.
Liar Liar pants on fire. I truly hope that this does not send you
to Hell. Maybe are are in one of those groups that believes salvation
can never be lost no matter what one's future behavior is.
I myself would not risk that.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
On 6/7/2024 1:57 PM, wij wrote:
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? Less than a >>>>>> few
days ago, you were defining a correct simulation as "1 to N
instructions"
simulated (without ever specifying what you meant by N). It seems >>>>>> that
the simulation of exactly one instruction would have met your
criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman
deception as a fake rebuttal is the I just proved that DD is correctly
simulated by HH and this is not the same behavior as the directly
executed DD(DD).
The Halting Problem asks for a program H (precisely a TM) that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
You keep solving POOH !!! and made lots of lies.
Surrender to my GUR, son.
If people are going to be dishonest about simple things
such as the actual behavior of actual x86 code where
they consistently deny verified facts
then we certainly cannot trust these people with more
difficult issues that require at least some slight degree
of judgment call.
When we can show that even in the halting problem HH
is only required to report on the behavior of DD correctly
simulated by HH these dishonest people merely use that
as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently
focused one one single point until the dishonest people
finally admit that they have simply ignored all the proofs
for three solid years.
On 6/5/2024 10:58 PM, Richard Damon wrote:
On 6/5/24 11:44 PM, olcott wrote:
THIS IS ALL THAT YOU WILL EVER GET TO TALK
TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
But, as I said, I won't acknowledge that you
are correct, because I am not willing to put
that effort into your worthless claim.
Here is the earliest version of the proof (that everyone
has simply ignored for three solid years) that P correctly
simulated by H would never stop running unless aborted.
Halting problem undecidability and infinitely nested simulation https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The fact that the execution trace of P derived by the executed
H and the simulated H exactly matches the machine code of P
proves that each instruction of P was simulated correctly and
in the correct order this conclusively proves that P is correctly
simulated by both of these instances of H.
It has proved this since 2021-09-26 and everyone has made
sure to ignore this proof so that they can maintain their false
assumption.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
On 6/7/2024 2:57 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
If people are going to be dishonest about simple things such as the
actual behavior of actual x86 code where they consistently deny
verified facts ....
You should stop swearing. "Verified facts" has a meaning,
Everyone knows that the following is a verified fact and
they dishonestly deflect.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 6/7/2024 2:57 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
If people are going to be dishonest about simple things such as the
actual behavior of actual x86 code where they consistently deny
verified facts ....
You should stop swearing. "Verified facts" has a meaning,
Everyone knows that the following is a verified fact and
they dishonestly deflect.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
He only ignores people now. Except Richard for some reason.The reason being that Richard responds at the same level
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:IME terrible thinkers are also terrible writers.
In comp.theory olcott <polcott333@gmail.com> wrote:Because I am a relatively terrible writer I must constantly improve my
A {correct simulation} means that each instruction of the above x86That's a bit of sudden and substantial change, isn't it? Less than a
machine language of DD is correctly simulated by HH and simulated in
the correct order.
few days ago, you were defining a correct simulation as "1 to N
instructions"
simulated (without ever specifying what you meant by N). It seems that
the simulation of exactly one instruction would have met your
criterion.
words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever stops running without having its simulation aborted by HH.It doesn't even matter. D halts or doesn't regardless of whether it is simulated. Even more important: the same goes for H.
Anyone claiming that HH should report on the behavior of the directly executed DD(DD) is requiring a violation of the above definition ofAre you saying a simulator can simulate whatever it wants?
correct simulation.
On 6/7/2024 1:57 PM, wij wrote:"only" It must report on the behaviour of DD, which must be the same when simulated. It can't simulate something different and say "look! My result simulating this is right, because it is my result!".
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:When we can show that even in the halting problem HH is only required to report on the behavior of DD correctly simulated by HH these dishonest
On 6/7/2024 1:24 PM, Richard Damon wrote:The Halting Problem asks for a program H (precisely a TM) that:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:And thus you admit that HH is not a Halt Decider,
In comp.theory olcott <polcott333@gmail.com> wrote:
Anyone claiming that HH should report on the behavior of the
directly executed DD(DD) is requiring a violation of the above
definition of correct simulation.
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
people merely use that as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently focused one
one single point until the dishonest people finally admit that they have simply ignored all the proofs for three solid years.
The fact that the execution trace of P derived by the executed H and the simulated H exactly matches the machine code of P proves that each instruction of P was simulated correctly and in the correct order this conclusively proves that P is correctly simulated by both of theseDoes the called H also match?
instances of H.
On 6/7/2024 2:28 PM, Richard Damon wrote:
On 6/7/24 2:41 PM, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? Less
than a few
days ago, you were defining a correct simulation as "1 to N
instructions"
simulated (without ever specifying what you meant by N). It seems >>>>>> that
the simulation of exactly one instruction would have met your
criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman
deception as a fake rebuttal is the I just proved that DD is correctly
simulated by HH and this is not the same behavior as the directly
executed DD(DD).
And thus, your idea of "Correct Simulation" fails to meet the
fundamental definition of the Correct Simulaiton of the machine.
Liar Liar pants on fire. I truly hope that this does not send you
to Hell. Maybe are are in one of those groups that believes salvation
can never be lost no matter what one's future behavior is.
I myself would not risk that.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
Pretending to be God when caught with pedophile materials won't help
much also.
On 6/7/2024 4:06 PM, Python wrote:--------------------------------------^^^^^^^^^
Le 07/06/2024 à 21:36, olcott a écrit :
On 6/7/2024 2:28 PM, Richard Damon wrote:
On 6/7/24 2:41 PM, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? Less >>>>>>>> than a few
days ago, you were defining a correct simulation as "1 to N
instructions"
simulated (without ever specifying what you meant by N). It
seems that
the simulation of exactly one instruction would have met your
criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman
deception as a fake rebuttal is the I just proved that DD is correctly >>>>> simulated by HH and this is not the same behavior as the directly
executed DD(DD).
And thus, your idea of "Correct Simulation" fails to meet the
fundamental definition of the Correct Simulaiton of the machine.
Liar Liar pants on fire. I truly hope that this does not send you
to Hell. Maybe are are in one of those groups that believes salvation
can never be lost no matter what one's future behavior is.
I myself would not risk that.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
There is NO definition of "correct simulation" above.
SHOULD IO REPEAT THIS FIFTY TIMES SO THAT YOU NOTICE THAT I SAID IT AT
LEAST ONCE?
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
On 6/7/2024 3:17 PM, Richard Damon wrote:
On 6/7/24 4:04 PM, olcott wrote:
On 6/7/2024 2:57 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
If people are going to be dishonest about simple things such as the
actual behavior of actual x86 code where they consistently deny
verified facts ....
You should stop swearing. "Verified facts" has a meaning,
Everyone knows that the following is a verified fact and
they dishonestly deflect.
It MIGHT be a fact, but it hasn't been "Verified" as in a formal
process that certifies a statement to be true, or that it has been
actually formally proven.
That is great you said that right before I was going to quit
looking at any of your replies. I enjoy talking to you yet not
at the expense of you undermining my life's work.
That it is literally impossible to prove that the following
is false conclusively proves that it is true and the proof
really need not be wrapped in any tuxedo.
We can get on to other key points only after we have closure
on this {foundation of simulating halt deciders} point.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
On 6/7/2024 3:16 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 6/7/2024 2:57 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
If people are going to be dishonest about simple things such as the
actual behavior of actual x86 code where they consistently deny
verified facts ....
You should stop swearing. "Verified facts" has a meaning,
Everyone knows that the following is a verified fact and
they dishonestly deflect.
That is untrue. There is at least one person who doesn't know "it's a
verified fact" (me).
I should have said more accurately that everyone that understands
this knows it is a verified fact.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
On 6/7/2024 6:00 PM, Richard Damon wrote:
On 6/7/24 6:24 PM, olcott wrote:
On 6/7/2024 3:56 PM, joes wrote:
Am Fri, 07 Jun 2024 14:31:10 -0500 schrieb olcott:
On 6/7/2024 1:57 PM, wij wrote:;
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:When we can show that even in the halting problem HH is only
On 6/7/2024 1:24 PM, Richard Damon wrote:The Halting Problem asks for a program H (precisely a TM) that:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:And thus you admit that HH is not a Halt Decider,
In comp.theory olcott <polcott333@gmail.com> wrote:
Anyone claiming that HH should report on the behavior of the >>>>>>>>> directly executed DD(DD) is requiring a violation of the above >>>>>>>>> definition of correct simulation.
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
required to
report on the behavior of DD correctly simulated by HH these dishonest >>>>> people merely use that as another deflection point for their
dishonesty.
The way around this that just worked is to stay diligently focused one >>>>> one single point until the dishonest people finally admit that they
have
simply ignored all the proofs for three solid years.
"only" It must report on the behaviour of DD, which must be the same
when
simulated. It can't simulate something different and say "look! My
result
simulating this is right, because it is my result!".
The most persistent false assumption that cannot possibly
be corrected without expertise in the x86 programming language.
Some people here have that.
You seem confused.
I haven't seen ANYONE complain about any x86 instruciton actually
simulated.
The complaints have always been about those NOT simulated by your
system, like the CALL H instruction.
Do you want to see the full 251 pages showing that the
call H was simulated?
On 6/7/2024 6:20 PM, Richard Damon wrote:
On 6/7/24 7:09 PM, olcott wrote:
On 6/7/2024 6:00 PM, Richard Damon wrote:
On 6/7/24 6:24 PM, olcott wrote:
On 6/7/2024 3:56 PM, joes wrote:
Am Fri, 07 Jun 2024 14:31:10 -0500 schrieb olcott:
On 6/7/2024 1:57 PM, wij wrote:;
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:When we can show that even in the halting problem HH is only
On 6/7/2024 1:24 PM, Richard Damon wrote:The Halting Problem asks for a program H (precisely a TM) that: >>>>>>>> IF H(D,D)==1, THEN D(D) will return.
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:And thus you admit that HH is not a Halt Decider,
In comp.theory olcott <polcott333@gmail.com> wrote:
Anyone claiming that HH should report on the behavior of the >>>>>>>>>>> directly executed DD(DD) is requiring a violation of the above >>>>>>>>>>> definition of correct simulation.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
required to
report on the behavior of DD correctly simulated by HH these
dishonest
people merely use that as another deflection point for their
dishonesty.
The way around this that just worked is to stay diligently
focused one
one single point until the dishonest people finally admit that
they have
simply ignored all the proofs for three solid years.
"only" It must report on the behaviour of DD, which must be the
same when
simulated. It can't simulate something different and say "look! My >>>>>> result
simulating this is right, because it is my result!".
The most persistent false assumption that cannot possibly
be corrected without expertise in the x86 programming language.
Some people here have that.
You seem confused.
I haven't seen ANYONE complain about any x86 instruciton actually
simulated.
The complaints have always been about those NOT simulated by your
system, like the CALL H instruction.
Do you want to see the full 251 pages showing that the
call H was simulated?
Sure, post it somewhere.
Then, make sure you point out what features of that traces proves that
the input represents a program that is non-halting.
That will be hard to do as you agree that it halts, and it is hard to
prove something that you admit is false.
https://liarparadox.org/HH(DD,DD)_FULL_TRACE.pdf
This includes the full trace of the simulated HH
and DD simulated by this HH mixed in.
Your false religious belief about correct simulations
can only be overcome by carefully examining this:
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
On 6/7/2024 6:00 PM, Richard Damon wrote:
On 6/7/24 6:24 PM, olcott wrote:
On 6/7/2024 3:56 PM, joes wrote:
Am Fri, 07 Jun 2024 14:31:10 -0500 schrieb olcott:
On 6/7/2024 1:57 PM, wij wrote:;
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:When we can show that even in the halting problem HH is only
On 6/7/2024 1:24 PM, Richard Damon wrote:The Halting Problem asks for a program H (precisely a TM) that:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:And thus you admit that HH is not a Halt Decider,
In comp.theory olcott <polcott333@gmail.com> wrote:
Anyone claiming that HH should report on the behavior of the >>>>>>>>> directly executed DD(DD) is requiring a violation of the above >>>>>>>>> definition of correct simulation.
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
required to
report on the behavior of DD correctly simulated by HH these dishonest >>>>> people merely use that as another deflection point for their
dishonesty.
The way around this that just worked is to stay diligently focused one >>>>> one single point until the dishonest people finally admit that they
have
simply ignored all the proofs for three solid years.
"only" It must report on the behaviour of DD, which must be the same
when
simulated. It can't simulate something different and say "look! My
result
simulating this is right, because it is my result!".
The most persistent false assumption that cannot possibly
be corrected without expertise in the x86 programming language.
Some people here have that.
You seem confused.
I haven't seen ANYONE complain about any x86 instruciton actually
simulated.
The complaints have always been about those NOT simulated by your
system, like the CALL H instruction.
It estimates the the full trace is 230 pages it is actually 246 pages. https://liarparadox.org/HH(DD,DD)_FULL_TRACE.pdf
HH simulates DD that calls HH that simulates DD and shows all of
the steps of the simulated HH. The execution trace of DD is mixed
in to this making it more difficult to find.
You STILL Haven't published any results that match your currentCopyright 2024 Olcott "Talent hits a target no one else can hit; Genius
definition of correct simulation.
--
hits a target no one else can see." Arthur Schopenhauer
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? Less than a few >>>> days ago, you were defining a correct simulation as "1 to N instructions" >>>> simulated (without ever specifying what you meant by N). It seems that >>>> the simulation of exactly one instruction would have met your criterion. >>>>
That now seems to have changed.
Because I am a relatively terrible writer I must constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman
deception as a fake rebuttal is the I just proved that DD is correctly simulated by HH and this is not the same behavior as the directly
executed DD(DD).
On 6/7/2024 3:45 PM, joes wrote:
Am Fri, 07 Jun 2024 21:22:12 +0200 schrieb immibis:
He only ignores people now. Except Richard for some reason.The reason being that Richard responds at the same level
You respond with persistent false assumptions that cannot be
corrected by feedback.
On 6/7/2024 11:18 PM, wij wrote:
On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
On 6/7/2024 2:43 PM, wij wrote:
On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
On 6/7/2024 1:57 PM, wij wrote:
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>> above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? Less >>>>>>>>>> than a
few
days ago, you were defining a correct simulation as "1 to N >>>>>>>>>> instructions"
simulated (without ever specifying what you meant by N). It >>>>>>>>>> seems that
the simulation of exactly one instruction would have met your >>>>>>>>>> criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman
deception as a fake rebuttal is the I just proved that DD is
correctly
simulated by HH and this is not the same behavior as the directly >>>>>>> executed DD(DD).
The Halting Problem asks for a program H (precisely a TM) that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
You keep solving POOH !!! and made lots of lies.
Surrender to my GUR, son.
If people are going to be dishonest about simple things
such as the actual behavior of actual x86 code where
they consistently deny verified facts
then we certainly cannot trust these people with more
difficult issues that require at least some slight degree
of judgment call.
When we can show that even in the halting problem HH
is only required to report on the behavior of DD correctly
simulated by HH these dishonest people merely use that
as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently
focused one one single point until the dishonest people
finally admit that they have simply ignored all the proofs
for three solid years.
On 6/5/2024 10:58 PM, Richard Damon wrote:
> On 6/5/24 11:44 PM, olcott wrote:
>>
>> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>
> But, as I said, I won't acknowledge that you
> are correct, because I am not willing to put
> that effort into your worthless claim.
>
Here is the earliest version of the proof (that everyone
has simply ignored for three solid years) that P correctly
simulated by H would never stop running unless aborted.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The fact that the execution trace of P derived by the executed
H and the simulated H exactly matches the machine code of P
proves that each instruction of P was simulated correctly and
in the correct order this conclusively proves that P is correctly
simulated by both of these instances of H.
It has proved this since 2021-09-26 and everyone has made
sure to ignore this proof so that they can maintain their false
assumption.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
I recalled now. You knew what the Halting Problem is. But soon, you
started to insist
POOH is correct by fabricating ...(lots of things)...
Wake up, your trick won't work.
All the while that you insist on lying about
the verified fact that DD correctly simulated by
HH cannot possibly stop running without having its
simulation aborted by HH.
You won't get to talk to me about anything else such
as why the above statement matters.
If you want to choose to be a liar thus <is> the
consequence that you get.
The Halting Problem asks for a program H (precisely a TM) that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
What is your answer? (the last time I saw POOH, it does not report
anything)
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD
[00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD
[00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
On 6/7/2024 11:18 PM, wij wrote:
On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
On 6/7/2024 2:43 PM, wij wrote:
On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
On 6/7/2024 1:57 PM, wij wrote:
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>> above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? Less >>>>>>>>>> than a
few
days ago, you were defining a correct simulation as "1 to N >>>>>>>>>> instructions"
simulated (without ever specifying what you meant by N). It >>>>>>>>>> seems that
the simulation of exactly one instruction would have met your >>>>>>>>>> criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman
deception as a fake rebuttal is the I just proved that DD is
correctly
simulated by HH and this is not the same behavior as the directly >>>>>>> executed DD(DD).
The Halting Problem asks for a program H (precisely a TM) that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
You keep solving POOH !!! and made lots of lies.
Surrender to my GUR, son.
If people are going to be dishonest about simple things
such as the actual behavior of actual x86 code where
they consistently deny verified facts
then we certainly cannot trust these people with more
difficult issues that require at least some slight degree
of judgment call.
When we can show that even in the halting problem HH
is only required to report on the behavior of DD correctly
simulated by HH these dishonest people merely use that
as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently
focused one one single point until the dishonest people
finally admit that they have simply ignored all the proofs
for three solid years.
On 6/5/2024 10:58 PM, Richard Damon wrote:
> On 6/5/24 11:44 PM, olcott wrote:
>>
>> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>
> But, as I said, I won't acknowledge that you
> are correct, because I am not willing to put
> that effort into your worthless claim.
>
Here is the earliest version of the proof (that everyone
has simply ignored for three solid years) that P correctly
simulated by H would never stop running unless aborted.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The fact that the execution trace of P derived by the executed
H and the simulated H exactly matches the machine code of P
proves that each instruction of P was simulated correctly and
in the correct order this conclusively proves that P is correctly
simulated by both of these instances of H.
It has proved this since 2021-09-26 and everyone has made
sure to ignore this proof so that they can maintain their false
assumption.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
I recalled now. You knew what the Halting Problem is. But soon, you
started to insist
POOH is correct by fabricating ...(lots of things)...
Wake up, your trick won't work.
All the while that you insist on lying about
the verified fact that DD correctly simulated by
HH cannot possibly stop running without having its
simulation aborted by HH.
You won't get to talk to me about anything else such
as why the above statement matters.
If you want to choose to be a liar thus <is> the
consequence that you get.
The Halting Problem asks for a program H (precisely a TM) that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
What is your answer? (the last time I saw POOH, it does not report
anything)
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD
[00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD
[00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
On 6/8/2024 2:01 AM, Mikko wrote:
On 2024-06-07 22:22:19 +0000, olcott said:
On 6/7/2024 3:45 PM, joes wrote:
Am Fri, 07 Jun 2024 21:22:12 +0200 schrieb immibis:
He only ignores people now. Except Richard for some reason.The reason being that Richard responds at the same level
You respond with persistent false assumptions that cannot be
corrected by feedback.
You cannot correct other people's false assumtion but
you can always present your own for comparison.
I can correct other people false assumptions iff (if and only if)
they are as interested in an honest dialogue as I am.
On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 14:20 schreef olcott:
On 6/7/2024 11:18 PM, wij wrote:
On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
On 6/7/2024 2:43 PM, wij wrote:
On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
On 6/7/2024 1:57 PM, wij wrote:
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>> by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? >>>>>>>>>>>> Less than a
few
days ago, you were defining a correct simulation as "1 to N >>>>>>>>>>>> instructions"
simulated (without ever specifying what you meant by N). It >>>>>>>>>>>> seems that
the simulation of exactly one instruction would have met >>>>>>>>>>>> your criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly >>>>>>>>>>> improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>> above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation >>>>>>>>>>> of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman >>>>>>>>> deception as a fake rebuttal is the I just proved that DD is >>>>>>>>> correctly
simulated by HH and this is not the same behavior as the directly >>>>>>>>> executed DD(DD).
The Halting Problem asks for a program H (precisely a TM) that: >>>>>>>> IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
You keep solving POOH !!! and made lots of lies.
Surrender to my GUR, son.
If people are going to be dishonest about simple things
such as the actual behavior of actual x86 code where
they consistently deny verified facts
then we certainly cannot trust these people with more
difficult issues that require at least some slight degree
of judgment call.
When we can show that even in the halting problem HH
is only required to report on the behavior of DD correctly
simulated by HH these dishonest people merely use that
as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently
focused one one single point until the dishonest people
finally admit that they have simply ignored all the proofs
for three solid years.
On 6/5/2024 10:58 PM, Richard Damon wrote:
> On 6/5/24 11:44 PM, olcott wrote:
>>
>> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>
> But, as I said, I won't acknowledge that you
> are correct, because I am not willing to put
> that effort into your worthless claim.
>
Here is the earliest version of the proof (that everyone
has simply ignored for three solid years) that P correctly
simulated by H would never stop running unless aborted.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The fact that the execution trace of P derived by the executed
H and the simulated H exactly matches the machine code of P
proves that each instruction of P was simulated correctly and
in the correct order this conclusively proves that P is correctly >>>>>>> simulated by both of these instances of H.
It has proved this since 2021-09-26 and everyone has made
sure to ignore this proof so that they can maintain their false
assumption.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
I recalled now. You knew what the Halting Problem is. But soon,
you started to insist
POOH is correct by fabricating ...(lots of things)...
Wake up, your trick won't work.
All the while that you insist on lying about
the verified fact that DD correctly simulated by
HH cannot possibly stop running without having its
simulation aborted by HH.
You won't get to talk to me about anything else such
as why the above statement matters.
If you want to choose to be a liar thus <is> the
consequence that you get.
The Halting Problem asks for a program H (precisely a TM) that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
What is your answer? (the last time I saw POOH, it does not report
anything)
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD
[00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD
[00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
The only reason being that HH, although required to halt, does not
halt, but calls DDD recursively until it is aborted.
Try rereading this again and again until to understand and remember
all of its words unless you fully intend to stay in rebuttal mode
against the verified facts. In that case I will quit replying to
your messages.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
For everyone with a little bit of knowledge of the x86 language it is
clear that if HH would return (as required), then DDD would return as
well.
So, not only DDD, but also HH is a problem for the simulator, because
they keep creating new instances of each other.
That the direct execution of HH halts, but the simulation of HH does
not halt, is a clear indication that HH is not correctly simulated. In
that case it does not help to simulate only DDD correctly. The
simulation of HH should go at least to the point where HH returns to
DDD. But the simulator is unable to do that, because it aborts too
early, which is a problem of the simulator, not of DDD.
On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 14:20 schreef olcott:
On 6/7/2024 11:18 PM, wij wrote:
On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
On 6/7/2024 2:43 PM, wij wrote:
On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
On 6/7/2024 1:57 PM, wij wrote:
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>> by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? >>>>>>>>>>>> Less than a
few
days ago, you were defining a correct simulation as "1 to N >>>>>>>>>>>> instructions"
simulated (without ever specifying what you meant by N). It >>>>>>>>>>>> seems that
the simulation of exactly one instruction would have met >>>>>>>>>>>> your criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly >>>>>>>>>>> improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>> above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation >>>>>>>>>>> of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman >>>>>>>>> deception as a fake rebuttal is the I just proved that DD is >>>>>>>>> correctly
simulated by HH and this is not the same behavior as the directly >>>>>>>>> executed DD(DD).
The Halting Problem asks for a program H (precisely a TM) that: >>>>>>>> IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
You keep solving POOH !!! and made lots of lies.
Surrender to my GUR, son.
If people are going to be dishonest about simple things
such as the actual behavior of actual x86 code where
they consistently deny verified facts
then we certainly cannot trust these people with more
difficult issues that require at least some slight degree
of judgment call.
When we can show that even in the halting problem HH
is only required to report on the behavior of DD correctly
simulated by HH these dishonest people merely use that
as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently
focused one one single point until the dishonest people
finally admit that they have simply ignored all the proofs
for three solid years.
On 6/5/2024 10:58 PM, Richard Damon wrote:
> On 6/5/24 11:44 PM, olcott wrote:
>>
>> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>
> But, as I said, I won't acknowledge that you
> are correct, because I am not willing to put
> that effort into your worthless claim.
>
Here is the earliest version of the proof (that everyone
has simply ignored for three solid years) that P correctly
simulated by H would never stop running unless aborted.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The fact that the execution trace of P derived by the executed
H and the simulated H exactly matches the machine code of P
proves that each instruction of P was simulated correctly and
in the correct order this conclusively proves that P is correctly >>>>>>> simulated by both of these instances of H.
It has proved this since 2021-09-26 and everyone has made
sure to ignore this proof so that they can maintain their false
assumption.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
I recalled now. You knew what the Halting Problem is. But soon,
you started to insist
POOH is correct by fabricating ...(lots of things)...
Wake up, your trick won't work.
All the while that you insist on lying about
the verified fact that DD correctly simulated by
HH cannot possibly stop running without having its
simulation aborted by HH.
You won't get to talk to me about anything else such
as why the above statement matters.
If you want to choose to be a liar thus <is> the
consequence that you get.
The Halting Problem asks for a program H (precisely a TM) that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
What is your answer? (the last time I saw POOH, it does not report
anything)
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD
[00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD
[00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
The only reason being that HH, although required to halt, does not
halt, but calls DDD recursively until it is aborted.
Try rereading this again and again until to understand and remember
all of its words unless you fully intend to stay in rebuttal mode
against the verified facts. In that case I will quit replying to
your messages.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
For everyone with a little bit of knowledge of the x86 language it is
clear that if HH would return (as required), then DDD would return as
well.
So, not only DDD, but also HH is a problem for the simulator, because
they keep creating new instances of each other.
That the direct execution of HH halts, but the simulation of HH does
not halt, is a clear indication that HH is not correctly simulated. In
that case it does not help to simulate only DDD correctly. The
simulation of HH should go at least to the point where HH returns to
DDD. But the simulator is unable to do that, because it aborts too
early, which is a problem of the simulator, not of DDD.
On 6/8/2024 8:03 AM, Richard Damon wrote:
On 6/8/24 8:20 AM, olcott wrote:
On 6/7/2024 11:18 PM, wij wrote:
On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
On 6/7/2024 2:43 PM, wij wrote:
On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
On 6/7/2024 1:57 PM, wij wrote:
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>> by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? >>>>>>>>>>>> Less than a
few
days ago, you were defining a correct simulation as "1 to N >>>>>>>>>>>> instructions"
simulated (without ever specifying what you meant by N). It >>>>>>>>>>>> seems that
the simulation of exactly one instruction would have met >>>>>>>>>>>> your criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly >>>>>>>>>>> improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>> above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation >>>>>>>>>>> of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman >>>>>>>>> deception as a fake rebuttal is the I just proved that DD is >>>>>>>>> correctly
simulated by HH and this is not the same behavior as the directly >>>>>>>>> executed DD(DD).
The Halting Problem asks for a program H (precisely a TM) that: >>>>>>>> IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
You keep solving POOH !!! and made lots of lies.
Surrender to my GUR, son.
If people are going to be dishonest about simple things
such as the actual behavior of actual x86 code where
they consistently deny verified facts
then we certainly cannot trust these people with more
difficult issues that require at least some slight degree
of judgment call.
When we can show that even in the halting problem HH
is only required to report on the behavior of DD correctly
simulated by HH these dishonest people merely use that
as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently
focused one one single point until the dishonest people
finally admit that they have simply ignored all the proofs
for three solid years.
On 6/5/2024 10:58 PM, Richard Damon wrote:
> On 6/5/24 11:44 PM, olcott wrote:
>>
>> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>
> But, as I said, I won't acknowledge that you
> are correct, because I am not willing to put
> that effort into your worthless claim.
>
Here is the earliest version of the proof (that everyone
has simply ignored for three solid years) that P correctly
simulated by H would never stop running unless aborted.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The fact that the execution trace of P derived by the executed
H and the simulated H exactly matches the machine code of P
proves that each instruction of P was simulated correctly and
in the correct order this conclusively proves that P is correctly >>>>>>> simulated by both of these instances of H.
It has proved this since 2021-09-26 and everyone has made
sure to ignore this proof so that they can maintain their false
assumption.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
I recalled now. You knew what the Halting Problem is. But soon,
you started to insist
POOH is correct by fabricating ...(lots of things)...
Wake up, your trick won't work.
All the while that you insist on lying about
the verified fact that DD correctly simulated by
HH cannot possibly stop running without having its
simulation aborted by HH.
You won't get to talk to me about anything else such
as why the above statement matters.
If you want to choose to be a liar thus <is> the
consequence that you get.
The Halting Problem asks for a program H (precisely a TM) that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
What is your answer? (the last time I saw POOH, it does not report
anything)
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
And what do you do with them?
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD
[00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD
[00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
Which isn't a truth preserving operations from the truth-makers to
something, Just a claim, so not a proof.
And proving a negative is hard.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
But only if HH NEVER aborts its simulation.
When HH sees what we see that DDD correctly simulated by HH
can never reach its own machine address in any finite number
of steps of correct simulation and HH sees this by recognizing
the non-halting behavior pattern in a finite sequence of steps
then HH is correct to abort its simulation and reject DDD
as non-halting.
On 6/8/2024 1:58 AM, Mikko wrote:
On 2024-06-07 18:41:47 +0000, olcott said:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? Less
than a few
days ago, you were defining a correct simulation as "1 to N
instructions"
simulated (without ever specifying what you meant by N). It seems >>>>>> that
the simulation of exactly one instruction would have met your
criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman
deception as a fake rebuttal is the I just proved that DD is correctly
simulated by HH and this is not the same behavior as the directly
executed DD(DD).
The true point is that you have never shown any proof about simulation
by HH.
In other words you lack the mandatory prerequisites so the
correct proof only looks like gibberish to you.
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD
[00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD
[00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
On 6/8/2024 8:38 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 15:16 schreef olcott:
On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 14:20 schreef olcott:
On 6/7/2024 11:18 PM, wij wrote:
On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
On 6/7/2024 2:43 PM, wij wrote:
On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
On 6/7/2024 1:57 PM, wij wrote:
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>>>> by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? >>>>>>>>>>>>>> Less than a
few
days ago, you were defining a correct simulation as "1 to N >>>>>>>>>>>>>> instructions"
simulated (without ever specifying what you meant by N). >>>>>>>>>>>>>> It seems that
the simulation of exactly one instruction would have met >>>>>>>>>>>>>> your criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly >>>>>>>>>>>>> improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>> by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior >>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation >>>>>>>>>>>>> of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman >>>>>>>>>>> deception as a fake rebuttal is the I just proved that DD is >>>>>>>>>>> correctly
simulated by HH and this is not the same behavior as the >>>>>>>>>>> directly
executed DD(DD).
The Halting Problem asks for a program H (precisely a TM) that: >>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
You keep solving POOH !!! and made lots of lies.
Surrender to my GUR, son.
If people are going to be dishonest about simple things
such as the actual behavior of actual x86 code where
they consistently deny verified facts
then we certainly cannot trust these people with more
difficult issues that require at least some slight degree
of judgment call.
When we can show that even in the halting problem HH
is only required to report on the behavior of DD correctly
simulated by HH these dishonest people merely use that
as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently
focused one one single point until the dishonest people
finally admit that they have simply ignored all the proofs
for three solid years.
On 6/5/2024 10:58 PM, Richard Damon wrote:
> On 6/5/24 11:44 PM, olcott wrote:
>>
>> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>
> But, as I said, I won't acknowledge that you
> are correct, because I am not willing to put
> that effort into your worthless claim.
>
Here is the earliest version of the proof (that everyone
has simply ignored for three solid years) that P correctly
simulated by H would never stop running unless aborted.
Halting problem undecidability and infinitely nested simulation >>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The fact that the execution trace of P derived by the executed >>>>>>>>> H and the simulated H exactly matches the machine code of P
proves that each instruction of P was simulated correctly and >>>>>>>>> in the correct order this conclusively proves that P is correctly >>>>>>>>> simulated by both of these instances of H.
It has proved this since 2021-09-26 and everyone has made
sure to ignore this proof so that they can maintain their false >>>>>>>>> assumption.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
I recalled now. You knew what the Halting Problem is. But soon, >>>>>>>> you started to insist
POOH is correct by fabricating ...(lots of things)...
Wake up, your trick won't work.
All the while that you insist on lying about
the verified fact that DD correctly simulated by
HH cannot possibly stop running without having its
simulation aborted by HH.
You won't get to talk to me about anything else such
as why the above statement matters.
If you want to choose to be a liar thus <is> the
consequence that you get.
The Halting Problem asks for a program H (precisely a TM) that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
What is your answer? (the last time I saw POOH, it does not report >>>>>> anything)
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD
[00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD
[00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
The only reason being that HH, although required to halt, does not
halt, but calls DDD recursively until it is aborted.
Try rereading this again and again until to understand and remember
all of its words unless you fully intend to stay in rebuttal mode
against the verified facts. In that case I will quit replying to
your messages.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
Don't only cite Sipser, but try to understand the words. Try to think!
If he really agreed about D, he would come to the same conclusion for H.
If simulating halt decider H correctly simulates its input H
(as part of D)
until H correctly determines that its simulated H would never
stop running unless aborted then
H can abort its simulation of H and correctly report that H
specifies a non-halting sequence of configurations.
It is only that DD calls HH that makes the simulated HH not halt.
On 6/8/2024 9:01 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 15:50 schreef olcott:
On 6/8/2024 8:38 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 15:16 schreef olcott:
On 6/8/2024 7:41 AM, Fred. Zwarts wrote:Don't only cite Sipser, but try to understand the words. Try to
Op 08.jun.2024 om 14:20 schreef olcott:
On 6/7/2024 11:18 PM, wij wrote:
On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
On 6/7/2024 2:43 PM, wij wrote:
On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
On 6/7/2024 1:57 PM, wij wrote:
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD >>>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH >>>>>>>>>>>>>>>>
A {correct simulation} means that each instruction of the >>>>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>>>>>> by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? >>>>>>>>>>>>>>>> Less than a
few
days ago, you were defining a correct simulation as "1 to N >>>>>>>>>>>>>>>> instructions"
simulated (without ever specifying what you meant by N). >>>>>>>>>>>>>>>> It seems that
the simulation of exactly one instruction would have met >>>>>>>>>>>>>>>> your criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly >>>>>>>>>>>>>>> improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>>>> by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior >>>>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation >>>>>>>>>>>>>>> of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the >>>>>>>>>>>>> strawman
deception as a fake rebuttal is the I just proved that DD >>>>>>>>>>>>> is correctly
simulated by HH and this is not the same behavior as the >>>>>>>>>>>>> directly
executed DD(DD).
The Halting Problem asks for a program H (precisely a TM) that: >>>>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
You keep solving POOH !!! and made lots of lies.
Surrender to my GUR, son.
If people are going to be dishonest about simple things
such as the actual behavior of actual x86 code where
they consistently deny verified facts
then we certainly cannot trust these people with more
difficult issues that require at least some slight degree >>>>>>>>>>> of judgment call.
When we can show that even in the halting problem HH
is only required to report on the behavior of DD correctly >>>>>>>>>>> simulated by HH these dishonest people merely use that
as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently >>>>>>>>>>> focused one one single point until the dishonest people
finally admit that they have simply ignored all the proofs >>>>>>>>>>> for three solid years.
On 6/5/2024 10:58 PM, Richard Damon wrote:
> On 6/5/24 11:44 PM, olcott wrote:
>>
>> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>
> But, as I said, I won't acknowledge that you
> are correct, because I am not willing to put
> that effort into your worthless claim.
>
Here is the earliest version of the proof (that everyone >>>>>>>>>>> has simply ignored for three solid years) that P correctly >>>>>>>>>>> simulated by H would never stop running unless aborted.
Halting problem undecidability and infinitely nested simulation >>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The fact that the execution trace of P derived by the executed >>>>>>>>>>> H and the simulated H exactly matches the machine code of P >>>>>>>>>>> proves that each instruction of P was simulated correctly and >>>>>>>>>>> in the correct order this conclusively proves that P is
correctly
simulated by both of these instances of H.
It has proved this since 2021-09-26 and everyone has made >>>>>>>>>>> sure to ignore this proof so that they can maintain their false >>>>>>>>>>> assumption.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>> above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation >>>>>>>>>>> of the above definition of correct simulation.
I recalled now. You knew what the Halting Problem is. But
soon, you started to insist
POOH is correct by fabricating ...(lots of things)...
Wake up, your trick won't work.
All the while that you insist on lying about
the verified fact that DD correctly simulated by
HH cannot possibly stop running without having its
simulation aborted by HH.
You won't get to talk to me about anything else such
as why the above statement matters.
If you want to choose to be a liar thus <is> the
consequence that you get.
The Halting Problem asks for a program H (precisely a TM) that: >>>>>>>> IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
What is your answer? (the last time I saw POOH, it does not
report anything)
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD >>>>>>> [00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD >>>>>>> [00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
The only reason being that HH, although required to halt, does not >>>>>> halt, but calls DDD recursively until it is aborted.
Try rereading this again and again until to understand and remember
all of its words unless you fully intend to stay in rebuttal mode
against the verified facts. In that case I will quit replying to
your messages.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022> >>>>
think! If he really agreed about D, he would come to the same
conclusion for H.
If simulating halt decider H correctly simulates its input H
(as part of D)
until H correctly determines that its simulated H would never
stop running unless aborted then
H can abort its simulation of H and correctly report that H
specifies a non-halting sequence of configurations.
It is only that DD calls HH that makes the simulated HH not halt.
With similar logic we can say that it is only HH that simulates DD
that makes the simulated DD not halt.
HH(DD,DD)==0 Please quit lying about this.
On 6/8/2024 8:40 AM, Richard Damon wrote:
On 6/8/24 9:07 AM, olcott wrote:
On 6/8/2024 2:01 AM, Mikko wrote:
On 2024-06-07 22:22:19 +0000, olcott said:
On 6/7/2024 3:45 PM, joes wrote:
Am Fri, 07 Jun 2024 21:22:12 +0200 schrieb immibis:
He only ignores people now. Except Richard for some reason.The reason being that Richard responds at the same level
You respond with persistent false assumptions that cannot be
corrected by feedback.
You cannot correct other people's false assumtion but
you can always present your own for comparison.
I can correct other people false assumptions iff (if and only if)
they are as interested in an honest dialogue as I am.
But you can onlly correct other people's false assumptions if they
have one, and it isn't YOU with the false assumption.
On 6/5/2024 10:58 PM, Richard Damon wrote:
On 6/5/24 11:44 PM, olcott wrote:
THIS IS ALL THAT YOU WILL EVER GET TO TALK
TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
But, as I said, I won't acknowledge that you
are correct, because I am not willing to put
that effort into your worthless claim.
That makes any statement that you make about the
behavior of DD correctly simulated by HH defamation.
On 6/8/2024 9:19 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 16:06 schreef olcott:
On 6/8/2024 9:01 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 15:50 schreef olcott:
On 6/8/2024 8:38 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 15:16 schreef olcott:
On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 14:20 schreef olcott:
On 6/7/2024 11:18 PM, wij wrote:
On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
On 6/7/2024 2:43 PM, wij wrote:
On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
On 6/7/2024 1:57 PM, wij wrote:
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:More dishonest deflection.
On 6/7/2024 12:50 PM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>> [ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>
[ .... ]
_DD()That's a bit of sudden and substantial change, isn't >>>>>>>>>>>>>>>>>> it? Less than a
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>> [00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD >>>>>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH >>>>>>>>>>>>>>>>>>
A {correct simulation} means that each instruction of >>>>>>>>>>>>>>>>>>> the
above x86 machine language of DD is correctly simulated >>>>>>>>>>>>>>>>>>> by HH and simulated in the correct order. >>>>>>>>>>>>>>>>>>
few
days ago, you were defining a correct simulation as "1 >>>>>>>>>>>>>>>>>> to N
instructions"
simulated (without ever specifying what you meant by >>>>>>>>>>>>>>>>>> N). It seems that
the simulation of exactly one instruction would have >>>>>>>>>>>>>>>>>> met your criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must >>>>>>>>>>>>>>>>> constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD >>>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH >>>>>>>>>>>>>>>>>
A {correct simulation} means that each instruction of the >>>>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>>>>>> by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior >>>>>>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation >>>>>>>>>>>>>>>>> of the above definition of correct simulation. >>>>>>>>>>>>>>>>>
And thus you admit that HH is not a Halt Decider, >>>>>>>>>>>>>>>
The point that I made and you try to deflect using the >>>>>>>>>>>>>>> strawman
deception as a fake rebuttal is the I just proved that DD >>>>>>>>>>>>>>> is correctly
simulated by HH and this is not the same behavior as the >>>>>>>>>>>>>>> directly
executed DD(DD).
The Halting Problem asks for a program H (precisely a TM) >>>>>>>>>>>>>> that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
You keep solving POOH !!! and made lots of lies.
Surrender to my GUR, son.
If people are going to be dishonest about simple things >>>>>>>>>>>>> such as the actual behavior of actual x86 code where >>>>>>>>>>>>> they consistently deny verified facts
then we certainly cannot trust these people with more >>>>>>>>>>>>> difficult issues that require at least some slight degree >>>>>>>>>>>>> of judgment call.
When we can show that even in the halting problem HH >>>>>>>>>>>>> is only required to report on the behavior of DD correctly >>>>>>>>>>>>> simulated by HH these dishonest people merely use that >>>>>>>>>>>>> as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently >>>>>>>>>>>>> focused one one single point until the dishonest people >>>>>>>>>>>>> finally admit that they have simply ignored all the proofs >>>>>>>>>>>>> for three solid years.
On 6/5/2024 10:58 PM, Richard Damon wrote:
> On 6/5/24 11:44 PM, olcott wrote:
>>
>> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT >>>>>>>>>>>>> >
> But, as I said, I won't acknowledge that you >>>>>>>>>>>>> > are correct, because I am not willing to put >>>>>>>>>>>>> > that effort into your worthless claim.
>
Here is the earliest version of the proof (that everyone >>>>>>>>>>>>> has simply ignored for three solid years) that P correctly >>>>>>>>>>>>> simulated by H would never stop running unless aborted. >>>>>>>>>>>>>
Halting problem undecidability and infinitely nested >>>>>>>>>>>>> simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The fact that the execution trace of P derived by the executed >>>>>>>>>>>>> H and the simulated H exactly matches the machine code of P >>>>>>>>>>>>> proves that each instruction of P was simulated correctly and >>>>>>>>>>>>> in the correct order this conclusively proves that P is >>>>>>>>>>>>> correctly
simulated by both of these instances of H.
It has proved this since 2021-09-26 and everyone has made >>>>>>>>>>>>> sure to ignore this proof so that they can maintain their >>>>>>>>>>>>> false
assumption.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>> by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior >>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation >>>>>>>>>>>>> of the above definition of correct simulation.
I recalled now. You knew what the Halting Problem is. But >>>>>>>>>>>> soon, you started to insist
POOH is correct by fabricating ...(lots of things)...
Wake up, your trick won't work.
All the while that you insist on lying about
the verified fact that DD correctly simulated by
HH cannot possibly stop running without having its
simulation aborted by HH.
You won't get to talk to me about anything else such
as why the above statement matters.
If you want to choose to be a liar thus <is> the
consequence that you get.
The Halting Problem asks for a program H (precisely a TM) that: >>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
What is your answer? (the last time I saw POOH, it does not >>>>>>>>>> report anything)
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD >>>>>>>>> [00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD >>>>>>>>> [00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
The only reason being that HH, although required to halt, does >>>>>>>> not halt, but calls DDD recursively until it is aborted.
Try rereading this again and again until to understand and remember >>>>>>> all of its words unless you fully intend to stay in rebuttal mode >>>>>>> against the verified facts. In that case I will quit replying to >>>>>>> your messages.
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>> until H correctly determines that its simulated D would never >>>>>>> stop running unless aborted then
H can abort its simulation of D and correctly report that D >>>>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim
words10/13/2022>
Don't only cite Sipser, but try to understand the words. Try to
think! If he really agreed about D, he would come to the same
conclusion for H.
If simulating halt decider H correctly simulates its input H
(as part of D)
until H correctly determines that its simulated H would never >>>>>> stop running unless aborted then
H can abort its simulation of H and correctly report that H
specifies a non-halting sequence of configurations.
It is only that DD calls HH that makes the simulated HH not halt.
With similar logic we can say that it is only HH that simulates DD
that makes the simulated DD not halt.
HH(DD,DD)==0 Please quit lying about this.
I never started, so it is impossible to quit.
HH(DD,DD)=0 means nothing else then that HH decides that 0 is the
correct answer for its procedure. This procedure involves the
simulation of HH (as part of DD).
It does not prove that DD(DD) halts, which would be a false negative.
You proved that HH, when used as a halting test, often has false
negatives.
So, I repeat what you have cut out:
The fact is that HH and DD both keep creating new instances of each
other. If one of them would halt, the other one would halt as well.
Your claim is that HH halts. If so, then DD halts as well.
Try to think!
DD correctly determines that its own input DD would never
stop running unless aborted.
It has no idea that the inner
HH is an instance of itself. HH merely recognizes the infinite
recursion behavior pattern.
On 6/8/2024 9:01 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 15:50 schreef olcott:
On 6/8/2024 8:38 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 15:16 schreef olcott:
On 6/8/2024 7:41 AM, Fred. Zwarts wrote:Don't only cite Sipser, but try to understand the words. Try to
Op 08.jun.2024 om 14:20 schreef olcott:
On 6/7/2024 11:18 PM, wij wrote:
On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
On 6/7/2024 2:43 PM, wij wrote:
On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
On 6/7/2024 1:57 PM, wij wrote:
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD >>>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH >>>>>>>>>>>>>>>>
A {correct simulation} means that each instruction of the >>>>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>>>>>> by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? >>>>>>>>>>>>>>>> Less than a
few
days ago, you were defining a correct simulation as "1 to N >>>>>>>>>>>>>>>> instructions"
simulated (without ever specifying what you meant by N). >>>>>>>>>>>>>>>> It seems that
the simulation of exactly one instruction would have met >>>>>>>>>>>>>>>> your criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly >>>>>>>>>>>>>>> improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>>>> by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior >>>>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation >>>>>>>>>>>>>>> of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the >>>>>>>>>>>>> strawman
deception as a fake rebuttal is the I just proved that DD >>>>>>>>>>>>> is correctly
simulated by HH and this is not the same behavior as the >>>>>>>>>>>>> directly
executed DD(DD).
The Halting Problem asks for a program H (precisely a TM) that: >>>>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
You keep solving POOH !!! and made lots of lies.
Surrender to my GUR, son.
If people are going to be dishonest about simple things
such as the actual behavior of actual x86 code where
they consistently deny verified facts
then we certainly cannot trust these people with more
difficult issues that require at least some slight degree >>>>>>>>>>> of judgment call.
When we can show that even in the halting problem HH
is only required to report on the behavior of DD correctly >>>>>>>>>>> simulated by HH these dishonest people merely use that
as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently >>>>>>>>>>> focused one one single point until the dishonest people
finally admit that they have simply ignored all the proofs >>>>>>>>>>> for three solid years.
On 6/5/2024 10:58 PM, Richard Damon wrote:
> On 6/5/24 11:44 PM, olcott wrote:
>>
>> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>
> But, as I said, I won't acknowledge that you
> are correct, because I am not willing to put
> that effort into your worthless claim.
>
Here is the earliest version of the proof (that everyone >>>>>>>>>>> has simply ignored for three solid years) that P correctly >>>>>>>>>>> simulated by H would never stop running unless aborted.
Halting problem undecidability and infinitely nested simulation >>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The fact that the execution trace of P derived by the executed >>>>>>>>>>> H and the simulated H exactly matches the machine code of P >>>>>>>>>>> proves that each instruction of P was simulated correctly and >>>>>>>>>>> in the correct order this conclusively proves that P is
correctly
simulated by both of these instances of H.
It has proved this since 2021-09-26 and everyone has made >>>>>>>>>>> sure to ignore this proof so that they can maintain their false >>>>>>>>>>> assumption.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>> above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation >>>>>>>>>>> of the above definition of correct simulation.
I recalled now. You knew what the Halting Problem is. But
soon, you started to insist
POOH is correct by fabricating ...(lots of things)...
Wake up, your trick won't work.
All the while that you insist on lying about
the verified fact that DD correctly simulated by
HH cannot possibly stop running without having its
simulation aborted by HH.
You won't get to talk to me about anything else such
as why the above statement matters.
If you want to choose to be a liar thus <is> the
consequence that you get.
The Halting Problem asks for a program H (precisely a TM) that: >>>>>>>> IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
What is your answer? (the last time I saw POOH, it does not
report anything)
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD >>>>>>> [00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD >>>>>>> [00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
The only reason being that HH, although required to halt, does not >>>>>> halt, but calls DDD recursively until it is aborted.
Try rereading this again and again until to understand and remember
all of its words unless you fully intend to stay in rebuttal mode
against the verified facts. In that case I will quit replying to
your messages.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022> >>>>
think! If he really agreed about D, he would come to the same
conclusion for H.
If simulating halt decider H correctly simulates its input H
(as part of D)
until H correctly determines that its simulated H would never
stop running unless aborted then
H can abort its simulation of H and correctly report that H
specifies a non-halting sequence of configurations.
It is only that DD calls HH that makes the simulated HH not halt.
With similar logic we can say that it is only HH that simulates DD
that makes the simulated DD not halt.
HH(DD,DD)==0 Please quit lying about this.
On 6/8/2024 8:38 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 15:16 schreef olcott:
On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 14:20 schreef olcott:
On 6/7/2024 11:18 PM, wij wrote:
On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
On 6/7/2024 2:43 PM, wij wrote:
On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
On 6/7/2024 1:57 PM, wij wrote:
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>>>> by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? >>>>>>>>>>>>>> Less than a
few
days ago, you were defining a correct simulation as "1 to N >>>>>>>>>>>>>> instructions"
simulated (without ever specifying what you meant by N). >>>>>>>>>>>>>> It seems that
the simulation of exactly one instruction would have met >>>>>>>>>>>>>> your criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly >>>>>>>>>>>>> improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>> by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior >>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation >>>>>>>>>>>>> of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman >>>>>>>>>>> deception as a fake rebuttal is the I just proved that DD is >>>>>>>>>>> correctly
simulated by HH and this is not the same behavior as the >>>>>>>>>>> directly
executed DD(DD).
The Halting Problem asks for a program H (precisely a TM) that: >>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
You keep solving POOH !!! and made lots of lies.
Surrender to my GUR, son.
If people are going to be dishonest about simple things
such as the actual behavior of actual x86 code where
they consistently deny verified facts
then we certainly cannot trust these people with more
difficult issues that require at least some slight degree
of judgment call.
When we can show that even in the halting problem HH
is only required to report on the behavior of DD correctly
simulated by HH these dishonest people merely use that
as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently
focused one one single point until the dishonest people
finally admit that they have simply ignored all the proofs
for three solid years.
On 6/5/2024 10:58 PM, Richard Damon wrote:
> On 6/5/24 11:44 PM, olcott wrote:
>>
>> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>
> But, as I said, I won't acknowledge that you
> are correct, because I am not willing to put
> that effort into your worthless claim.
>
Here is the earliest version of the proof (that everyone
has simply ignored for three solid years) that P correctly
simulated by H would never stop running unless aborted.
Halting problem undecidability and infinitely nested simulation >>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The fact that the execution trace of P derived by the executed >>>>>>>>> H and the simulated H exactly matches the machine code of P
proves that each instruction of P was simulated correctly and >>>>>>>>> in the correct order this conclusively proves that P is correctly >>>>>>>>> simulated by both of these instances of H.
It has proved this since 2021-09-26 and everyone has made
sure to ignore this proof so that they can maintain their false >>>>>>>>> assumption.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
I recalled now. You knew what the Halting Problem is. But soon, >>>>>>>> you started to insist
POOH is correct by fabricating ...(lots of things)...
Wake up, your trick won't work.
All the while that you insist on lying about
the verified fact that DD correctly simulated by
HH cannot possibly stop running without having its
simulation aborted by HH.
You won't get to talk to me about anything else such
as why the above statement matters.
If you want to choose to be a liar thus <is> the
consequence that you get.
The Halting Problem asks for a program H (precisely a TM) that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
What is your answer? (the last time I saw POOH, it does not report >>>>>> anything)
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD
[00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD
[00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
The only reason being that HH, although required to halt, does not
halt, but calls DDD recursively until it is aborted.
Try rereading this again and again until to understand and remember
all of its words unless you fully intend to stay in rebuttal mode
against the verified facts. In that case I will quit replying to
your messages.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
Don't only cite Sipser, but try to understand the words. Try to think!
If he really agreed about D, he would come to the same conclusion for H.
If simulating halt decider H correctly simulates its input H
(as part of D)
until H correctly determines that its simulated H would never
stop running unless aborted then
H can abort its simulation of H and correctly report that H
specifies a non-halting sequence of configurations.
It is only that DD calls HH that makes the simulated HH not halt.
On 6/8/2024 9:19 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 16:06 schreef olcott:
On 6/8/2024 9:01 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 15:50 schreef olcott:
On 6/8/2024 8:38 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 15:16 schreef olcott:
On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 14:20 schreef olcott:
On 6/7/2024 11:18 PM, wij wrote:
On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
On 6/7/2024 2:43 PM, wij wrote:
On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
On 6/7/2024 1:57 PM, wij wrote:
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:More dishonest deflection.
On 6/7/2024 12:50 PM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>> [ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>
[ .... ]
_DD()That's a bit of sudden and substantial change, isn't >>>>>>>>>>>>>>>>>> it? Less than a
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>> [00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD >>>>>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH >>>>>>>>>>>>>>>>>>
A {correct simulation} means that each instruction of >>>>>>>>>>>>>>>>>>> the
above x86 machine language of DD is correctly simulated >>>>>>>>>>>>>>>>>>> by HH and simulated in the correct order. >>>>>>>>>>>>>>>>>>
few
days ago, you were defining a correct simulation as "1 >>>>>>>>>>>>>>>>>> to N
instructions"
simulated (without ever specifying what you meant by >>>>>>>>>>>>>>>>>> N). It seems that
the simulation of exactly one instruction would have >>>>>>>>>>>>>>>>>> met your criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must >>>>>>>>>>>>>>>>> constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD >>>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH >>>>>>>>>>>>>>>>>
A {correct simulation} means that each instruction of the >>>>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>>>>>> by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior >>>>>>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation >>>>>>>>>>>>>>>>> of the above definition of correct simulation. >>>>>>>>>>>>>>>>>
And thus you admit that HH is not a Halt Decider, >>>>>>>>>>>>>>>
The point that I made and you try to deflect using the >>>>>>>>>>>>>>> strawman
deception as a fake rebuttal is the I just proved that DD >>>>>>>>>>>>>>> is correctly
simulated by HH and this is not the same behavior as the >>>>>>>>>>>>>>> directly
executed DD(DD).
The Halting Problem asks for a program H (precisely a TM) >>>>>>>>>>>>>> that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
You keep solving POOH !!! and made lots of lies.
Surrender to my GUR, son.
If people are going to be dishonest about simple things >>>>>>>>>>>>> such as the actual behavior of actual x86 code where >>>>>>>>>>>>> they consistently deny verified facts
then we certainly cannot trust these people with more >>>>>>>>>>>>> difficult issues that require at least some slight degree >>>>>>>>>>>>> of judgment call.
When we can show that even in the halting problem HH >>>>>>>>>>>>> is only required to report on the behavior of DD correctly >>>>>>>>>>>>> simulated by HH these dishonest people merely use that >>>>>>>>>>>>> as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently >>>>>>>>>>>>> focused one one single point until the dishonest people >>>>>>>>>>>>> finally admit that they have simply ignored all the proofs >>>>>>>>>>>>> for three solid years.
On 6/5/2024 10:58 PM, Richard Damon wrote:
> On 6/5/24 11:44 PM, olcott wrote:
>>
>> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT >>>>>>>>>>>>> >
> But, as I said, I won't acknowledge that you >>>>>>>>>>>>> > are correct, because I am not willing to put >>>>>>>>>>>>> > that effort into your worthless claim.
>
Here is the earliest version of the proof (that everyone >>>>>>>>>>>>> has simply ignored for three solid years) that P correctly >>>>>>>>>>>>> simulated by H would never stop running unless aborted. >>>>>>>>>>>>>
Halting problem undecidability and infinitely nested >>>>>>>>>>>>> simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The fact that the execution trace of P derived by the executed >>>>>>>>>>>>> H and the simulated H exactly matches the machine code of P >>>>>>>>>>>>> proves that each instruction of P was simulated correctly and >>>>>>>>>>>>> in the correct order this conclusively proves that P is >>>>>>>>>>>>> correctly
simulated by both of these instances of H.
It has proved this since 2021-09-26 and everyone has made >>>>>>>>>>>>> sure to ignore this proof so that they can maintain their >>>>>>>>>>>>> false
assumption.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>> by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior >>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation >>>>>>>>>>>>> of the above definition of correct simulation.
I recalled now. You knew what the Halting Problem is. But >>>>>>>>>>>> soon, you started to insist
POOH is correct by fabricating ...(lots of things)...
Wake up, your trick won't work.
All the while that you insist on lying about
the verified fact that DD correctly simulated by
HH cannot possibly stop running without having its
simulation aborted by HH.
You won't get to talk to me about anything else such
as why the above statement matters.
If you want to choose to be a liar thus <is> the
consequence that you get.
The Halting Problem asks for a program H (precisely a TM) that: >>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
What is your answer? (the last time I saw POOH, it does not >>>>>>>>>> report anything)
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD >>>>>>>>> [00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD >>>>>>>>> [00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
The only reason being that HH, although required to halt, does >>>>>>>> not halt, but calls DDD recursively until it is aborted.
Try rereading this again and again until to understand and remember >>>>>>> all of its words unless you fully intend to stay in rebuttal mode >>>>>>> against the verified facts. In that case I will quit replying to >>>>>>> your messages.
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>> until H correctly determines that its simulated D would never >>>>>>> stop running unless aborted then
H can abort its simulation of D and correctly report that D >>>>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim
words10/13/2022>
Don't only cite Sipser, but try to understand the words. Try to
think! If he really agreed about D, he would come to the same
conclusion for H.
If simulating halt decider H correctly simulates its input H
(as part of D)
until H correctly determines that its simulated H would never >>>>>> stop running unless aborted then
H can abort its simulation of H and correctly report that H
specifies a non-halting sequence of configurations.
It is only that DD calls HH that makes the simulated HH not halt.
With similar logic we can say that it is only HH that simulates DD
that makes the simulated DD not halt.
HH(DD,DD)==0 Please quit lying about this.
I never started, so it is impossible to quit.
HH(DD,DD)=0 means nothing else then that HH decides that 0 is the
correct answer for its procedure. This procedure involves the
simulation of HH (as part of DD).
It does not prove that DD(DD) halts, which would be a false negative.
You proved that HH, when used as a halting test, often has false
negatives.
So, I repeat what you have cut out:
The fact is that HH and DD both keep creating new instances of each
other. If one of them would halt, the other one would halt as well.
Your claim is that HH halts. If so, then DD halts as well.
Try to think!
DD correctly determines that its own input DD would never
stop running unless aborted. It has no idea that the inner
HH is an instance of itself. HH merely recognizes the infinite
recursion behavior pattern.
On 6/8/2024 8:47 AM, Richard Damon wrote:
On 6/8/24 9:16 AM, olcott wrote:
On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 14:20 schreef olcott:
On 6/7/2024 11:18 PM, wij wrote:
On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
On 6/7/2024 2:43 PM, wij wrote:
On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
On 6/7/2024 1:57 PM, wij wrote:
On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>>>> by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? >>>>>>>>>>>>>> Less than a
few
days ago, you were defining a correct simulation as "1 to N >>>>>>>>>>>>>> instructions"
simulated (without ever specifying what you meant by N). >>>>>>>>>>>>>> It seems that
the simulation of exactly one instruction would have met >>>>>>>>>>>>>> your criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly >>>>>>>>>>>>> improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>> by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior >>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation >>>>>>>>>>>>> of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman >>>>>>>>>>> deception as a fake rebuttal is the I just proved that DD is >>>>>>>>>>> correctly
simulated by HH and this is not the same behavior as the >>>>>>>>>>> directly
executed DD(DD).
The Halting Problem asks for a program H (precisely a TM) that: >>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
You keep solving POOH !!! and made lots of lies.
Surrender to my GUR, son.
If people are going to be dishonest about simple things
such as the actual behavior of actual x86 code where
they consistently deny verified facts
then we certainly cannot trust these people with more
difficult issues that require at least some slight degree
of judgment call.
When we can show that even in the halting problem HH
is only required to report on the behavior of DD correctly
simulated by HH these dishonest people merely use that
as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently
focused one one single point until the dishonest people
finally admit that they have simply ignored all the proofs
for three solid years.
On 6/5/2024 10:58 PM, Richard Damon wrote:
> On 6/5/24 11:44 PM, olcott wrote:
>>
>> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>
> But, as I said, I won't acknowledge that you
> are correct, because I am not willing to put
> that effort into your worthless claim.
>
Here is the earliest version of the proof (that everyone
has simply ignored for three solid years) that P correctly
simulated by H would never stop running unless aborted.
Halting problem undecidability and infinitely nested simulation >>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The fact that the execution trace of P derived by the executed >>>>>>>>> H and the simulated H exactly matches the machine code of P
proves that each instruction of P was simulated correctly and >>>>>>>>> in the correct order this conclusively proves that P is correctly >>>>>>>>> simulated by both of these instances of H.
It has proved this since 2021-09-26 and everyone has made
sure to ignore this proof so that they can maintain their false >>>>>>>>> assumption.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
I recalled now. You knew what the Halting Problem is. But soon, >>>>>>>> you started to insist
POOH is correct by fabricating ...(lots of things)...
Wake up, your trick won't work.
All the while that you insist on lying about
the verified fact that DD correctly simulated by
HH cannot possibly stop running without having its
simulation aborted by HH.
You won't get to talk to me about anything else such
as why the above statement matters.
If you want to choose to be a liar thus <is> the
consequence that you get.
The Halting Problem asks for a program H (precisely a TM) that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
What is your answer? (the last time I saw POOH, it does not report >>>>>> anything)
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD
[00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD
[00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
The only reason being that HH, although required to halt, does not
halt, but calls DDD recursively until it is aborted.
Try rereading this again and again until to understand and remember
all of its words unless you fully intend to stay in rebuttal mode
against the verified facts. In that case I will quit replying to
your messages.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
Which uses a DIFFERENT defintion of "Correct Simulation" then you do,
so you can't apply it the way you try.
I prove that DD is correctly simulated by HH and
your "rebuttal" is refusal to look at this proof.
*Cease and desist calling my simulation incorrect*
On 6/5/2024 10:58 PM, Richard Damon wrote:
On 6/5/24 11:44 PM, olcott wrote:
THIS IS ALL THAT YOU WILL EVER GET TO TALK
TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
But, as I said, I won't acknowledge that you
are correct, because I am not willing to put
that effort into your worthless claim.
On 6/8/2024 9:36 AM, Fred. Zwarts wrote:
Op 08.jun.2024 om 16:25 schreef olcott:
DD correctly determines that its own input DD would never
stop running unless aborted.
But it is aborted. We can not base conclusions on things that do not
happen.
We use a kind of backwards mathematical induction to prove
that a simulated input cannot possibly stop running.
We start with looking as what the behavior would be
when an infinite number of steps are correctly simulated.
We do this in a finite number of steps by matching
non-halting behavior patterns.
void Infinite_Recursion(u32 N)
{
Infinite_Recursion(N);
}
When we verify in a finite number of steps of correct
simulation that Infinite_Recursion cannot possibly
stop running without having its simulation aborted
then HH(Infinite_Recursion, (ptr)5); correctly reports
that Infinite_Recursion never halts.
Infinite_Recursion matches one of the non-halting
behavior patterns that HH has.
It has no idea that the innerThere is no infinite recursion behavior pattern, because HH aborts.
HH is an instance of itself. HH merely recognizes the infinite
recursion behavior pattern.
Whenever the input would never stop running unless aborted
then HH is correct to report that and ignore everything else
in the universe.
Most computer scientists don't pay enough attention to know
that halt deciders only compute the mapping from their inputs
on the basis of the behavior specified by these inputs.
I have never heard of any computer scientist that did not make
this mistake. Professor's Hehner and Stoddart are the only
one's in the whole world that I know of that have an actual
clue that something is wrong with the halting problem.
I found out about them on my phone when I was getting
chemotherapy on my birthday in 2022.
[1] E C R Hehner. Problems with the Halting Problem, COMPUTING2011
Symposium on 75 years of Turing Machine and Lambda-Calculus, Karlsruhe Germany, invited, 2011 October 20-21; Advances in Computer Science and Engineering v.10 n.1 p.31-60, 2013
https://www.cs.toronto.edu/~hehner/PHP.pdf
[2] E C R Hehner. Objective and Subjective Specifications
WST Workshop on Termination, Oxford. 2018 July 18.
See https://www.cs.toronto.edu/~hehner/OSS.pdf
[3] Bill Stoddart. The Halting Paradox
20 December 2017
https://arxiv.org/abs/1906.05340
arXiv:1906.05340 [cs.LO]
If there would be an infinite recursion behavior pattern that would
prove that HH would not meet its requirement that it must halt.
On 6/8/2024 2:01 AM, Mikko wrote:
On 2024-06-07 22:22:19 +0000, olcott said:
On 6/7/2024 3:45 PM, joes wrote:
Am Fri, 07 Jun 2024 21:22:12 +0200 schrieb immibis:
He only ignores people now. Except Richard for some reason.The reason being that Richard responds at the same level
You respond with persistent false assumptions that cannot be
corrected by feedback.
You cannot correct other people's false assumtion but
you can always present your own for comparison.
I can correct other people false assumptions iff (if and only if)
they are as interested in an honest dialogue as I am.
On 6/8/2024 1:58 AM, Mikko wrote:
On 2024-06-07 18:41:47 +0000, olcott said:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? Less than a few
days ago, you were defining a correct simulation as "1 to N instructions"
simulated (without ever specifying what you meant by N). It seems that >>>>>> the simulation of exactly one instruction would have met your criterion. >>>>>>
That now seems to have changed.
Because I am a relatively terrible writer I must constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman
deception as a fake rebuttal is the I just proved that DD is correctly
simulated by HH and this is not the same behavior as the directly
executed DD(DD).
The true point is that you have never shown any proof about simulation
by HH.
In other words you lack the mandatory prerequisites so the
correct proof only looks like gibberish to you.
On 6/9/2024 4:33 AM, Mikko wrote:This is not a simulator.
On 2024-06-08 13:06:06 +0000, olcott said:
On 6/8/2024 1:58 AM, Mikko wrote:
On 2024-06-07 18:41:47 +0000, olcott said:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
Anyone claiming that HH should report on the behavior of theAnd thus you admit that HH is not a Halt Decider,
directly executed DD(DD) is requiring a violation of the above
definition of correct simulation.
typedef void (*ptr)(); // pointer to void function
void HHH(ptr P, ptr I)
{
P(I); return;
}
void DDD(int (*x)())This is not a decider.
{
HHH(x, x); return;
}
int main()Thus are not deciders.
{
HHH(DDD,DDD);
}
In the above Neither DDD nor HHH ever reach their own return statement
thus never halt.
When HHH is a simulating halt decider then HHH sees that DDD correctly simulated by HHH cannot possibly reach its own return statement, AKAAnd aborts it, making it behave differently - namely, terminating.
simulating halt decider HHH correctly simulates its input DDD until
HHH correctly determines that its simulated DDD would never stop
running unless aborted
On 6/9/2024 2:34 AM, Mikko wrote:
On 2024-06-08 13:07:11 +0000, olcott said:
On 6/8/2024 2:01 AM, Mikko wrote:
On 2024-06-07 22:22:19 +0000, olcott said:
On 6/7/2024 3:45 PM, joes wrote:
Am Fri, 07 Jun 2024 21:22:12 +0200 schrieb immibis:
He only ignores people now. Except Richard for some reason.The reason being that Richard responds at the same level
You respond with persistent false assumptions that cannot be
corrected by feedback.
You cannot correct other people's false assumtion but
you can always present your own for comparison.
I can correct other people false assumptions iff (if and only if)
they are as interested in an honest dialogue as I am.
Not even then. If one does not correct one's assumption oneself they
remain uncorrected.
So one majickly cures one's own ignorance?
If one assumes 5 > 6 then one is wrong.
On 6/9/2024 4:33 AM, Mikko wrote:
On 2024-06-08 13:06:06 +0000, olcott said:
On 6/8/2024 1:58 AM, Mikko wrote:
On 2024-06-07 18:41:47 +0000, olcott said:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? Less >>>>>>>> than a few
days ago, you were defining a correct simulation as "1 to N
instructions"
simulated (without ever specifying what you meant by N). It
seems that
the simulation of exactly one instruction would have met your
criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman
deception as a fake rebuttal is the I just proved that DD is correctly >>>>> simulated by HH and this is not the same behavior as the directly
executed DD(DD).
The true point is that you have never shown any proof about simulation >>>> by HH.
In other words you lack the mandatory prerequisites so the
correct proof only looks like gibberish to you.
Hard to teest wihout the correct proof.
Anyway, something that starts with "Proof:" and ends with "Q.E.D." may
fail to be a proof. It depends on what is between.
typedef void (*ptr)(); // pointer to void function
void HHH(ptr P, ptr I)
{
P(I);
return;
}
void DDD(int (*x)())
{
HHH(x, x);
return;
}
int main()
{
HHH(DDD,DDD);
}
In the above Neither DDD nor HHH ever reach their own return
statement thus never halt.
When HHH is a simulating halt decider then HHH sees that
DDD correctly simulated by HHH cannot possibly reach its
own return statement, AKA
simulating halt decider HHH correctly simulates its input DDD
until HHH correctly determines that its simulated DDD would never
stop running unless aborted
Then I am no longer willing to talk to you.
It is not a worthless claim it is the validation of the
essence of my life's work.
On 6/9/2024 1:08 PM, Richard Damon wrote:
On 6/9/24 10:04 AM, olcott wrote:
On 6/9/2024 4:33 AM, Mikko wrote:
On 2024-06-08 13:06:06 +0000, olcott said:
On 6/8/2024 1:58 AM, Mikko wrote:
On 2024-06-07 18:41:47 +0000, olcott said:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>> above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? Less >>>>>>>>>> than a few
days ago, you were defining a correct simulation as "1 to N >>>>>>>>>> instructions"
simulated (without ever specifying what you meant by N). It >>>>>>>>>> seems that
the simulation of exactly one instruction would have met your >>>>>>>>>> criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly
improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman
deception as a fake rebuttal is the I just proved that DD is
correctly
simulated by HH and this is not the same behavior as the directly >>>>>>> executed DD(DD).
The true point is that you have never shown any proof about
simulation
by HH.
In other words you lack the mandatory prerequisites so the
correct proof only looks like gibberish to you.
Hard to teest wihout the correct proof.
Anyway, something that starts with "Proof:" and ends with "Q.E.D." may >>>> fail to be a proof. It depends on what is between.
typedef void (*ptr)(); // pointer to void function
void HHH(ptr P, ptr I)
{
P(I);
return;
}
void DDD(int (*x)())
{
HHH(x, x);
return;
}
int main()
{
HHH(DDD,DDD);
}
In the above Neither DDD nor HHH ever reach their own return
statement thus never halt.
When HHH is a simulating halt decider then HHH sees that
DDD correctly simulated by HHH cannot possibly reach its
own return statement, AKA
But HHH (as shown above) ISN'T a simulating halt decider, so you are
just caught in another of youre lies.
I didn't say it was a simulating halt decider. I needed to see
if my reviewers understand what infinite recursion is before
proceeding with them. It looks like they do not understand this.
That you call everything that I say a lie even when it
is not even incorrect is ridiculously childish of you.
On 6/9/2024 7:36 PM, Richard Damon wrote:
On 6/9/24 8:17 PM, olcott wrote:
On 6/9/2024 1:08 PM, Richard Damon wrote:
On 6/9/24 10:04 AM, olcott wrote:
On 6/9/2024 4:33 AM, Mikko wrote:
On 2024-06-08 13:06:06 +0000, olcott said:
On 6/8/2024 1:58 AM, Mikko wrote:
On 2024-06-07 18:41:47 +0000, olcott said:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>> by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? >>>>>>>>>>>> Less than a few
days ago, you were defining a correct simulation as "1 to N >>>>>>>>>>>> instructions"
simulated (without ever specifying what you meant by N). It >>>>>>>>>>>> seems that
the simulation of exactly one instruction would have met >>>>>>>>>>>> your criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly >>>>>>>>>>> improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>> above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation >>>>>>>>>>> of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman >>>>>>>>> deception as a fake rebuttal is the I just proved that DD is >>>>>>>>> correctly
simulated by HH and this is not the same behavior as the directly >>>>>>>>> executed DD(DD).
The true point is that you have never shown any proof about
simulation
by HH.
In other words you lack the mandatory prerequisites so the
correct proof only looks like gibberish to you.
Hard to teest wihout the correct proof.
Anyway, something that starts with "Proof:" and ends with "Q.E.D." >>>>>> may
fail to be a proof. It depends on what is between.
typedef void (*ptr)(); // pointer to void function
void HHH(ptr P, ptr I)
{
P(I);
return;
}
void DDD(int (*x)())
{
HHH(x, x);
return;
}
int main()
{
HHH(DDD,DDD);
}
In the above Neither DDD nor HHH ever reach their own return
statement thus never halt.
V V V So, what does this mean???? (see comment below) V V V
When HHH is a simulating halt decider then HHH sees that
DDD correctly simulated by HHH cannot possibly reach its
own return statement, AKA
But HHH (as shown above) ISN'T a simulating halt decider, so you are
just caught in another of youre lies.
I didn't say it was a simulating halt decider. I needed to see
if my reviewers understand what infinite recursion is before
proceeding with them. It looks like they do not understand this.
The why did you say "When HHH is a simulating Halt Decider..."
You can't use the same name in the same arguememt to mean different
things!
SO of course you are implying that your HHH above is to be thought of
as a Simulating Halting Decider, or at least that it will behave as one.
That you call everything that I say a lie even when it
is not even incorrect is ridiculously childish of you.
Because most things you say are a lie, because you just don't know
what you are saying.
I told one exaggeration five years ago.
I said that I had a Turing machine believing that what I
had was equivalent to a Turing machine, not yet knowing
that anyone understood Turing equivalence.
In the mean time you have repeatedly called me a liar on
practically everything that I said. This <is> defamation
in the state where you live and more importantly could
get you eventually sent to actual Hell.
THIS IS AN OFFICIAL CEASE AND DESIST NOTIFICATION.
STOP CALLING ME A LIAR.
On 6/9/2024 8:07 PM, Richard Damon wrote:
On 6/9/24 8:50 PM, olcott wrote:
On 6/9/2024 7:36 PM, Richard Damon wrote:
On 6/9/24 8:17 PM, olcott wrote:
On 6/9/2024 1:08 PM, Richard Damon wrote:
On 6/9/24 10:04 AM, olcott wrote:
On 6/9/2024 4:33 AM, Mikko wrote:
On 2024-06-08 13:06:06 +0000, olcott said:
On 6/8/2024 1:58 AM, Mikko wrote:
On 2024-06-07 18:41:47 +0000, olcott said:
On 6/7/2024 1:24 PM, Richard Damon wrote:
On 6/7/24 2:02 PM, olcott wrote:
On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>
[ .... ]
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>>>> by HH and simulated in the correct order.
That's a bit of sudden and substantial change, isn't it? >>>>>>>>>>>>>> Less than a few
days ago, you were defining a correct simulation as "1 to >>>>>>>>>>>>>> N instructions"
simulated (without ever specifying what you meant by N). >>>>>>>>>>>>>> It seems that
the simulation of exactly one instruction would have met >>>>>>>>>>>>>> your criterion.
That now seems to have changed.
Because I am a relatively terrible writer I must constantly >>>>>>>>>>>>> improve my words on the basis of reviews.
Try to show how this DD correctly simulated by any HH ever >>>>>>>>>>>>> stops running without having its simulation aborted by HH. >>>>>>>>>>>>>
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD >>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD >>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the >>>>>>>>>>>>> above x86 machine language of DD is correctly simulated >>>>>>>>>>>>> by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior >>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation >>>>>>>>>>>>> of the above definition of correct simulation.
And thus you admit that HH is not a Halt Decider,
More dishonest deflection.
The point that I made and you try to deflect using the strawman >>>>>>>>>>> deception as a fake rebuttal is the I just proved that DD is >>>>>>>>>>> correctly
simulated by HH and this is not the same behavior as the >>>>>>>>>>> directly
executed DD(DD).
The true point is that you have never shown any proof about >>>>>>>>>> simulation
by HH.
In other words you lack the mandatory prerequisites so the
correct proof only looks like gibberish to you.
Hard to teest wihout the correct proof.
Anyway, something that starts with "Proof:" and ends with
"Q.E.D." may
fail to be a proof. It depends on what is between.
typedef void (*ptr)(); // pointer to void function
void HHH(ptr P, ptr I)
{
P(I);
return;
}
void DDD(int (*x)())
{
HHH(x, x);
return;
}
int main()
{
HHH(DDD,DDD);
}
In the above Neither DDD nor HHH ever reach their own return
statement thus never halt.
V V V So, what does this mean???? (see comment below) V V V
When HHH is a simulating halt decider then HHH sees that
DDD correctly simulated by HHH cannot possibly reach its
own return statement, AKA
But HHH (as shown above) ISN'T a simulating halt decider, so you
are just caught in another of youre lies.
I didn't say it was a simulating halt decider. I needed to see
if my reviewers understand what infinite recursion is before
proceeding with them. It looks like they do not understand this.
The why did you say "When HHH is a simulating Halt Decider..."
You can't use the same name in the same arguememt to mean different
things!
SO of course you are implying that your HHH above is to be thought
of as a Simulating Halting Decider, or at least that it will behave
as one.
That you call everything that I say a lie even when it
is not even incorrect is ridiculously childish of you.
Because most things you say are a lie, because you just don't know
what you are saying.
I told one exaggeration five years ago.
I said that I had a Turing machine believing that what I
had was equivalent to a Turing machine, not yet knowing
that anyone understood Turing equivalence.
NO, you have told many more lies than that.
For instance, you said that you system produced a 250 page trace that
you verified that it showed a property of H, when it turns out you
barely glanced at it and didn't even realizd it wasn't the trace you
thought it was.
OBVIOUSLY you lied that you studied that trace.
I never even looked that the trace until
after you looked at it. Calling mistakes
lies IS DEFAMATION IN YOUR STATE
You LIE that your published traces are "Correct Simulations" per the
x86 instructions shown, when they clearly can not be, as a call H
would then be followed by the code in H, which it isn't.
IT AM STOPPING RIGHT HERE
*THAT D IS CORRECTLY SIMULATED BY H HAS BEEN PROVED FOR THREE YEARS*
THE COMPLETE PROOF OF THIS IS THAT THE X86 SOURCE-CODE
OF D EXACTLY MATCHES THE PROVIDED TRACES
On 5/29/2021 2:26 PM, olcott wrote:
[Would the simulation of D be infinitely nested unless simulating
partial halt decider H terminated its simulation of D?] https://groups.google.com/g/comp.theory/c/dTvIY5NX6b4/m/cHR2ZPgPBAAJ
THIS IS AN OFFICIAL CEASE AND DESIST NOTIFICATION.
STOP CALLING ME A LIAR.
On 6/9/2024 10:32 AM, Mikko wrote:
On 2024-06-09 12:51:40 +0000, olcott said:
On 6/9/2024 2:34 AM, Mikko wrote:
On 2024-06-08 13:07:11 +0000, olcott said:
On 6/8/2024 2:01 AM, Mikko wrote:
On 2024-06-07 22:22:19 +0000, olcott said:
On 6/7/2024 3:45 PM, joes wrote:
Am Fri, 07 Jun 2024 21:22:12 +0200 schrieb immibis:
He only ignores people now. Except Richard for some reason.The reason being that Richard responds at the same level
You respond with persistent false assumptions that cannot be
corrected by feedback.
You cannot correct other people's false assumtion but
you can always present your own for comparison.
I can correct other people false assumptions iff (if and only if)
they are as interested in an honest dialogue as I am.
Not even then. If one does not correct one's assumption oneself they
remain uncorrected.
So one majickly cures one's own ignorance?
Rarely that way.
If one assumes 5 > 6 then one is wrong.
Your disagreement does not prevent one from keeping that assumption.
The verified facts prevent anyone from correctly
maintaining false assumptions.
On 6/10/2024 2:00 AM, Mikko wrote:
On 2024-06-09 16:18:58 +0000, olcott said:
On 6/9/2024 10:32 AM, Mikko wrote:
On 2024-06-09 12:51:40 +0000, olcott said:
On 6/9/2024 2:34 AM, Mikko wrote:
On 2024-06-08 13:07:11 +0000, olcott said:
On 6/8/2024 2:01 AM, Mikko wrote:
On 2024-06-07 22:22:19 +0000, olcott said:
On 6/7/2024 3:45 PM, joes wrote:
Am Fri, 07 Jun 2024 21:22:12 +0200 schrieb immibis:
He only ignores people now. Except Richard for some reason. >>>>>>>>>> The reason being that Richard responds at the same level
You respond with persistent false assumptions that cannot be >>>>>>>>> corrected by feedback.
You cannot correct other people's false assumtion but
you can always present your own for comparison.
I can correct other people false assumptions iff (if and only if) >>>>>>> they are as interested in an honest dialogue as I am.
Not even then. If one does not correct one's assumption oneself they >>>>>> remain uncorrected.
So one majickly cures one's own ignorance?
Rarely that way.
If one assumes 5 > 6 then one is wrong.
Your disagreement does not prevent one from keeping that assumption.
The verified facts prevent anyone from correctly
maintaining false assumptions.
No, they don't, if one assumes that the verification was incorrect.
*Then they are being dishonest*
Besides, you didn't say they maintain their false assumtions "correctly". and still don't.
On 6/10/2024 2:00 AM, Mikko wrote:
On 2024-06-09 16:18:58 +0000, olcott said:
On 6/9/2024 10:32 AM, Mikko wrote:
On 2024-06-09 12:51:40 +0000, olcott said:
On 6/9/2024 2:34 AM, Mikko wrote:
On 2024-06-08 13:07:11 +0000, olcott said:
On 6/8/2024 2:01 AM, Mikko wrote:
On 2024-06-07 22:22:19 +0000, olcott said:
On 6/7/2024 3:45 PM, joes wrote:
Am Fri, 07 Jun 2024 21:22:12 +0200 schrieb immibis:
He only ignores people now. Except Richard for some reason. >>>>>>>>>> The reason being that Richard responds at the same level
You respond with persistent false assumptions that cannot be >>>>>>>>> corrected by feedback.
You cannot correct other people's false assumtion but
you can always present your own for comparison.
I can correct other people false assumptions iff (if and only if) >>>>>>> they are as interested in an honest dialogue as I am.
Not even then. If one does not correct one's assumption oneself they >>>>>> remain uncorrected.
So one majickly cures one's own ignorance?
Rarely that way.
If one assumes 5 > 6 then one is wrong.
Your disagreement does not prevent one from keeping that assumption.
The verified facts prevent anyone from correctly
maintaining false assumptions.
No, they don't, if one assumes that the verification was incorrect.
*Then they are being dishonest*
Besides, you didn't say they maintain their false assumtions "correctly".
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 30:07:26 |
| Calls: | 9,739 |
| Calls today: | 29 |
| Files: | 13,741 |
| Messages: | 6,183,042 |
| Posted today: | 2 |