olcott <NoOne@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 5/18/2022 10:31 AM, Ben wrote:
olcott <NoOne@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
On 5/18/2022 7:57 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 5/18/2022 10:31 AM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
Begin Local Halt Decider Simulation Execution Trace Stored at:212352 >>>>> ...[00001352][0021233e][00212342] 55 push ebp // enter PThis can't be the trace of the function you have been talking about.
...[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
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.
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.
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 <NoOne@NoWhere.com> writes:
On 5/18/2022 7:57 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 5/18/2022 10:31 AM, Ben wrote:
olcott <NoOne@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,espentering a simulator.
...[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
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.
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?
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.
On Thursday, 19 May 2022 at 06:26:28 UTC+1, olcott wrote:
On 5/18/2022 8:20 PM, olcott 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
On 5/18/2022 7:57 PM, Ben wrote:I only want to treat you fairly and with honesty. Now that you have
olcott <No...@NoWhere.com> writes:
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,espsomething) so the code at the start of H should be setting up and
...[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
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.
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.
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.
have described it is based on a call.
So it's unclear what is going on.
And it turns out that the traces are edited.
So is the second part of the trace the output of the emulated emulator?
That seems the best explanation, but we can't be sure that this is going on.
On 5/19/2022 6:56 AM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 5/18/2022 7:57 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 5/18/2022 10:31 AM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
Begin Local Halt Decider Simulation Execution Trace StoredThis 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,
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
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.
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.
On 5/19/2022 3:29 AM, Malcolm McLean wrote:
On Thursday, 19 May 2022 at 06:26:28 UTC+1, olcott wrote:
On 5/18/2022 8:20 PM, olcott wrote:P calls H. But H, as you have described it, doesn't call P. It
On 5/18/2022 7:57 PM, Ben wrote:I only want to treat you fairly and with honesty. Now that you have
olcott <No...@NoWhere.com> writes:
On 5/18/2022 10:31 AM, Ben wrote:
olcott <No...@NoWhere.com> writes:
Begin Local Halt Decider Simulation Execution Trace Stored >>>>>>>> at:212352This 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
...[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
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.
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.
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.
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.
On 5/19/2022 2:19 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 5/19/2022 6:56 AM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 5/18/2022 7:57 PM, Ben wrote:Another question you won't answer. What are you hiding?
olcott <NoOne@NoWhere.com> writes:
On 5/18/2022 10:31 AM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
Begin Local Halt Decider Simulation Execution Trace Stored >>>>>>>>> at:212352This can't be the trace of the function you have been talking
...[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
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.
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?
A confusing mess of ridiculously complex and totally irrelevant
information that you have consistently proven incapable of
comprehending.
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.
#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) = 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.
olcott <NoOne@NoWhere.com> writes:
On 5/19/2022 6:56 AM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 5/18/2022 7:57 PM, Ben wrote:Another question you won't answer. What are you hiding?
olcott <NoOne@NoWhere.com> writes:
On 5/18/2022 10:31 AM, Ben wrote:
olcott <NoOne@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,espsomething) so the code at the start of H should be setting up and >>>>>>> entering a simulator.
...[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
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.
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?
A confusing mess of ridiculously complex and totally irrelevant
information that you have consistently proven incapable of
comprehending.
You'll have to make it public one day, unless chatting on here is your
only objective.
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.
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?
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.
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.
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.
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)
On 5/19/2022 5:58 PM, Richard Damon wrote:
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)
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 115:36:48 |
| Calls: | 6,662 |
| Files: | 12,209 |
| Messages: | 5,334,132 |