XPost: sci.logic

On 6/23/24 9:40 AM, olcott wrote:

_DDD()
[00002172] 55               push ebp
[00002173] 8bec             mov ebp,esp
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call HHH0
[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.

Likewise according to the semantics of arithmetic for
decimal integers: 2 + 3 = 5.

Anyone disagreeing with these two statements is WRONG.

NOw, if you REALLY mean just can H0 simulate this input to a final
state, the answer is WHO CARES.

But I will put out a few comments on errors in your presentation\.

First, if you ONLY have the bytes presented, then the answer becomes
trivial, as H0 HAS to stop emulating when it gets to the call
instruction, as there is no data at address 000015d2 defined to simulate.

This means you need to fix your problem statement to include the
instructions of HHH0, and everything that it calls as part of the
"input", or your question isn't the one you mean to be asking.

Of course, this means that each HHH0 that you try, is processing a
DIFFERENT input, so you can't argue from one about the behavior of a
different one.

Second, you forgot to specify what HHH0 has as requirements. Once you
include its code, so can simulate it, the "non-pure" function tricks
allow it to correctly simulate to the return instruction.

Reminder, you complain when we point out assumptions made on previous statements that you didn't want to carry forward, so you can't also
complain about us forgetting about requirements that you didn't bring
forward.

If you want to pull in the past, we can just point out that we KNOW you
are talking about a Halt Decider, and that your question is the wrong
question for a Halt decider.

So, your statement is wrong for two logical reasons as described above,
so your statement that anyone who disagrees is wrong is just wrong.

You don't know how to properly state a problem.

The last point to make, is that this is NOT a "proof" but just an
argument claiming something should be obviously true.

That may be a "proof" in the wild west of Philosophy, but it isn't in
the realm of Formal Logic, which is what the field you are talking about is.

So, you are making a statement, that when fixed to correct the deficits
in it, becomes a statement that might be plausably true, but not proven.

A proof can likely be made, but it seems that is beyond your ability
since you didn't even try, Of course, without the second fix, the
statement is just false, and without the first fix, the statment is meaningless, as of course you can't simulate to a return from a call
that you are unable to simulate past.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/23/24 5:41 PM, olcott wrote:

On 6/23/2024 1:20 PM, Richard Damon wrote:

On 6/23/24 9:40 AM, olcott wrote:

_DDD()
[00002172] 55               push ebp
[00002173] 8bec             mov ebp,esp
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call HHH0
[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.

Likewise according to the semantics of arithmetic for
decimal integers: 2 + 3 = 5.

Anyone disagreeing with these two statements is WRONG.

NOw, if you REALLY mean just can H0 simulate this input to a final
state, the answer is WHO CARES.

But I will put out a few comments on errors in your presentation\.

First, if you ONLY have the bytes presented, then the answer becomes
trivial, as H0 HAS to stop emulating when it gets to the call
instruction, as there is no data at address 000015d2 defined to simulate.

What a God damned liar.
https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf

Which begins its trace at main, not DDD:

From Source Listing:
_main()
[000020b3] 55 push ebp


From the beginnig of the trace:

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [000020b3][00103680][00000000] 55 push ebp

So it isn't the trace of HHH0 correctly simulating DDD

So, who is the God Damned Liar?

I told you this last time you posted it.

I guess reading what you are talking about is too hard for you.

LIAR.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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

On 6/23/2024 4:49 PM, Richard Damon wrote:

On 6/23/24 5:41 PM, olcott wrote:

On 6/23/2024 1:20 PM, Richard Damon wrote:

On 6/23/24 9:40 AM, olcott wrote:

_DDD()
[00002172] 55               push ebp
[00002173] 8bec             mov ebp,esp
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call HHH0
[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.

Likewise according to the semantics of arithmetic for
decimal integers: 2 + 3 = 5.

Anyone disagreeing with these two statements is WRONG.

NOw, if you REALLY mean just can H0 simulate this input to a final
state, the answer is WHO CARES.

But I will put out a few comments on errors in your presentation\.

First, if you ONLY have the bytes presented, then the answer becomes
trivial, as H0 HAS to stop emulating when it gets to the call
instruction, as there is no data at address 000015d2 defined to
simulate.

What a God damned liar.
https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf

Which begins its trace at main, not DDD:

You knew that there IS an HH0 and lied about it.
That makes you a God damned liar.

Of course C programs begin at main() Liar !!!

But you weren't talking about it, so your trace isn't the claimed trace,
so you are again the LIAR.


You keep on talking about the decider taking as its input, the machine
that calls it, and what THAT DECIDERS trace shows.

That will not begin with main.

THAT is the input that you NEED to show to "verify" your claim, and that
you have never done.

So, you are just showing that either you don't know what you are talking
about, or intentionally trying to use double speak to avoid revealing
your error.

In the above program, if the listed bytes are all that is available,
HHH0(DDD) absolutely can not trace more than 4 instructions.

Thus, to make you claim, the input can't be just what you show. PERIOD.

It must include all of the memory that the trace would go to, which
means all of HHH0 and everything it calls, so when you change the
decider, you have a different input, so can't equate them without lying.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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

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

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

On 6/23/2024 4:49 PM, Richard Damon wrote:

On 6/23/24 5:41 PM, olcott wrote:

On 6/23/2024 1:20 PM, Richard Damon wrote:

On 6/23/24 9:40 AM, olcott wrote:

_DDD()
[00002172] 55               push ebp
[00002173] 8bec             mov ebp,esp
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call HHH0
[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.

Likewise according to the semantics of arithmetic for
decimal integers: 2 + 3 = 5.

Anyone disagreeing with these two statements is WRONG.

NOw, if you REALLY mean just can H0 simulate this input to a final >>>>>> state, the answer is WHO CARES.

But I will put out a few comments on errors in your presentation\. >>>>>>
First, if you ONLY have the bytes presented, then the answer
becomes trivial, as H0 HAS to stop emulating when it gets to the
call instruction, as there is no data at address 000015d2 defined
to simulate.

What a God damned liar.
https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf

Which begins its trace at main, not DDD:

You knew that there IS an HH0 and lied about it.
That makes you a God damned liar.

Of course C programs begin at main() Liar !!!

But you weren't talking about it, so your trace isn't the claimed
trace, so you are again the LIAR.


You keep on talking about the decider taking as its input, the machine
that calls it, and what THAT DECIDERS trace shows.

That will not begin with main.

THAT is the input that you NEED to show to "verify" your claim, and
that you have never done.

So, you are just showing that either you don't know what you are
talking about, or intentionally trying to use double speak to avoid
revealing your error.

In the above program, if the listed bytes are all that is available,
HHH0(DDD) absolutely can not trace more than 4 instructions.

Thus, to make you claim, the input can't be just what you show. PERIOD.

It must include all of the memory that the trace would go to, which
means all of HHH0 and everything it calls, so when you change the
decider, you have a different input, so can't equate them without lying.

You know what the freak I was talking from prior
discussions unless your brain is so damaged that
you can 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.

I pointed out that you claim to have verified that the decider can not correctly emulate the input to the return instruciton.

I point out that you have never shown such a decider correctly emulating
the input past the CALL instruction.

YOU HAVEN'T, and when you call me a liar, as "proof" you show a trace
that doesn't show anything like what you claim.

So, it is still demonstrated that the decider of the machine that calls
the decider has ever been correctly emulated past the call instruction.

So, you are still shown to be a LIAR.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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.

Also, with JUST what you have said, I can prove it FALSE with an unpure
H0, but I won't push that as you have previous indicated your
intentions, but that also means that you have previously indicated that
H0 is supposed to be a Halt Decider, so we can say you definition of its requirements are just wrong, so again it is an incorrect question.

So, by that logic, you claim isn't correct (either being provably wrong
or just the wrong questiion).

You also haven't shown that your H0 actually DOES the required correct simulation, so you can't claim your results either, even if it is
established that on partial correct emulation by any version of H0 can
reach the return in H0, because we don't know if your H0 actually does a correct emulation. (If it did, you should be able to show its trace)

Part of the problem, is with the input given, you can't get past the
call 000015d2 instruciton as you don;t specify what is there, so we need
to either assume that your problem is just an invalid one, or that we
can use the implied input, which means that all of the code of H0 is
included in the input, and thus any change to H0 implies a change to the
input the way you do it (meaning we can't compare the results of
different H0s).


So, in summary, you are just showing a total lack of understanding of
what you are talking about.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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:

1) Statements of propositions that are currently accepted as proven by
the general field.

2) Valid logical operations (of the field) on those statements to
produce new statements that proven to be true by combining the accepted
true statements with the valid logical operations.

3) Repeat 1) and 2) until you get to your proposition.

