XPost: sci.logic

On 7/3/24 10:41 PM, olcott wrote:

On 7/3/2024 9:34 PM, Richard Damon wrote:

On 7/3/24 10:05 PM, olcott wrote:

On 7/3/2024 8:47 PM, Richard Damon wrote:

On 7/3/24 9:26 PM, olcott wrote:

On 7/3/2024 8:17 PM, Richard Damon wrote:

On 7/3/24 8:40 PM, olcott wrote:

On 7/3/2024 6:18 PM, Richard Damon wrote:

On 7/3/24 10:19 AM, olcott wrote:

On 7/3/2024 9:11 AM, joes wrote:

Am Tue, 02 Jul 2024 22:55:12 -0500 schrieb olcott:

On 7/2/2024 10:50 PM, joes wrote:

Am Tue, 02 Jul 2024 14:46:38 -0500 schrieb olcott:

On 7/2/2024 2:17 PM, Fred. Zwarts wrote:

Op 02.jul.2024 om 21:00 schreef olcott:

On 7/2/2024 1:42 PM, Fred. Zwarts wrote:

Op 02.jul.2024 om 14:22 schreef olcott:

On 7/2/2024 3:22 AM, Fred. Zwarts wrote:

Op 02.jul.2024 om 03:25 schreef olcott:

HHH repeats the process twice and aborts too soon.

DDD is correctly emulated by any HHH that can exist which >>>>>>>>>>>>> calls this
emulated HHH(DDD) to repeat the process until aborted >>>>>>>>>>>>> (which may be
never).

Whatever HHH does, it does not run forever but aborts. >>>>>>>>>>>>

HHH halts on input DDD.
DDD correctly simulated by HHH cannot possibly halt.

WTF? It only calls HHH, which you just said halts.

An aborted simulation does not count as halting.

And doesn't show non-halting either.

Reaching it own machine address 00002183 counts as halting.
DDD correctly simulated by HHH cannot possibly do that.

But HHH doesn't DO a "Correct Simulation" that can show that, it >>>>>>>> only does a PARTIAL simulation.

<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
     If simulating halt decider H correctly simulates its input D >>>>>>>      until H correctly determines that its simulated D would never >>>>>>>      stop running unless aborted then

     H can abort its simulation of D and correctly report that D >>>>>>>      specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>

until H correctly determines
until H correctly determines
until H correctly determines
until H correctly determines
until H correctly determines
until H correctly determines
until H correctly determines

Which it doesn't.

THUS STIPULATING THAT A PARTIAL SIMULATION IS CORRECT
THUS STIPULATING THAT A PARTIAL SIMULATION IS CORRECT
THUS STIPULATING THAT A PARTIAL SIMULATION IS CORRECT
THUS STIPULATING THAT A PARTIAL SIMULATION IS CORRECT
THUS STIPULATING THAT A PARTIAL SIMULATION IS CORRECT
THUS STIPULATING THAT A PARTIAL SIMULATION IS CORRECT
THUS STIPULATING THAT A PARTIAL SIMULATION IS CORRECT

Nope, just double talk.

H never CORRECTLY determined that a CORRECT SIMULATION (which
means one that matchs the behavior of the machine represented by
the input) would never halt, sinc ehta tmachine halts.

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

OK so it is not your ADD you continue to insist that
you can disagree with the x86 language that conclusively
proves that DDD correctly simulated by HHH cannot
possibly get past machine instruction 0000217a.

No, the claim is that it isn't the simulation by HHH that determines
the actual behavior of the input, but the detailed semantics of the
x86 instruciton set of the WHOLE input (which includes this
particular HHH which you say DOES abort its simulation and return).

You are not paying close enough attention to the exact words
that I am saying. DDD cannot possibly reach past its own
machine address 0000217a no matter what the Hell that HHH does.

OF course it can. HHH might not be able to simulate it getting there,

Because the machine instructions provided to HHH specify that
it is not possible to go there. HHH uses an x86 emulator with
two decades of development effort.

No, the exact same instructions that HHH used when called by main are in
the presentation to HHH by DDD, and since the first one returned, so
will the COMPLETE (which is what the semantic require) emulation of
those exact same x86 instructions of HHH to also return, and thus DDD
will return.

The fact that HHH gives up part way on the inner emulation it is doing
doesn't affect the semantics of the instructions that were there.

Correctly simulated means OBEYS THE X86 SEMANTICS.
Correctly simulated DOES NOT MEAN do what Richard expects.

Right, so if Main calling HHH(DDD) causes HHH to return to main, the x86 instruction in HHH, which are ALSO presented to HHH, will cause the
COMPLETE emulation of that code (not the partial one by HHH) to return.

You are just stuck in your lies.

I guess you don't understand that programs are exactly what they are and
do exactly what they do, and just because one emulator stooped its
emulation doesn't change that behavior.

