Re: DDD correctly emulated by H0 --- Why Lie?

On 6/24/24 9:39 AM, olcott wrote:

On 6/24/2024 6:02 AM, Richard Damon wrote:

On 6/23/24 11:26 PM, olcott wrote:

On 6/23/2024 10:11 PM, Richard Damon wrote:

On 6/23/24 10:52 PM, olcott wrote:

On 6/23/2024 9:38 PM, olcott wrote:

On 6/23/2024 9:31 PM, Richard Damon wrote:

On 6/23/24 10:27 PM, olcott wrote:

On 6/23/2024 9:16 PM, Richard Damon wrote:

On 6/23/24 10:09 PM, olcott wrote:

On 6/23/2024 9:00 PM, Richard Damon wrote:

On 6/23/24 9:36 PM, olcott wrote:

On 6/23/2024 8:30 PM, Richard Damon wrote:

On 6/23/24 9:20 PM, olcott wrote:

On 6/23/2024 8:13 PM, Richard Damon wrote:

On 6/23/24 9:00 PM, olcott wrote:

On 6/23/2024 7:24 PM, Richard Damon wrote:

On 6/23/24 8:08 PM, olcott wrote:

On 6/23/2024 6:44 PM, Richard Damon wrote:

On 6/23/24 7:34 PM, olcott wrote:

On 6/23/2024 5:58 PM, Richard Damon wrote:

On 6/23/24 6:45 PM, olcott wrote:

>
You know what the freak I was talking from prior
discussions unless your brain is so damaged that
you can't remember anything from one post to the next.
>
In the case that you affirm that your brain <is>
this damaged then I humbly apologize.
>

>
>
No, you don't know what you are talking about.
>

So you insist on lying about this verified fact?
>
_DDD()
[00002172] 55               push ebp
[00002173] 8bec             mov ebp,esp
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]
>
According to the semantics of the x86 programming language
when DDD correctly emulated by H0 calls H0(DDD) this call
cannot possibly return.
>

>
I won't say it can't be true, but it hasn't been proven, largely because it seems you don't know how to do a formal logic proof.
>

>
Liar
>

>
Then where is the proof?
>
And were is the simulation that H0 did?
>
Failure to show where you ACTUALLY PROVED it just shows you a liar.
>
Remember the parts of a Formal Logic Proof:
>

>
You could disagree that 2 + 3 = 5 on this same Jackass basis.
2 + 3 = 5 ON THE FREAKING BASIS OF THE SEMANTICS OF ARITHMETIC.

>
But I seen proofs that 2 + 3 = 5
>
And that is done on a proof that uses the semantics of aritmetic.
>
The phrase "Semantics of Arithmetic" though, is not a proof.
>

>
According to the semantics of the x86 programming language
when DDD correctly emulated by H0 calls H0(DDD) this call
cannot possibly return.
>

>
Then try to prove it.
>

>
I will not try any prove that 2 + 3 = 5, if you deny
it then you are a liar.

>
And you don't need to, as it has been done.
>
Now, showing how 2 + 3 = 5 would help show you how to right an actual proof.
>

>
Likewise for the behavior of DDD correctly simulated
by H0. A correct x86 emulator already proved this three
years ago and you still try and get away with lying about it.

>
Nope. Just a fallacy of proof by example, which isn't a proof.
>

>
We have gotten it down to this ONLY LIARS WILL DISAGREE
THAT MY PROOF IS CORRECT.

>
WHAT PROOF?
>
No proof, just means your statement is just a LIE.
>

>
DDD correctly emulated by H0 DOES NOT HALT.

>
TYPE ERROR.
>
Correct Simutation by H is not part of the definition of HALTING.
>
Just proves your ignorance of what you talk about.
>
>

Likewise for P correctly emulated by H.

>
AGAIN TYPE ERROR.
>
Correct Simutation by H is not part of the definition of HALTING.
>
Just proves your ignorance of what you talk about.
>