You haven't done that for anything of significance, and I don't think
you know how, you always drop into just making an argument, not a proof.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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.

If the Semantics actualy do show it, then a proof, using those semantic,
should be possible, unless the proof becomes infinite in length.

(Just like the semantics of arithmetic show that there is no number G
that satisfies the specified Primative Recursive Relationship, but the
issue is that in PA, the only method to show it is to test all infinity
of the numbers one by one, so it isn't a proof, but is a true statement)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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.

H may not have been able to prove that statement, but it could prove
that it doesn't halt, and basically made a wrong guess based on faulty
logic.

YOU on the other hand, are just a LIAR, as you claim your H does
something it doesn't.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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.

Face it, you are just stuck with the need to lie about what halting
means because that is the only way to try to show your false ideas to
even have a chance to be true.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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

On 6/23/2024 8: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.

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.

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

DDD correctly emulated by H0 DOES NOT HALT.
Likewise for P correctly emulated by H.

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]

It took me a couple of years to realize the key difference
between P(P) and P correctly simulated by H is that in the
latter case the call to H(P,P) cannot possibly return.

And no one disagrees that they are different. And that is your problem,
Halting is DEFINED as the first, not the second, so you just lie when
you say the second tells us about halting. It can prove Halting
(sometimes) if H reaches the final state. It does not tell about
non-halting by itself (but can sometimes provide data for an induction
in the cases where the direct execution doesn't halt).

The key word is SOMETIMES.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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

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

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

On 6/23/2024 8: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.

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.

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

DDD correctly emulated by H0 DOES NOT HALT.
Likewise for P correctly emulated by H.

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]

