Re: At least 100 people kept denying the easily verified fact --- last communication with Richard

On 6/8/24 10:25 AM, olcott wrote:

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:

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.
>
>

>
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.
 

DD isn't required to "decide" anything, its job is to make HH wrong.
The HH that DD uses, as ALL HH must do, is required to determine if its input represents a Halting Computation. If HH recognizes the infinite recursion behavior pattern, the it isn't there as the HH that DD calls will so that and break the pattern and return.
Thus HH can't get the correct answer, and can't be a correct halt decider for this input.