>
typedef int (*ptr2)();
int H(ptr2 P, ptr2 I);
>
int P(ptr2 x)
{
   int Halt_Status = H(x, x);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
>
int main()
{
   H(P,P);
}
>
_P()
[000020e2] 55               push ebp         ; housekeeping
[000020e3] 8bec             mov ebp,esp      ; housekeeping
[000020e5] 51               push ecx         ; housekeeping
[000020e6] 8b4508           mov eax,[ebp+08] ; parameter
[000020e9] 50               push eax         ; push parameter
[000020ea] 8b4d08           mov ecx,[ebp+08] ; parameter
[000020ed] 51               push ecx         ; push parameter
[000020ee] e82ff3ffff       call 00001422    ; call H(P,P)
[000020f3] 83c408           add esp,+08
[000020f6] 8945fc           mov [ebp-04],eax
[000020f9] 837dfc00         cmp dword [ebp-04],+00
[000020fd] 7402             jz 00002101
[000020ff] ebfe             jmp 000020ff
[00002101] 8b45fc           mov eax,[ebp-04]
[00002104] 8be5             mov esp,ebp
[00002106] 5d               pop ebp
[00002107] c3               ret
Size in bytes:(0038) [00002107]
>
>
>

>
>
And, P(P) Halts since you have indicated that H(P,P) to returns 0.
>
VERIFIED FACT.
>

>
A verified fact to a God damned liar.

>
Nope, actual verified fact, one YOU have even proven and agreed to.
>
SO, I guess you are just showing you are just a LIAR.
>
>

>
The actual verified fact is that when P is correctly emulated
by H according to the semantics of the x86 language that the
call from P to H(P,P) CANNOT POSSIBLY RETURN.
>

>
But that isn't halting, so saying it shows non-halting is just a LIE, and proves your ignorance of the topic.

>
So you agree that the call cannot possibly return
or are you going to keep lying about that?
>

>
No, I am saying the call WILL return in the direct execution, which is what matters.
>

>
So finally after three years you quit lying about the
behavior of P correctly simulated by H.
>
It should not have taken that long to get you to quit
being dishonest.
>
>

>
When did I ever say anything like that about the correct simulation by H.
>

>
>

>
Many many times, dozens to hundreds of times you have
provided your incorrect opinion on D correctly simulated by H.

>
SHOW ONE.
>
WHere I said that H could simulate to there.
>

>
You tried to get away with the lie that P correctly simulated
by H had to have the same behavior as the directly executed
P(P) for three years.

>
Different statement. The instruction seen in the "correct" emulation of P by H will see EXACTLY the same instructions as seen in the direct execution of P, up to the point that H stops simulating.
>

 *That is not true*
I just ran it to make sure that my current code does this.

So, what instruction CORRECTLY emulated differed in behavior to the directly executed instruction.
and HOW? since your DEFINITION of "Correctly Emulated" is emulated according to the specification of the x86 instruction set, which is what the direct execution will also do.
If you "ran it" to verify, why haven't you posted that trace?
Probably because it would show that you are lying,
It likely does the same mistake you keep on doing of NOT actually correctly emulating the call instruction.

 The call from DD to HH(DD,DD) when DD is correctly emulated
by HH cannot possibly return. This is NOT the same behavior
as the directly executed DD(DD).

So? it will STILL follow the exact same sequence of instructions as the directly executed, until HH decides to stop.

 The call from DD to HH(DD,DD) when DD is correctly emulated
by HH1 DOES return. This is the same behavior as the directly
executed DD(DD).

Right, because the trace goes longer to the return instrucition.
The emulated by HH trace, doesn't show that the program will never return, just that the PARTIAL emulation doesn't get there.

 https://liarparadox.org/HH1(DD,DD)_Executon_Trace.pdf

Still not the right trace, I thought you said you looked at it?
_main()
[00002192] 55     push ebp
The begining of your trace:
machine   stack     stack     machine
  address   address   data      code
  ========  ========  ========  =========  =============
[00002192][00103835][00000000] 55         push ebp
[00002193][00103835][00000000] 8bec       mov ebp,esp
[00002195][00103831][00002162] 6862210000 push 00002162
[0000219a][0010382d][00002162] 6862210000 push 00002162
[0000219f][00103829][000021a4] e89ef1ffff call 00001342
So it didn't begin at DDD as it needs to.
You don''t seem to understand what is required, showing your utter ignorance (or pathology)

 

Thus, the simulation can not claim there is a different behavior of the actual program (not just emulation by H) between executed and emulated. H sees a sub-set of the behavior, not a "different" behavior.
>

>
If you really don't remember saying this your brain is much
more damaged than I ever thought.

>
You are missing fine points in the statement, probably because you don't understand them
>

>
*In any case we will remain on this single point*
>
The call from P to H(P,P) when P is correctly emulated
by H cannot possibly return.

>
And who cares? It isn't what Halting is defined to be, so has no relevance to the Halting Problem.
>
You need to prove relevance before you can work your argument.
>

>
for the next 10,000 messages if you really want to look
foolish that long.
>
>

>
Go ahead, stall your argument till you die.