It took me a couple of years to realize the key difference
between P(P) and P correctly simulated by H is that in the
latter case the call to H(P,P) cannot possibly return.

And no one disagrees that they are different.

You are lying about that.
everyone has consistently disagreed
that they can possibly be different.

The STEPS that H simulates in H correctly (partially) simulating its
input must exactly match the corresponding steps of the machine
represented by the input directly executed. (and to do either, you need
to fix your input to include all the instructions of the decider that
the input uses).

What is different is the conclusion, but you run into the issue that we
need different inputs for the two problems. The "Direct Execution"
problem, needs the input to be an actual specific machine, that could be
a template instantiated on a given decider.

Your "Correctly Simulated by H" falls apart on that case, as if H is a
fixed decider, if it aborted before it reached the end, of course it
didn't simulate to the end, (but the same input, that has been
instantiated to that H, when given to an actual complete simulator, will
see it halts). Your "Correctly Simulated by H" problem only makes sense
for tempalte inputs, which are impropper for the direct execution case.

So, they end up being totally different problems as their input spaces
are just diffferent.

You tried to get away with claiming that D correctly
simulated by H must return to its caller.

WHEN?

I think you need to check your medications, as you are hallucinating.

Please show where I said that.

Not that the dirrect execution gets there, as it must if H returns 0,
but the emulated by the decider got there.

Now that I boxed you into a corner you are trying
to get away with saying that you never said that.

So, When did I say that D correctly simulated by H must return to the
caller?

You are just making things up because you are just a pathological liar.

I will note, you have an abismal record of showing proof of your claims,
even when you claim someone has said something.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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.

I have said you haven't proved it, because you haven't, and probably
don't have the knowledge to do so.

I have said it is meaningless, because it isn't the definition needed
for halting (particularly for non-halting).

SO, it seems you are just being your normal pathological liar that has
run out of excuses so go for the ad-homenem.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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.

I think you might be right that no H, that meets the requirements you
keep on forgetting to add, can simulate the input to the return, but not positive there isn't some corner case, and not willing to put in the effort.

You could try to write out an actual proof, but based on your history, I
don't think you could even do the 2 + 3 = 5 unless you looked up how it
was done, since you haven't shown that sort of knowledge.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/23/24 10: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.
The call from P to H(P,P) cannot possibly return from P
correctly simulated by H.

SHOW ONE WHERE I SAID IT DID, for the simulation by *H*

We can stay on this single point for the next 10,000
messages if you really want to look foolish that long.

So SHOW YOUR EVIDENCE.

You are just stuck in your lies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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 are just stuck in your lies and it seems they are colapsing on you.

You need to make other liars to excuse your own lies.

The call from P to H(P,P) cannot possibly return from P
correctly simulated by H.

We can stay on this single point for the next 10,000
messages if you really want to look foolish that long.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

Am Sun, 23 Jun 2024 21:13:04 -0500 schrieb olcott:

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

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

On 6/23/2024 8: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:

Then where is the proof?

...

It took me a couple of years to realize the key difference between
P(P) and P correctly simulated by H is that in the latter case the
call to H(P,P) cannot possibly return.

And no one disagrees that they are different.

You are lying about that.
everyone has consistently disagreed that they can possibly be different.

You misunderstood. Your H is different from the direct behaviour.
It should not be.

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/24/24 9:42 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:

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

Go ahead, stall your argument till you die.

There is no sense moving on to the next point until AFTER
you quit lying about this point.

_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]

The call from P to H(P,P) when P is correctly emulated
by H cannot possibly return.

And my reply, like always, So?

Since that isn't the criteria for Halting, what do I care about it.

You haven' PROVEN your statement, only made a bald claim about it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/24/24 7:38 PM, olcott wrote:

On 6/24/2024 6:17 PM, Richard Damon wrote:

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:

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.