You keep on trying to pull a "shell game" and attempt to change HHH and
DDD between tests, that is just lying.

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

XPost: sci.logic

Op 04.jul.2024 om 05:21 schreef olcott:

On 7/3/2024 10:05 PM, Richard Damon wrote:

On 7/3/24 10:41 PM, olcott wrote:

On 7/3/2024 9:34 PM, Richard Damon wrote:

On 7/3/24 10:05 PM, olcott wrote:

You are not paying close enough attention to the exact words
that I am saying. DDD cannot possibly reach past its own
machine address 0000217a no matter what the Hell that HHH does.

OF course it can. HHH might not be able to simulate it getting there,

Because the machine instructions provided to HHH specify that
it is not possible to go there. HHH uses an x86 emulator with
two decades of development effort.

No, the exact same instructions that HHH used when called by main are
in the presentation to HHH by DDD,

That is false and you are too indoctrinated to notice verified facts.

HHH1 and directly executed DDD(DDD) benefit from
HHH(DDD) having already aborted its simulation.
HHH cannot possibly reap this same benefit.

Exactly! Well done! This proves that HHH cannot possibly correctly
simulate itself. Because it aborts too soon.

Maybe I need to repeat this in every reply.

Yes and remember that, therefore, HHH cannot possibly correctly simulate itself.

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

XPost: sci.logic

On 7/3/24 11:21 PM, olcott wrote:

On 7/3/2024 10:05 PM, Richard Damon wrote:

On 7/3/24 10:41 PM, olcott wrote:

On 7/3/2024 9:34 PM, Richard Damon wrote:

On 7/3/24 10:05 PM, olcott wrote:

You are not paying close enough attention to the exact words
that I am saying. DDD cannot possibly reach past its own
machine address 0000217a no matter what the Hell that HHH does.

OF course it can. HHH might not be able to simulate it getting there,

Because the machine instructions provided to HHH specify that
it is not possible to go there. HHH uses an x86 emulator with
two decades of development effort.

No, the exact same instructions that HHH used when called by main are
in the presentation to HHH by DDD,

That is false and you are too indoctrinated to notice verified facts.

HHH1 and directly executed DDD(DDD) benefit from
HHH(DDD) having already aborted its simulation.
HHH cannot possibly reap this same benefit.

Maybe I need to repeat this in every reply.

So? The fact that HHH is just stupid like you doesn't make its wrong
answer right.

Where is the difference that actualy occures in the CORRECT x86 simulation?

Remember, x86 simulation means you don't replace the call to HHH with
another simulation of the input, as that isn't what the x86 processor
does, it needs to be the actual simulation of the x86 instructions of HHH.

So, what instruction does HHH see differently then HHH1 does to allow it
to have a different behavior path, other than the fact that HHH just
stops at some point.


Maybe I need to repeat THIS at every reply,

That question, in various forms has been out there for years, and you
deafening non-answer just shows that you are admitting this claim is
just as much of a lie as your recent "Diagonalization" claim where you
went form claiming there was a Diagonalization proof that showed Godel
wrong, and when pushed for that proof, your reply was that
Diagonalization proofs were just nonsense, effectively admitting that
you use nonsense proofs as your source of your claims.

Your whole argument is based on LIES, deceit, and ignorance.

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

XPost: sci.logic

Op 04.jul.2024 om 14:43 schreef olcott:

On 7/4/2024 2:52 AM, Fred. Zwarts wrote:

Op 04.jul.2024 om 05:21 schreef olcott:

On 7/3/2024 10:05 PM, Richard Damon wrote:

On 7/3/24 10:41 PM, olcott wrote:

On 7/3/2024 9:34 PM, Richard Damon wrote:

On 7/3/24 10:05 PM, olcott wrote:

You are not paying close enough attention to the exact words
that I am saying. DDD cannot possibly reach past its own
machine address 0000217a no matter what the Hell that HHH does.

OF course it can. HHH might not be able to simulate it getting there, >>>>>

Because the machine instructions provided to HHH specify that
it is not possible to go there. HHH uses an x86 emulator with
two decades of development effort.

No, the exact same instructions that HHH used when called by main
are in the presentation to HHH by DDD,

That is false and you are too indoctrinated to notice verified facts.

HHH1 and directly executed DDD(DDD) benefit from
HHH(DDD) having already aborted its simulation.
HHH cannot possibly reap this same benefit.

Exactly! Well done! This proves that HHH cannot possibly correctly
simulate itself. Because it aborts too soon.

Liar

Ad hominem attack as an attempt to hide that you ran out of arguments.
You could not point to any error in the reasoning.
It is a pity for you that your contributions only confirm my case.

Maybe I need to repeat this in every reply.

Yes and remember that, therefore, HHH cannot possibly correctly
simulate itself.

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