Re: Category error [ HEAD GAMES ]

[olcott]

On 5/18/2022 10:31 AM, Ben wrote:
> olcott <No...@NoWhere.com> writes:
>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
>> ...[00001358][0021233a][00001352] 50 push eax // push P
>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
>> ...[0000135c][00212336][00001352] 51 push ecx // push P
>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
>
> This can't be the trace of the function you have been talking about.
> The H you claim to have simulates something (no one cares what, but it's
> something) so the code at the start of H should be setting up and
> entering a simulator.
>
> You've admitted you edit some traces which is really not on. I think
> you should stop posting them until you can be honest about them.
>
> Mind you, my personally guess is that the trace is fundamentally honest
> about you've been pulling our legs about what H really does. It's just
> the top-level x86 emulator that does that does any "simulating" and H
> really does call P which calls H which calls P...
>

ON THE BASIS OF THE X86 MACHINE CODE PROVIDED FOR P AND THE
EXECUTION TRACE OF P PROVIDED BY H IT IS EASY TO SEE THAT
THE EXECUTION TRACE OF P IS THE EXECUTION TRACE OF P THAT
WOULD OCCUR IF H PERFORMED A PURE SIMULATION OF THE FIRST
13 INSTRUCTIONS OF P.

BECAUSE OF THIS THE INSISTENCE ON SEEING THE HUNDREDS OF
PAGES OF THE EXECUTION TRACE OF H OR THE SOURCE-CODE OF H
IS A JACKASS MOVE THAT IS ONLY PLAYING HEAD GAMES.

#include <stdint.h>
#define u32 uint32_t

void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001372][0010229e][00000000] 55 push ebp
...[00001373][0010229e][00000000] 8bec mov ebp,esp
...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

H sees that P is calling the same function from the same machine address
with identical parameters, twice in sequence. This is the infinite
recursion (infinitely nested simulation) non-halting behavior pattern.