It is much clearer to compare apples to apples thus
see that DDD correctly simulated by H1 has different
behavior than DDD correctly simulated by H0.

Dodge and Weave, Dodge and Weave.

The emulation of the two are IDENTICAL to the point that H0 aborts its emulation.

Of course an aborted simulation won't make it to the end.

void DDD()
{
  H0(DDD);
}

_DDD()
[00002172] 55               push ebp      ; housekeeping [00002173] 8bec             mov ebp,esp   ; housekeeping [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]

The call from DDD to H0(DDD) when DDD is correctly emulated
by H0 cannot possibly return.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/24/24 7:43 PM, olcott wrote:

On 6/24/2024 6:19 PM, Richard Damon wrote:

On 6/24/24 9:42 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:

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

Go ahead, stall your argument till you die.

There is no sense moving on to the next point until AFTER
you quit lying about this point.

_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]

The call from P to H(P,P) when P is correctly emulated
by H cannot possibly return.

And my reply, like always, So?

Since you are such a damned liar I am not going to give
you two different points to endlessly switch back and forth
between. I am going to keep repeating this point to prove
what a damned liar you really are.

What is the LIE?

It seems YOU are the LIAR.

void DDD()
{
  H0(DDD);
}

_DDD()
[00002172] 55               push ebp      ; housekeeping [00002173] 8bec             mov ebp,esp   ; housekeeping [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]

The call from DDD to H0(DDD) when DDD is correctly emulated
by H0 cannot possibly return.

Once we have closure on this point we can move on to
the last point.

And what do we care about it?

It isn't halting.

That is all you will get from me until you answer some of the many
questions you have ignored, which all just prove you have been lying all
these years.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

Am Sun, 23 Jun 2024 20:36:39 -0500 schrieb olcott:

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:

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 write an actual
proof.
And, P(P) Halts since you have indicated that H(P,P) to returns 0.

So it doesn't need to be aborted.

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.

So H is not a decider anymore?

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/23/24 9:40 AM, olcott wrote:

_DDD()
[00002172] 55               push ebp
[00002173] 8bec             mov ebp,esp
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call HHH0
[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.

According to the semantics of the x86 programming language, a "Correct emulation" of DDD must continue untul we reach the ret at 00002183, a
fault occurs, or we hit a Halt instruction, as part of the behavior of
every instruction is that the next instruction WILL be run.

Thus, the only HHH0 that can exist can not "abort" its simulation, and
thus does not answer for this input.


If you want to alter the semantics to allow for PARTIAL simulation, then
by the semantics of partial simulation, you can not talk about the
future past the point of aborting (without otherwise proving the claim),
and thus you can not say "can not possibly return", but "was not
simulated to return", or "hasn't returned YET".

All such statements must allow for the fact that emulating further might
occur by some bettert emulator.

Also, the very form of your question says that the code for HHH0 is
INCLUDED in the input, or we can not actually emulate the call
instruction itself.

Likewise according to the semantics of arithmetic for
decimal integers: 2 + 3 = 5.

Exactly.

Anyone disagreeing with these two statements is WRONG.

Right, so the ONLY HHH0 is the actual PURE EMULATOR which never answers.


Except of course for the HHH0 that begins as:


HHH0(ptr x) {
static int flag = 0;
if (flag) return 0;
...


That one (and similar) WILL be able to emulate its input to the final
return.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/26/24 9:48 AM, olcott wrote:

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

On 6/23/24 9:40 AM, olcott wrote:

_DDD()
[00002172] 55               push ebp
[00002173] 8bec             mov ebp,esp
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call HHH0
[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.

According to the semantics of the x86 programming language, a "Correct
emulation" of DDD must continue untul we reach the ret at 00002183, a
fault occurs, or we hit a Halt instruction, as part of the behavior of
every instruction is that the next instruction WILL be run.

Yes

Thus, the only HHH0 that can exist can not "abort" its simulation, and
thus does not answer for this input.

No

Since you agreed that the specification includes the full continued
execution trace, if it aborts, it does NOT do a correct emulation of the
input, and for this input, if it calim non-halting, it is wrrong ,as
then DDD specifies halting behavior by the actually correct emulation of
it, the DOES continue until it sees H0 abort its emulation and return.

void Infinite_Recursion()
{
  Infinite_Recursion();
}

void DDD()
{
  H0(DDD);
}

int main()
{
  H0(Infinite_Recursion);
  H0(DDD);
}

Literally in the exact same way that H0 detects that
Infinite_Recursion correctly emulated by H0 will never halt
H0 detects that DDD correctly emulated by H0 will never halt.

Except that it doesn't work, as has been proven in the past.

ANY pattern that the decider uses to try to show the "pathological"
pattern would never end, is incorrect, as detecting that pattern, and returning, makes it end on the next cycle.

So, you are just a liar again.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)