...[00001384][0010229e][00000000] 83c408 add esp,+08
...[00001387][0010229a][00000000] 50 push eax
...[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
...[00001392][0010229e][00000000] 83c408 add esp,+08
...[00001395][0010229e][00000000] 33c0 xor eax,eax
...[00001397][001022a2][00100000] 5d pop ebp
...[00001398][001022a6][00000004] c3 ret
Number_of_User_Instructions(1)
Number of Instructions Executed(15892)


Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5



--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

[Richard Damon]

And the trace starts to LIE right here unless H actually calls P

> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50         push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> H sees that P is calling the same function from the same machine address
> with identical parameters, twice in sequence. This is the infinite
> recursion (infinitely nested simulation) non-halting behavior pattern.

But H is seeing things, since it is looking at an incorrect trace,
unless the H that P called did just call P, then H is proven to NOT be a
computation as H(P,P) does different things at different times.

[olcott]

On 5/18/2022 8:20 PM, olcott wrote:

>> Ah, "if".  So you admit that you are tracing an H this is not the one
>> you have been describing, or are you just trying to justify editing the
>> trace?  You should be clear on this point.
>
> THE TRACE OF H IS IRRELEVANT, WHAT ARE YOU STUPID?

>
>>> BECAUSE OF THIS THE INSISTENCE ON SEEING THE HUNDREDS OF
>>> PAGES OF THE EXECUTION TRACE OF H OR THE SOURCE-CODE OF H
>>> IS A JACKASS MOVE THAT IS ONLY PLAYING HEAD GAMES.
>>

>> Yes, I want to see a trace of the function you claim have,
>
> IF YOU CAN'T TELL FROM THE TRACE THAT H PRODUCES THAT H CORRECTLY
> DECIDES ITS INPUT YOU SIMPLY ARE NOT ANYWHERE IN THE BALLPARK SMART
> ENOUGH TO CORRECTLY ANALYZE MY WORK.
>
> I AM MUCH MORE APT TO BELIEVE DISHONEST RATHER THAN STUPID.

I only want to treat you fairly and with honesty. Now that you have
finally demonstrated excellent programming skills I finally have a basis
to know a key aspect of your technical skills that were never previously
confirmed.

Anyone with the skills that you demonstrated that never saw the x86
language ever before would be able to correctly analyze the execution
trace of the input to H(P,P) and confirm that it is correct.

>
>> not a made up
>> edited trace, or a trace of some other function altogether.  Though what
>> I really want if fo you to be brave enough to publish H.
>>
>
> THIS IS THE ACTUAL TRACE OF THE INPUT TO H(P,P) THAT H ACTUALLY PRODUCES.

[olcott]

On 5/19/2022 3:29 AM, Malcolm McLean wrote:

> P calls H. But H, as you have described it, doesn't call P. It emulates it.
> But the trace seems to show a call. The infinite cycle detector, as you
> have described it is based on a call.
>
> So it's unclear what is going on.


It is a little annoying that I have to say this 150 times and people
can't remember that I said it even once. I take this as head games.
H(P,P) emulates its input that calls H(P,P) that emulates its input.

Because H only emulates the first 7 instructions of its input H cannot
possibly have any effect on the behavior of this input. This means that
there is no need to see the 237 pages of the execution trace of H.

Furthermore we can easily verify that these first 7 instructions of P
are emulated correctly because the execution trace provided by H exactly
matches the behavior specified by these first 7 instructions of P.

> And it turns out that the traces are edited.

I removed some of the extraneous debug information about the memory
allocation. A normal execution trace would not show this. I changed the
source-code so that it doesn't display this.

My purpose in providing the memory allocation information was to prove
that there really are several independent processes. H(P,P) emulating
its input that calls H(P,P) that emulates its input.

> So is the second part of the trace the output of the emulated emulator?
>

The first 7 lines are emulated by the emulator, the second 7 lines are
emulated by the emulated emulator.

> That seems the best explanation, but we can't be sure that this is going on.

[olcott]

On 5/19/2022 6:56 AM, Ben wrote:
> olcott <No...@NoWhere.com> writes:
>

>>> Ah, "if". So you admit that you are tracing an H this is not the one
>>> you have been describing, or are you just trying to justify editing the
>>> trace? You should be clear on this point.
>>
>> THE TRACE OF H IS IRRELEVANT, WHAT ARE YOU STUPID?
>

> Another question you won't answer. What are you hiding?

A confusing mess of ridiculously complex and totally irrelevant
information that you have consistently proven incapable of comprehending.

>
> We already know that H is not deciding the halting instance that it
> should (i.e. whether the call P(P) halts or not) but it also seems you
> are being deceptive about what H is really doing.

>

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

H sees that P is calling the same function from the same machine address
with identical parameters, twice in sequence. This is the infinite
recursion (infinitely nested simulation) non-halting behavior pattern.

[Richard Damon]

But that isn't what the trace shows. The second trace of P is NOT what
actually happens.

>
> Because H only emulates the first 7 instructions of its input H cannot
> possibly have any effect on the behavior of this input. This means that
> there is no need to see the 237 pages of the execution trace of H.
>

But it DOES have inpact on the copy of P that calls it, and because H
needes

> Furthermore we can easily verify that these first 7 instructions of P
> are emulated correctly because the execution trace provided by H exactly
> matches the behavior specified by these first 7 instructions of P.

Except that you don't correctly emulate the REST of P, which includes
the code of H. The "copy" of H that P calls is part of the execution
history of the Program P.

>
>> And it turns out that the traces are edited.
>
> I removed some of the extraneous debug information about the memory
> allocation. A normal execution trace would not show this. I changed the
> source-code so that it doesn't display this.

Maybe it is H that edits it itself. Still says the trace is NOT a trace
of the execution path of the PROGRAM P.

"Subroutine" P is not a computation by itself. The bytes you are calling
the "representation" of P is not comp[ete. This just shows that you are
just lying about following the proof.

>
> My purpose in providing the memory allocation information was to prove
> that there really are several independent processes. H(P,P) emulating
> its input that calls H(P,P) that emulates its input.

But you don't show the ACTUAL execution trace of what the program P
does, which after P calls H is to start emulating the input that P gave
to the function H. Remember, the PROGRAM P, includes as part of its code
ALL the code that would be executed if you directly execute P as an
independent program, which includes all of H, and anything H uses.

>
>> So is the second part of the trace the output of the emulated emulator?
>>
>
> The first 7 lines are emulated by the emulator, the second 7 lines are
> emulated by the emulated emulator.

SO NOT a trace of the emulation of the P that the top level H is
deciding on.

THAT is the error. The transformation of an emulation of an emulator to
the emulation of the emulated code is ONLY valid for unconditional
emulation, which H does not do.

So, that transformation is an INVALID logical operation, and thus makes
your whole arguemet INCORRECT.


My guess (and will admit that it is only a guess) is that your H doesn't
actually have the code to emulate, but that H is just an API into your
overall simulation system, which is INCAPABLE of actually emulating its
emulation of the input (and thus switches to showing the trace of the
code being emulated by the emulator and not the emulation of that code
(with its conditionals to abort on what it INCORRECT decides in infinite
recursion). This make your H NOT actually meeting the requirements of a
Computation that is the equivalent of a Turing Machine.

[Richard Damon]

The LIE starts here.

NO CPU will go to address 00001352 as a result of a call 000011A2.

Thus, this is NOT a correct trace.

Since you are basing you analysis on a FALSE trace, your results are
invalid.

You are just proving that your setup is BROKEN.

> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50         push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> H sees that P is calling the same function from the same machine address
> with identical parameters, twice in sequence. This is the infinite
> recursion (infinitely nested simulation) non-halting behavior pattern.
>

Nope, please provide a reference to this that includes handling a
CONDITIONAL emulation in the loop.

You are just proving that your knowledge of this sort of thing is abismal

[olcott]

> You'll have to make it public one day, unless chatting on here is your
> only objective.

ANYONE WITH SUFFICIENT TECHNICAL COMPETENCE THAT IS NOT A GOD DAMNED
LIAR KNOWS THAT I ALREADY TOTALLY PROVED MY POINT THAT H(P,P)==0 IS
CORRECT.

...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

H sees that P is calling the same function from the same machine address
with identical parameters, twice in sequence. This is the infinite
recursion (infinitely nested simulation) non-halting behavior pattern.

...[00001384][0010229e][00000000] 83c408 add esp,+08
...[00001387][0010229a][00000000] 50 push eax
...[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
...[00001392][0010229e][00000000] 83c408 add esp,+08
...[00001395][0010229e][00000000] 33c0 xor eax,eax
...[00001397][001022a2][00100000] 5d pop ebp
...[00001398][001022a6][00000004] c3 ret
Number_of_User_Instructions(1)

Number of Instructions Executed(15892) = 237 pages


> No one will take deceptively edited traces as evidence
> of anything but you being shifty, and since you've already abandoned any
> pretence at talking about the halting problem, all you have is this
> faked-up trace of the simulation.

ANYONE WITH SUFFICIENT TECHNICAL COMPETENCE THAT IS NOT A GOD DAMNED
LIAR KNOWS THAT I ALREADY TOTALLY PROVED MY POINT THAT H(P,P)==0 IS
CORRECT.

ONE CAN VERIFY THAT THE EXECUTION TRACE IS CORRECT ON THE BASIS THAT THE
EXECUTION TRACE PROVIDED CORRESPONDS TO THE X86 SOURCE-CODE OF H(P,P)
EMULATING ITS INPUT CALLING H(P,P) THAT EMULATES ITS INPUT.

I DON'T BELIEVE THAT YOU DON'T SEE THIS.

> H(P,P) == false is wrong about the halting of P(P) and the trace does
> not back-up what you say your H is doing. There's nothing left here.
>
> But there's always the TM emulator... How's that coming along?
>

There are about two lines of code that are out-of-place. I have been ill
and had other issues that I had to deal with.

[Richard Damon]

But the trace is false, so the application of the rule is incorrect.

H sees P calling H which CONDITIONALLY simulates P which calls H

The CONDITIONAL simulation break your "rule"

FAIL

>
> ...[00001384][0010229e][00000000] 83c408     add esp,+08
> ...[00001387][0010229a][00000000] 50         push eax
> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
> "Input_Halts = "
> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
> Input_Halts = 0
> ...[00001392][0010229e][00000000] 83c408     add esp,+08
> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
> ...[00001397][001022a2][00100000] 5d         pop ebp
> ...[00001398][001022a6][00000004] c3         ret
> Number_of_User_Instructions(1)
> Number of Instructions Executed(15892) = 237 pages
>
>
>> No one will take deceptively edited traces as evidence
>> of anything but you being shifty, and since you've already abandoned any
>> pretence at talking about the halting problem, all you have is this
>> faked-up trace of the simulation.
>
> ANYONE WITH SUFFICIENT TECHNICAL COMPETENCE THAT IS NOT A GOD DAMNED
> LIAR KNOWS THAT I ALREADY TOTALLY PROVED MY POINT THAT H(P,P)==0 IS
> CORRECT.

Nope, you have just proved that YOU are INCOMPETENT and a LIAR.

H(P,P) == 0 can NOT be correct if H is a Halting Decider.

Maybe it is a correct POOP decider, but not a Halting Decider.

Your arguement that it can't use the actual defintion is just support of
the Theorem. If you can't ask the question, you can't answer it correctly.

>
> ONE CAN VERIFY THAT THE EXECUTION TRACE IS CORRECT ON THE BASIS THAT THE
> EXECUTION TRACE PROVIDED CORRESPONDS TO THE X86 SOURCE-CODE OF H(P,P)
> EMULATING ITS INPUT CALLING H(P,P) THAT EMULATES ITS INPUT.

But the call to H needs to trace H. And, unless H actually calls P (and
thus losing the ability to 'abort' it) the 'Second' round in P never
actualy occurs as an exectution of P, it is all just a simulation
(inside the simulation) of P

>
> I DON'T BELIEVE THAT YOU DON'T SEE THIS.

Me either, you are dumber than an ox.

You don't get to change the rules, doing so just proves your ignorance
of how logic works. Shows how pitiful is your whole idea.

[olcott]

THE EXECUTION TRACE OF THE INPUT TO H(P,P) CORRESPONDS TO

THE BEHAVIOR SPECIFIED BY THE X86 SOURCE-CODE OF P

WHERE H(P,P) CORRECTLY EMULATES ITS INPUT

THAT CALLS H(P,P) THAT CORRECTLY EMULATES ITS INPUT

[Python]

Peter Olcott wrote:
> On 5/19/2022 2:19 PM, Ben wrote:

...

>> But there's always the TM emulator...  How's that coming along?
>>
>
> There are about two lines of code that are out-of-place. I have been ill
> and had other issues that I had to deal with.

It should have taken four hours, remember?

You are a joke, a kook, a pretender.

[Richard Damon]

NOPE, Becaue P calls H, but the trace doesn't show anything in H.

H is defined to EMULATE its input, not call it.

>
> WHERE H(P,P) CORRECTLY EMULATES ITS INPUT
>
> THAT CALLS H(P,P) THAT CORRECTLY EMULATES ITS INPUT

So, why don't we see the EMULATION of H EMULATING P?

Just shows you are LYING, and presenting a FALSE trace.

[olcott]

I have been sick from chemotherapy.
I almost had to go the the hospital again last night.
I had to spend two days in the hospital three weeks ago.
My design scales much better than Ben's design.
Ben's design takes O(N) for state transitions.
My design takes log2(N) for state transitions.

[Richard Damon]

On 5/19/22 6:43 PM, olcott wrote:
> On 5/19/2022 4:38 PM, Python wrote:
>> Peter Olcott wrote:
>>> On 5/19/2022 2:19 PM, Ben wrote:
>> ...
>>>> But there's always the TM emulator...  How's that coming along?
>>>>
>>>
>>> There are about two lines of code that are out-of-place. I have been
>>> ill and had other issues that I had to deal with.
>>
>> It should have taken four hours, remember?
>>
>> You are a joke, a kook, a pretender.
>>
>
> I have been sick from chemotherapy.
> I almost had to go the the hospital again last night.
> I had to spend two days in the hospital three weeks ago.
> My design scales much better than Ben's design.
> Ben's design takes O(N) for state transitions.
> My design takes log2(N) for state transitions.
>

My design is O(1) for state transitions, so it scales even better. (Bit
more overhead on reading in the design, but is O(1) for running)

[olcott]

Normally for a DFA one always has O(1) because the current input and
current state are in a fully populated matrix. When the current state,
current input are in a sparse matrix a fully populated matrix wastes too
mach space. In this case O log2(N) is the best that we can do. I had to
do this for my DFA based OCR system because the current input was a
short list of 24-bit pixels.

[Richard Damon]

But it is easy to convert the sparce matrix into a dense one with a
simple mapping layer, and if you keep the inverse map around it is still
simple to make your output (and keep even that O(1))

The other option is to use a hash table to find entries.

Since for any case that matters, the run time vastly outweighs the time
to read the description, spending just a bit up front to optimize the
state transitions is likely worth it.

And, if you are limiting your states and symbols to the basic character
set, even the sparce table isn't that big for a modern computer (It
likely still fits in L1 cache)

[olcott]

On 5/20/2022 6:25 AM, Ben wrote:
> olcott <No...@NoWhere.com> writes:
>

>>> Rather than shouting, you could either publish an honest, un-edited
>>> execution trace,
>>
>> If you can't understand that a single page already proves that
>> H(p,P)==0 is correct it is certainly the case that providing 237-fold
>> more details [would not help].
>
> (Your correction added)
>
> Yours traces are edited. No one will believe them until you post the
> real trace, and even then you will have some work to do to convince
> people you are being honest about the output.
>

I can simply upgrade to smarter people that don't lie.

They would be able to confirm that the execution trace of the first 7
instructions of the input to H(P,P) is the execution trace of P.
Malcolm already did that.

When I tell them that H only performs a pure simulation of its input
then these smart non-liars would be able to confirm that the next 7
lines of the execution trace of P are the correct 7 lines for this
nested simulation of P.

These smart non-liars would know that they don't need the 237 pages of
execution trace or the source-code of H to definitively determine that
H(P,P)==0 is correct. They would be able to see the P does specify
infinitely nested simulation that never reaches its own final state at
machine address: [0000136c].

> Anyway, it's no skin off my nose. H fails at the task you once set
> yourself -- the one the word cares about -- so finding out what H is
> actually deciding is just an amusing distraction.

[Richard Damon]

On 5/20/22 10:51 AM, olcott wrote:
> On 5/20/2022 6:25 AM, Ben wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> On 5/19/2022 7:53 PM, Ben wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> ONE CAN VERIFY THAT THE EXECUTION TRACE IS CORRECT ON THE BASIS THAT
>>>>> THE EXECUTION TRACE OF THE INPUT TO H(P,P) CORRESPONDS TO
>>>>> THE BEHAVIOR SPECIFIED BY THE X86 SOURCE-CODE OF P
>>>>> WHERE H(P,P) CORRECTLY EMULATES ITS INPUT
>>>>> THAT CALLS H(P,P) THAT CORRECTLY EMULATES ITS INPUT
>>>>
>>>> Rather than shouting, you could either publish an honest, un-edited
>>>> execution trace,
>>>
>>> If you can't understand that a single page already proves that
>>> H(p,P)==0 is correct it is certainly the case that providing 237-fold
>>> more details [would not help].
>>
>> (Your correction added)
>>
>> Yours traces are edited.  No one will believe them until you post the
>> real trace, and even then you will have some work to do to convince
>> people you are being honest about the output.
>>
>
> I can simply upgrade to smarter people that don't lie.

You mean replace yourself?

The other people are not lying, you are.

>
> They would be able to confirm that the execution trace of the first 7
> instructions of the input to H(P,P) is the execution trace of P.
> Malcolm already did that.
>
> When I tell them that H only performs a pure simulation of its input
> then these smart non-liars would be able to confirm that the next 7
> lines of the execution trace of P are the correct 7 lines for this
> nested simulation of P.

LIE. H does NOT do a "Pure Simulation" by the meaning of the words,
since it can abort its simulation.

There is no such thing as Conditional Unconditional processing.

The is no actual execution of P inside the simulation done by the H
called by P, so reporting that is just a LIE.

>
> These smart non-liars would know that they don't need the 237 pages of
> execution trace or the source-code of H to definitively determine that
> H(P,P)==0 is correct. They would be able to see the P does specify
> infinitely nested simulation that never reaches its own final state at
> machine address: [0000136c].

No, we just need to simple examination of the code to see that H(P,P)
must be wrong to say P(P) is non-halting when it returns 0.

If it isn't answering about P(P), then YOU are LYING that H is a Halting
Decider.

>
>

BEGIN THE BIG LIE.

[Ben]

olcott <No...@NoWhere.com> writes:

> On 5/20/2022 6:25 AM, Ben wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> On 5/19/2022 7:53 PM, Ben wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> ONE CAN VERIFY THAT THE EXECUTION TRACE IS CORRECT ON THE BASIS THAT
>>>>> THE EXECUTION TRACE OF THE INPUT TO H(P,P) CORRESPONDS TO
>>>>> THE BEHAVIOR SPECIFIED BY THE X86 SOURCE-CODE OF P
>>>>> WHERE H(P,P) CORRECTLY EMULATES ITS INPUT
>>>>> THAT CALLS H(P,P) THAT CORRECTLY EMULATES ITS INPUT
>>>>
>>>> Rather than shouting, you could either publish an honest, un-edited
>>>> execution trace,
>>>
>>> If you can't understand that a single page already proves that
>>> H(p,P)==0 is correct it is certainly the case that providing 237-fold
>>> more details [would not help].
>> (Your correction added)
>>

>> Your traces are edited. No one will believe them until you post the

>> real trace, and even then you will have some work to do to convince
>> people you are being honest about the output.
>
> I can simply upgrade to smarter people that don't lie.

I don't lie. Your trace does not show what you claim H is doing. And
having admitted to editing the traces, no one is going to believe you.

But I urge you, most forcefully, to find someone to review your claims
who you have enough respect for to listen to what they have to say.

> These smart non-liars would know that they don't need the 237 pages of
> execution trace or the source-code of H to definitively determine that
> H(P,P)==0 is correct.

It would be dumb to accept edited traces that don't show the nested
emulation you claim is occurring. Maybe you can find a smart sucker out
there? We all know they exist.

But first you'd have explain why they should care about what H is
actually deciding since it isn't the halting of the call specified by
the problem definition. Apparently you accept (but dare not actually
state) that not algorithm an do what H is supposed to do. It'll be hard
to get people enthusiastic about a function that just gets halting of
the conventional constriction wrong.

> Number of Instructions Executed(15892) = 237 pages

Post it all (if indeed it even exists) or better yet, stop keeping H a
secret.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

[olcott]

On 5/20/2022 11:41 AM, Ben wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 5/20/2022 11:26 AM, Ben wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 5/20/2022 10:12 AM, Ben wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 5/20/2022 6:25 AM, Ben wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 5/19/2022 7:53 PM, Ben wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> ONE CAN VERIFY THAT THE EXECUTION TRACE IS CORRECT ON THE BASIS THAT
>>>>>>>>>> THE EXECUTION TRACE OF THE INPUT TO H(P,P) CORRESPONDS TO
>>>>>>>>>> THE BEHAVIOR SPECIFIED BY THE X86 SOURCE-CODE OF P
>>>>>>>>>> WHERE H(P,P) CORRECTLY EMULATES ITS INPUT
>>>>>>>>>> THAT CALLS H(P,P) THAT CORRECTLY EMULATES ITS INPUT
>>>>>>>>>
>>>>>>>>> Rather than shouting, you could either publish an honest, un-edited
>>>>>>>>> execution trace,
>>>>>>>>
>>>>>>>> If you can't understand that a single page already proves that
>>>>>>>> H(p,P)==0 is correct it is certainly the case that providing 237-fold
>>>>>>>> more details [would not help].
>>>>>>> (Your correction added)
>>>>>>>
>>>>>>> Your traces are edited. No one will believe them until you post the
>>>>>>> real trace, and even then you will have some work to do to convince
>>>>>>> people you are being honest about the output.
>>>>>>
>>>>>> I can simply upgrade to smarter people that don't lie.
>>>>>
>>>>> I don't lie. Your trace does not show what you claim H is doing.
>>>>

>>>> That is either a lie or you are very stupid and I do not believe that
>>>> you are very stupid.
>>> I really don't care. The trace of a nested emulation would not look
>>> like your trace.
>>
>> This <is> the trace of the nested emulation of the input to H(P,P)
>
> So you say. But there are no signs of anything but an edited sequence
> of function calls. No emulation code appears at all. You may have
> removed the evidence that you are right, but that would an absurd thing
> to do.


NONE-THE-LESS WHEN WE REVERSE ENGINEER WHAT THE CORRECT NESTED
SIMULATION OF THE INPUT TO H(P,P) WOULD BE IT EXACTLY MATCHES THE TRACE
THAT IS PROVIDED THUS CONCLUSIVELY PROVING THAT THE TRACE PROVIDED IS
CORRECT.

>> You will be exposed as a liar when you try to show any error in the
>> execution trace of the nested simulation of the input to H(P,P).
>
> Post H and I'll gladly explain. We know that H is not a halt decider,
> but we don't know exactly what silly thing it really is deciding because
> you post only edited execution traces.

[olcott]

On 5/20/2022 11:41 AM, Ben wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 5/20/2022 11:26 AM, Ben wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 5/20/2022 10:12 AM, Ben wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 5/20/2022 6:25 AM, Ben wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 5/19/2022 7:53 PM, Ben wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> ONE CAN VERIFY THAT THE EXECUTION TRACE IS CORRECT ON THE BASIS THAT
>>>>>>>>>> THE EXECUTION TRACE OF THE INPUT TO H(P,P) CORRESPONDS TO
>>>>>>>>>> THE BEHAVIOR SPECIFIED BY THE X86 SOURCE-CODE OF P
>>>>>>>>>> WHERE H(P,P) CORRECTLY EMULATES ITS INPUT
>>>>>>>>>> THAT CALLS H(P,P) THAT CORRECTLY EMULATES ITS INPUT
>>>>>>>>>
>>>>>>>>> Rather than shouting, you could either publish an honest, un-edited
>>>>>>>>> execution trace,
>>>>>>>>
>>>>>>>> If you can't understand that a single page already proves that
>>>>>>>> H(p,P)==0 is correct it is certainly the case that providing 237-fold
>>>>>>>> more details [would not help].
>>>>>>> (Your correction added)
>>>>>>>
>>>>>>> Your traces are edited. No one will believe them until you post the
>>>>>>> real trace, and even then you will have some work to do to convince
>>>>>>> people you are being honest about the output.
>>>>>>
>>>>>> I can simply upgrade to smarter people that don't lie.
>>>>>
>>>>> I don't lie. Your trace does not show what you claim H is doing.
>>>>

>>>> That is either a lie or you are very stupid and I do not believe that
>>>> you are very stupid.
>>> I really don't care. The trace of a nested emulation would not look
>>> like your trace.
>>
>> This <is> the trace of the nested emulation of the input to H(P,P)
>
> So you say. But there are no signs of anything but an edited sequence
> of function calls. No emulation code appears at all. You may have
> removed the evidence that you are right, but that would an absurd thing
> to do.

NONE-THE-LESS WHEN WE REVERSE ENGINEER WHAT THE CORRECT NESTED
SIMULATION OF THE INPUT TO H(P,P) WOULD BE IT EXACTLY MATCHES THE TRACE
THAT IS PROVIDED THUS CONCLUSIVELY PROVING THAT THE TRACE PROVIDED IS
CORRECT.

>> You will be exposed as a liar when you try to show any error in the
>> execution trace of the nested simulation of the input to H(P,P).
>
> Post H and I'll gladly explain. We know that H is not a halt decider,
> but we don't know exactly what silly thing it really is deciding because
> you post only edited execution traces.
>

[olcott]

On 5/20/2022 11:41 AM, Ben wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 5/20/2022 11:26 AM, Ben wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 5/20/2022 10:12 AM, Ben wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 5/20/2022 6:25 AM, Ben wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 5/19/2022 7:53 PM, Ben wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> ONE CAN VERIFY THAT THE EXECUTION TRACE IS CORRECT ON THE BASIS THAT
>>>>>>>>>> THE EXECUTION TRACE OF THE INPUT TO H(P,P) CORRESPONDS TO
>>>>>>>>>> THE BEHAVIOR SPECIFIED BY THE X86 SOURCE-CODE OF P
>>>>>>>>>> WHERE H(P,P) CORRECTLY EMULATES ITS INPUT
>>>>>>>>>> THAT CALLS H(P,P) THAT CORRECTLY EMULATES ITS INPUT
>>>>>>>>>
>>>>>>>>> Rather than shouting, you could either publish an honest, un-edited
>>>>>>>>> execution trace,
>>>>>>>>
>>>>>>>> If you can't understand that a single page already proves that
>>>>>>>> H(p,P)==0 is correct it is certainly the case that providing 237-fold
>>>>>>>> more details [would not help].
>>>>>>> (Your correction added)
>>>>>>>
>>>>>>> Your traces are edited. No one will believe them until you post the
>>>>>>> real trace, and even then you will have some work to do to convince
>>>>>>> people you are being honest about the output.
>>>>>>
>>>>>> I can simply upgrade to smarter people that don't lie.
>>>>>
>>>>> I don't lie. Your trace does not show what you claim H is doing.
>>>>

>>>> That is either a lie or you are very stupid and I do not believe that
>>>> you are very stupid.
>>> I really don't care. The trace of a nested emulation would not look
>>> like your trace.
>>
>> This <is> the trace of the nested emulation of the input to H(P,P)
>
> So you say. But there are no signs of anything but an edited sequence
> of function calls. No emulation code appears at all. You may have
> removed the evidence that you are right, but that would an absurd thing
> to do.


NONE-THE-LESS WHEN WE REVERSE ENGINEER WHAT THE CORRECT NESTED
SIMULATION OF THE INPUT TO H(P,P) WOULD BE IT EXACTLY MATCHES THE TRACE
THAT IS PROVIDED THUS CONCLUSIVELY PROVING THAT THE TRACE PROVIDED IS
CORRECT.

>> You will be exposed as a liar when you try to show any error in the
>> execution trace of the nested simulation of the input to H(P,P).
>
> Post H and I'll gladly explain. We know that H is not a halt decider,
> but we don't know exactly what silly thing it really is deciding because
> you post only edited execution traces.
>

[Richard Damon]

Nope.

[Richard Damon]

On 5/20/22 4:33 PM, olcott wrote:

Nope.

[Richard Damon]

On 5/20/22 4:33 PM, olcott wrote:

Nope/