#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H would never reach the "ret" instruction of P because both H and P would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite number
of steps then H could reject its input on this basis. Here are the
details of exactly how H does this in a finite number of steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [000010d2][00211e8a][00211e8e] 55 push ebp [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] [000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] [000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*) Allocate(sizeof(Registers));
Registers* slave_state = (Registers*) Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:", execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
&slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily examine
its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an accept or reject state on the basis of the actual behavior that is actually
specified by these inputs.
computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
On 6/21/22 10:38 PM, olcott wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite number
of steps then H could reject its input on this basis. Here are the
details of exactly how H does this in a finite number of steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k; >> u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state,
&slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the
DEFINITION of the behavior of H(P,P),
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is wrong.
On 6/21/2022 9:52 PM, Richard Damon wrote:
On 6/21/22 10:38 PM, olcott wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here are
the details of exactly how H does this in a finite number of steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state,
&slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the
DEFINITION of the behavior of H(P,P),
Linz and others were aware that: A halt decider must compute the mapping
from its inputs to an accept or reject state on the basis of the actual behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of
this because no one previously fully examined a simulating halt decider
ever before.
especially if that is what P calls and P is claimed to be built by the
Linz template.
So, either P isn't built right, or H isn't built fight, or H is wrong.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:That is an actual immutable verified fact.
On 6/21/2022 9:52 PM, Richard Damon wrote:You've dry-run P(P) and it doesn't halt. Additionally the halt decider H >>> reports it as non-halting. So it's reasonable to assume that H is correct. >>>
Linz and others were aware that: A halt decider must compute the mapping >>>> from its inputs to an accept or reject state on the basis of the actual >>>> behavior that is actually specified by these inputs.
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H >>>>> was incorrect in its mapping, since the behavior of P(P) is the
DEFINITION of the behavior of H(P,P),
Linz and others made the false assumption that the actual behavior that >>>> is actually specified by the inputs to a simulating halt decider is not >>>> the same as the direct execution of these inputs. They were unaware of >>>> this because no one previously fully examined a simulating halt decider >>>> ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is wrong. >>>>
However, when run, P(P) halts. So what are we to conclude? That "the
actual behaviour that is actually specified by the inputs to a simulating >>> halt decider is not the same as the direct execution of these inputs"?
dry-run P(P), and it doesn't halt. You've run H on P(P), and it reports "non-halting".
You've run P(P), and it halts.
So one explanation is the one you've given but, as I said, that explanation has
rather far-reaching consequences. In these circumstances, the sensible scientist (or I suppose mathematician, though I'm a scientist and not a mathematician) looks for alternative explanations which aren't quite as consequential.
That would be one consequence of going with your explanation. We'd have to say the behaviour of P(P) differs depending on caller. As I said, try simpler,That would have far-reaching consequences. Before going there, maybeThere are no alternatives to immutable verified facts. H(P,P) halts only
think up some simpler, alternative explanations and eliminate them.
because H(P,P) correctly determines that its input never halts.
Technically competent software engineers would agree. On the basis of
the much more complete details that I provided in my original post.
When P(P) is called from main its behavior depends on the return value
of H. When H is called from main P(P) cannot possibly depend on the
return value of H because the correctly emulated input to H(P,P)
continues to remain stuck in infinite emulation until H aborts it.
less far-reaching explanations first.
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
On 6/21/2022 9:52 PM, Richard Damon wrote:You've dry-run P(P) and it doesn't halt. Additionally the halt decider H reports it as non-halting. So it's reasonable to assume that H is correct.
Linz and others were aware that: A halt decider must compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the
DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of
this because no one previously fully examined a simulating halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is wrong.
However, when run, P(P) halts. So what are we to conclude? That "the
actual behaviour that is actually specified by the inputs to a simulating halt decider is not the same as the direct execution of these inputs"?
That would have far-reaching consequences. Before going there, maybe
think up some simpler, alternative explanations and eliminate them.
On 6/22/2022 7:45 AM, Malcolm McLean wrote:
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:That is an actual immutable verified fact.
On 6/21/2022 9:52 PM, Richard Damon wrote:You've dry-run P(P) and it doesn't halt. Additionally the halt
Linz and others were aware that: A halt decider must compute the
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H >>>>>> was incorrect in its mapping, since the behavior of P(P) is the
DEFINITION of the behavior of H(P,P),
mapping
from its inputs to an accept or reject state on the basis of the
actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual behavior
that
is actually specified by the inputs to a simulating halt decider is
not
the same as the direct execution of these inputs. They were unaware of >>>>> this because no one previously fully examined a simulating halt
decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is
wrong.
decider H
reports it as non-halting. So it's reasonable to assume that H is
correct.
However, when run, P(P) halts. So what are we to conclude? That "the
actual behaviour that is actually specified by the inputs to a
simulating
halt decider is not the same as the direct execution of these inputs"?
dry-run P(P), and it doesn't halt. You've run H on P(P), and it
reports "non-halting".
You've run P(P), and it halts.
So one explanation is the one you've given but, as I said, that
explanation has
rather far-reaching consequences. In these circumstances, the sensible
scientist (or I suppose mathematician, though I'm a scientist and not a
mathematician) looks for alternative explanations which aren't quite as
consequential.
That is like looking for alternatives to 5 > 3
5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
That would be one consequence of going with your explanation. We'dThat would have far-reaching consequences. Before going there, maybeThere are no alternatives to immutable verified facts. H(P,P) halts only >>> because H(P,P) correctly determines that its input never halts.
think up some simpler, alternative explanations and eliminate them.
Technically competent software engineers would agree. On the basis of
the much more complete details that I provided in my original post.
When P(P) is called from main its behavior depends on the return value
of H. When H is called from main P(P) cannot possibly depend on the
return value of H because the correctly emulated input to H(P,P)
continues to remain stuck in infinite emulation until H aborts it.
have to
say the behaviour of P(P) differs depending on caller. As I said, try
simpler,
less far-reaching explanations first.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
H(P,P)==0 is provably correct
H1(P,P)==1 is provably correct.
H1(P,P) reports on the behavior of P(P).
On 6/21/2022 8:38 PM, olcott wrote:
<SNIPPED GARBAGE UNRELATED TO MSG SUBJECT>
Peter, you must first identify a competent Software Engineer to do said verification. There are two problems: The first is that no competent SE
would verify your claims whether or not you shared your crap code with
them. You don't certify a black box from the outside because there are
too many simple errors that wont be caught.
Yes, it is clear to us humans watching
it that the program is repeating itself.
Thus we can appreciate that it will never
reach the final "ret" - indeed, it won't
even get to the infinite loop identified above.
The second is that you have nominated yourself as a competent SE. NOT!!!
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
On 6/21/2022 9:52 PM, Richard Damon wrote:You've dry-run P(P) and it doesn't halt. Additionally the halt decider H >>>> reports it as non-halting. So it's reasonable to assume that H is correct. >>>>
Linz and others were aware that: A halt decider must compute the mapping >>>>> from its inputs to an accept or reject state on the basis of the actual >>>>> behavior that is actually specified by these inputs.
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H >>>>>> was incorrect in its mapping, since the behavior of P(P) is the
DEFINITION of the behavior of H(P,P),
Linz and others made the false assumption that the actual behavior that >>>>> is actually specified by the inputs to a simulating halt decider is not >>>>> the same as the direct execution of these inputs. They were unaware of >>>>> this because no one previously fully examined a simulating halt decider >>>>> ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is wrong. >>>>>
However, when run, P(P) halts. So what are we to conclude? That "the
actual behaviour that is actually specified by the inputs to a simulating >>>> halt decider is not the same as the direct execution of these inputs"?
That is an actual immutable verified fact.
dry-run P(P), and it doesn't halt. You've run H on P(P), and it
reports "non-halting". You've run P(P), and it halts. So one
explanation is the one you've given but, as I said, that explanation
has rather far-reaching consequences.
There is only one explanation. What you call the "dry-run" is not that
same as the P(P). We've known this since the "line 15 commented out"
days. There are two computations -- one that is not stopped and one
that is, the "dry-run" and the run, the "simulation of the input to
H(P,P)" and P(P). All PO is doing is trying to find words that hide
what's going on.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here are
the details of exactly how H does this in a finite number of steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [000010d2][00211e8a][00211e8e] 55 push ebp [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] [000010d8][00211e86][000010d2] 50 push eax // push P [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] [000010dc][00211e82][000010d2] 51 push ecx // push P [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:", execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <NoOne@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here are
the details of exactly how H does this in a finite number of steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 ...[000013eb][00102353][00000000] 50 push eax ...[000013ec][0010234f][00000427] 6827040000 push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 ...[000013f9][00102357][00000000] 33c0 xor eax,eax ...[000013fb][0010235b][00100000] 5d pop ebp ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <NoOne@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here are
the details of exactly how H does this in a finite number of steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 ...[000013eb][00102353][00000000] 50 push eax ...[000013ec][0010234f][00000427] 6827040000 push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 ...[000013f9][00102357][00000000] 33c0 xor eax,eax ...[000013fb][0010235b][00100000] 5d pop ebp ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <NoOne@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P)
by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 ...[000013eb][00102353][00000000] 50 push eax ...[000013ec][0010234f][00000427] 6827040000 push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 ...[000013f9][00102357][00000000] 33c0 xor eax,eax ...[000013fb][0010235b][00100000] 5d pop ebp ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly
language level. No knowledge of the halting problem is required.
The proof of your technical incompetence that others can see is that
you only stater dogmatically that I am wrong without pointing out any
actual mistakes.
The proof of the technical incompetence of Richard and Ben is that
they intentionally paraphrase what I said incorrect so that they can
use the strawman deception to form a rebuttal on the basis of this intentionally incorrect paraphrase.
straw man
An intentionally misrepresented proposition that is set up because it
is easier to defeat than an opponent's real argument. https://www.lexico.com/en/definition/straw_man
The proof of the technical incompetence of most everyone else is that
they simply provide ad hominem insults as the entire basis of their
fake "rebuttal". That zero rebuttals with any plausible basis have
been presented for many weeks is very encouraging.
On Wed, 22 Jun 2022 15:27:01 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <NoOne@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P)
by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software
engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly
language level. No knowledge of the halting problem is required.
I cannot speak for Richard but I have 30+ years C++ experience; I also
have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
emulator in 80286 assembly) and I can recognize an infinite recursion;
the problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based omnishambles:
the recursion simply isn't there for a "valid" halt
decider, that being a halt decider that can return an answer in finite
time to ALL invokers: H needs to return an answer to Px to be
considered a valid halt decider.
/Flibble
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <NoOne@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P)
by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 ...[000013eb][00102353][00000000] 50 push eax ...[000013ec][0010234f][00000427] 6827040000 push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 ...[000013f9][00102357][00000000] 33c0 xor eax,eax ...[000013fb][0010235b][00100000] 5d pop ebp ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly
language level. No knowledge of the halting problem is required.
On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <NoOne@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to
H(P,P) by H would never reach the "ret" instruction of P because
both H and P would remain stuck in infinitely recursive
emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax //
push P [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx //
push P [000010dd][00211e7e][000010e2] e820feffff call 00000f02
// call H Infinitely Recursive Simulation Detected Simulation
Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state,
slave_stack); Output("\nBegin Simulation Execution Trace
Stored at:", execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called
with. (b) No instructions in P could possibly escape this
otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this
computer science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that
is actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and
Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided
correctly. QED.
/Flibble
You and Richard are insufficiently technically competent at
software engineering not meeting these specs:
A software engineer must be an expert in: the C programming
language, the x86 programming language, exactly how C translates
into x86 and the ability to recognize infinite recursion at the
x86 assembly language level. No knowledge of the halting problem
is required.
I cannot speak for Richard but I have 30+ years C++ experience; I
also have C and x86 assembly experience (I once wrote a Zilog Z80A
CPU emulator in 80286 assembly) and I can recognize an infinite
recursion; the problem is that you cannot recognize the fact that
the infinite recursion only manifests as part of your invalid simulation-based omnishambles:
If you are competent then you already know this is true and lie about
it:
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
Otherwise you are incompetent.
the recursion simply isn't there for a "valid" halt
decider, that being a halt decider that can return an answer in
finite time to ALL invokers: H needs to return an answer to Px to be considered a valid halt decider.
/Flibble
On Wed, 22 Jun 2022 16:41:43 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <NoOne@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to
H(P,P) by H would never reach the "ret" instruction of P because
both H and P would remain stuck in infinitely recursive
emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax //
push P [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx //
push P [000010dd][00211e7e][000010e2] e820feffff call 00000f02
// call H Infinitely Recursive Simulation Detected Simulation
Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state,
slave_stack); Output("\nBegin Simulation Execution Trace
Stored at:", execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called
with. (b) No instructions in P could possibly escape this
otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this
computer science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that
is actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it >>>>>> enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and
Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided
correctly. QED.
/Flibble
You and Richard are insufficiently technically competent at
software engineering not meeting these specs:
A software engineer must be an expert in: the C programming
language, the x86 programming language, exactly how C translates
into x86 and the ability to recognize infinite recursion at the
x86 assembly language level. No knowledge of the halting problem
is required.
I cannot speak for Richard but I have 30+ years C++ experience; I
also have C and x86 assembly experience (I once wrote a Zilog Z80A
CPU emulator in 80286 assembly) and I can recognize an infinite
recursion; the problem is that you cannot recognize the fact that
the infinite recursion only manifests as part of your invalid
simulation-based omnishambles:
If you are competent then you already know this is true and lie about
it:
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
Otherwise you are incompetent.
the recursion simply isn't there for a "valid" halt
decider, that being a halt decider that can return an answer in
finite time to ALL invokers: H needs to return an answer to Px to be
considered a valid halt decider.
/Flibble
Why did you ignore the second part? Again:
The problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based
omnishambles: the recursion simply isn't there for a "valid" halt
decider, that being a halt decider that can return an answer in finite
time to ALL invokers: H needs to return an answer to Px to be
considered a valid halt decider.
/Flibble
On 6/22/2022 12:11 PM, Jeff Barnett wrote:Your words are not clear even to you. Are you really that stupid? Your
On 6/21/2022 8:38 PM, olcott wrote:
<SNIPPED GARBAGE UNRELATED TO MSG SUBJECT>
Peter, you must first identify a competent Software Engineer to do
said verification. There are two problems: The first is that no
competent SE would verify your claims whether or not you shared your
crap code with them. You don't certify a black box from the outside
because there are too many simple errors that wont be caught.
My words are perfectly clear and correct thus leaving the only possible rebuttal of changing the words and forming a rebuttal on the basis of
these changed words.
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H would never reach the "ret" instruction of P because both H and P would remain stuck in infinitely recursive emulation.
After 100 reviewers in a dozen forums over a period of one year:
On 6/14/2022 6:47 AM, Paul N wrote:
Yes, it is clear to us humans watching
it that the program is repeating itself.
Thus we can appreciate that it will never
reach the final "ret" - indeed, it won't
even get to the infinite loop identified above.
If H can determine that this is the case in a finite number of steps
then H could correctly reject its input on this basis.
Sufficiently competent software engineers will agree that if you cannot verify that the above reasoning is valid forms sufficient proof that you
are not a sufficiently competent software engineer as defined below:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and the ability to recognize infinite recursion at the x86 assembly language
level. No knowledge of the halting problem is required.
The second is that you have nominated yourself as a competent SE. NOT!!!
Clueless wonders always use ad hominem personal attacks as their basis
of rebuttal because that is all that they have.
On 6/22/2022 12:10 PM, olcott wrote:
On 6/22/2022 12:11 PM, Jeff Barnett wrote:
On 6/21/2022 8:38 PM, olcott wrote:
<SNIPPED GARBAGE UNRELATED TO MSG SUBJECT>
Peter, you must first identify a competent Software Engineer to do
said verification. There are two problems: The first is that no
competent SE would verify your claims whether or not you shared your
crap code with them. You don't certify a black box from the outside
because there are too many simple errors that wont be caught.
My words are perfectly clear and correct thus leaving the onlyYour words are not clear even to you. Are you really that stupid? Your
possible rebuttal of changing the words and forming a rebuttal on the
basis of these changed words.
not a Software Engineer, Computer Scientist, or a Programmer of even
modest skills. Sorry. Your accomplishments here on USENET or on the job
are of so trite a nature that no one of any accomplishments in these
areas can allow you pollute newsgroup after newsgroup with the same repetitive dribble. I think you have invented the "E" version of the
good old "cluster fuck". (That's one innovation you can put on your
resume.)
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
And that's the point. You are neither a competent Software Engineer nor
one who can judge competence. Remember all those employers who told you
the same thing.
After 100 reviewers in a dozen forums over a period of one year:
On 6/14/2022 6:47 AM, Paul N wrote:
Yes, it is clear to us humans watching
it that the program is repeating itself.
Thus we can appreciate that it will never
reach the final "ret" - indeed, it won't
even get to the infinite loop identified above.
If H can determine that this is the case in a finite number of steps
then H could correctly reject its input on this basis.
Let's give Paul N a little credit but not much; notice that he doesn't
even understand the point of the exercise which is that the *same
function* must be used for both inner and outer purposes.
On 6/22/2022 12:10 PM, olcott wrote:
On 6/22/2022 12:11 PM, Jeff Barnett wrote:
On 6/21/2022 8:38 PM, olcott wrote:
<SNIPPED GARBAGE UNRELATED TO MSG SUBJECT>
Peter, you must first identify a competent Software Engineer to do
said verification. There are two problems: The first is that no
competent SE would verify your claims whether or not you shared your
crap code with them. You don't certify a black box from the outside
because there are too many simple errors that wont be caught.
My words are perfectly clear and correct thus leaving the onlyYour words are not clear even to you. Are you really that stupid? Your
possible rebuttal of changing the words and forming a rebuttal on the
basis of these changed words.
not a Software Engineer, Computer Scientist, or a Programmer of even
modest skills. Sorry. Your accomplishments here on USENET or on the job
are of so trite a nature that no one of any accomplishments in these
areas can allow you pollute newsgroup after newsgroup with the same repetitive dribble. I think you have invented the "E" version of the
good old "cluster fuck". (That's one innovation you can put on your
resume.)
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
And that's the point. You are neither a competent Software Engineer nor
one who can judge competence. Remember all those employers who told you
the same thing.
After 100 reviewers in a dozen forums over a period of one year:
On 6/14/2022 6:47 AM, Paul N wrote:
Yes, it is clear to us humans watching
it that the program is repeating itself.
Thus we can appreciate that it will never
reach the final "ret" - indeed, it won't
even get to the infinite loop identified above.
If H can determine that this is the case in a finite number of steps
then H could correctly reject its input on this basis.
Let's give Paul N a little credit but not much; notice that he doesn't
even understand the point of the exercise which is that the *same
function* must be used for both inner and outer purposes.
Sufficiently competent software engineers will agree that if you
cannot verify that the above reasoning is valid forms sufficient proof
that you are not a sufficiently competent software engineer as defined
below:
Ass backwards as usual.
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly
language level. No knowledge of the halting problem is required.
That's really a shame for you since you have little knowledge or
competence in anything above. Strangely you need knowledge of the
halting problem to judge whether you have a legit counter example. So as
to what you "need knowledge of", you are once again ass backward.
The second is that you have nominated yourself as a competent SE. NOT!!!
Clueless wonders always use ad hominem personal attacks as their basis
of rebuttal because that is all that they have.
Mine isn't an ad hominem attack: It is based not only on my perception
of your nonsense but 100's of others pointing out glaring repetitive
errors. You on the other hand repeated nonsense, most of it off topic,
and then claim that someone else's competence is lacking.
Let's close by paraphrasing Schopenhauer to describe you Peter:
"Ignorance induces errors no one else could duplicate;
Ignorance + stupidity and ambition induce errors no one could foresee."
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:because H contains code to abort, and does abort, it does not do a complete emulation.
On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and lie about it:
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P) >>>>>> by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with. >>>>>> (b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer >>>>>> science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is >>>>>> actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it >>>>>> enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata. >>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly. >>>>> QED.
/Flibble
You and Richard are insufficiently technically competent at software
engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly
language level. No knowledge of the halting problem is required.
I cannot speak for Richard but I have 30+ years C++ experience; I also
have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
emulator in 80286 assembly) and I can recognize an infinite recursion;
the problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based
omnishambles:
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely recursive emulation.
H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And
So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
Otherwise you are incompetent.
the recursion simply isn't there for a "valid" halt
decider, that being a halt decider that can return an answer in finite
time to ALL invokers: H needs to return an answer to Px to be
considered a valid halt decider.
/Flibble
On 6/22/2022 4:49 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 16:41:43 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <NoOne@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily
verify that the complete and correct x86 emulation of the
input to H(P,P) by H would never reach the "ret" instruction
of P because both H and P would remain stuck in infinitely
recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis.
Here are the details of exactly how H does this in a finite
number of steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax //
push P [000010d9][00211e86][000010d2] 8b4d08 mov
ecx,[ebp+08] [000010dc][00211e82][000010d2] 51 push
ecx // push P [000010dd][00211e7e][000010e2] e820feffff
call 00000f02 // call H Infinitely Recursive Simulation
Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); //
64k; u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state,
slave_stack); Output("\nBegin Simulation Execution Trace
Stored at:", execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called
with. (b) No instructions in P could possibly escape this
otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is
invoked.
Technically competent software engineers may not know this
computer science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that
is actually specified by these inputs.
computation that halts … the Turing machine will halt whenever >>>>>> it enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and
Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided
correctly. QED.
/Flibble
You and Richard are insufficiently technically competent at
software engineering not meeting these specs:
A software engineer must be an expert in: the C programming
language, the x86 programming language, exactly how C translates
into x86 and the ability to recognize infinite recursion at the
x86 assembly language level. No knowledge of the halting problem
is required.
I cannot speak for Richard but I have 30+ years C++ experience; I
also have C and x86 assembly experience (I once wrote a Zilog Z80A
CPU emulator in 80286 assembly) and I can recognize an infinite
recursion; the problem is that you cannot recognize the fact that
the infinite recursion only manifests as part of your invalid
simulation-based omnishambles:
If you are competent then you already know this is true and lie
about it:
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to
H(Px,Px) by H would never reach the "ret" instruction of P because
both H and P would remain stuck in infinitely recursive emulation.
Otherwise you are incompetent.
the recursion simply isn't there for a "valid" halt
decider, that being a halt decider that can return an answer in
finite time to ALL invokers: H needs to return an answer to Px to
be considered a valid halt decider.
/Flibble
Why did you ignore the second part? Again:
The problem is that you cannot recognize the fact that the infinite recursion only manifests as part of your invalid simulation-based
It is easily provably correct. That you lack the technical competence
to verify that the x86 emulated behavior of the x86 emulation of the
input to H(P,P) by H precisely matches the behavior specified by P is
far less than no rebuttal at all.
I am not going to keep responding to your nonsense I don't really
give a rat's ass for the woefully incorrect opinion of incompetent
people.
omnishambles: the recursion simply isn't there for a "valid" halt
decider, that being a halt decider that can return an answer in
finite time to ALL invokers: H needs to return an answer to Px to be considered a valid halt decider.
On 6/22/2022 7:53 AM, olcott wrote:
On 6/22/2022 7:45 AM, Malcolm McLean wrote:
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
On 6/21/2022 9:52 PM, Richard Damon wrote:You've dry-run P(P) and it doesn't halt. Additionally the halt
Linz and others were aware that: A halt decider must compute the
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, >>>>>>> so H
was incorrect in its mapping, since the behavior of P(P) is the
DEFINITION of the behavior of H(P,P),
mapping
from its inputs to an accept or reject state on the basis of the
actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual behavior >>>>>> that
is actually specified by the inputs to a simulating halt decider
is not
the same as the direct execution of these inputs. They were
unaware of
this because no one previously fully examined a simulating halt
decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is
wrong.
decider H
reports it as non-halting. So it's reasonable to assume that H is
correct.
However, when run, P(P) halts. So what are we to conclude? That "the >>>>> actual behaviour that is actually specified by the inputs to a
simulating
halt decider is not the same as the direct execution of these inputs"? >>>> That is an actual immutable verified fact.
dry-run P(P), and it doesn't halt. You've run H on P(P), and it
reports "non-halting".
You've run P(P), and it halts.
So one explanation is the one you've given but, as I said, that
explanation has
rather far-reaching consequences. In these circumstances, the sensible
scientist (or I suppose mathematician, though I'm a scientist and not a
mathematician) looks for alternative explanations which aren't quite as
consequential.
That is like looking for alternatives to 5 > 3
5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
That would be one consequence of going with your explanation. We'dThat would have far-reaching consequences. Before going there, maybe >>>>> think up some simpler, alternative explanations and eliminate them.There are no alternatives to immutable verified facts. H(P,P) halts
only
because H(P,P) correctly determines that its input never halts.
Technically competent software engineers would agree. On the basis of
the much more complete details that I provided in my original post.
When P(P) is called from main its behavior depends on the return value >>>> of H. When H is called from main P(P) cannot possibly depend on the
return value of H because the correctly emulated input to H(P,P)
continues to remain stuck in infinite emulation until H aborts it.
have to
say the behaviour of P(P) differs depending on caller. As I said, try
simpler,
less far-reaching explanations first.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
H(P,P)==0 is provably correct
H1(P,P)==1 is provably correct.
H1(P,P) reports on the behavior of P(P).
A halt decider must compute the mapping from its inputs to an accept or reject state on the basis of the actual behavior that is actually
specified by these inputs. The actual behavior of the actual input to
H(P,P) is non halting thus rejecting its input is necessarily correct.
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:because H contains code to abort, and does abort, it does not do a complete emulation.
On 6/22/2022 4:53 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and lie about it: >>>> Every sufficiently competent software engineer can easily verify that
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify >>>>>>>> that the complete and correct x86 emulation of the input to H(P,P) >>>>>>>> by H would never reach the "ret" instruction of P because both H >>>>>>>> and P would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite >>>>>>>> number of steps then H could reject its input on this basis. Here >>>>>>>> are the details of exactly how H does this in a finite number of >>>>>>>> steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H >>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system >>>>>>>> u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack); >>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I)) >>>>>>>> goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily >>>>>>>> examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with. >>>>>>>> (b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked. >>>>>>>>
Technically competent software engineers may not know this computer >>>>>>>> science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is >>>>>>>> actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it >>>>>>>> enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata. >>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly. >>>>>>> QED.
/Flibble
You and Richard are insufficiently technically competent at software >>>>>> engineering not meeting these specs:
A software engineer must be an expert in: the C programming language, >>>>>> the x86 programming language, exactly how C translates into x86 and >>>>>> the ability to recognize infinite recursion at the x86 assembly
language level. No knowledge of the halting problem is required.
I cannot speak for Richard but I have 30+ years C++ experience; I also >>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
emulator in 80286 assembly) and I can recognize an infinite recursion; >>>>> the problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based
omnishambles:
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of P because both H and P would >>>> remain stuck in infinitely recursive emulation.
H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And
So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of Px because both H and Px
would remain stuck in infinitely recursive emulation.
So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
My words are perfectly clear and correct thus leaving the only possible rebuttal of changing the words and forming a rebuttal on the basis of
these changed words.
On 6/22/22 10:55 AM, olcott wrote:
On 6/22/2022 7:53 AM, olcott wrote:
On 6/22/2022 7:45 AM, Malcolm McLean wrote:
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:That is an actual immutable verified fact.
On 6/21/2022 9:52 PM, Richard Damon wrote:You've dry-run P(P) and it doesn't halt. Additionally the halt
Linz and others were aware that: A halt decider must compute the >>>>>>> mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, >>>>>>>> so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of the >>>>>>> actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual
behavior that
is actually specified by the inputs to a simulating halt decider >>>>>>> is not
the same as the direct execution of these inputs. They were
unaware of
this because no one previously fully examined a simulating halt
decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is >>>>>>>> wrong.
decider H
reports it as non-halting. So it's reasonable to assume that H is
correct.
However, when run, P(P) halts. So what are we to conclude? That "the >>>>>> actual behaviour that is actually specified by the inputs to a
simulating
halt decider is not the same as the direct execution of these
inputs"?
dry-run P(P), and it doesn't halt. You've run H on P(P), and it
reports "non-halting".
You've run P(P), and it halts.
So one explanation is the one you've given but, as I said, that
explanation has
rather far-reaching consequences. In these circumstances, the sensible >>>> scientist (or I suppose mathematician, though I'm a scientist and not a >>>> mathematician) looks for alternative explanations which aren't quite as >>>> consequential.
That is like looking for alternatives to 5 > 3
5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
That would be one consequence of going with your explanation. We'dThat would have far-reaching consequences. Before going there, maybe >>>>>> think up some simpler, alternative explanations and eliminate them. >>>>> There are no alternatives to immutable verified facts. H(P,P) haltsonly
because H(P,P) correctly determines that its input never halts.
Technically competent software engineers would agree. On the basis of >>>>> the much more complete details that I provided in my original post.
When P(P) is called from main its behavior depends on the return value >>>>> of H. When H is called from main P(P) cannot possibly depend on the
return value of H because the correctly emulated input to H(P,P)
continues to remain stuck in infinite emulation until H aborts it.
have to
say the behaviour of P(P) differs depending on caller. As I said,
try simpler,
less far-reaching explanations first.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
H(P,P)==0 is provably correct
H1(P,P)==1 is provably correct.
H1(P,P) reports on the behavior of P(P).
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs. The actual behavior of the actual input to
H(P,P) is non halting thus rejecting its input is necessarily correct.
You have this wrong.
A decider must compute the mapping that represents the FUNCTION it is deciding, there is actually nothing about "behavior" in the definition.
For a HALTING decider, that mapping is based on the HALTING Behavior of
the machine the input REPRESENTS.
On 6/22/22 1:58 PM, olcott wrote:
My words are perfectly clear and correct thus leaving the only
possible rebuttal of changing the words and forming a rebuttal on the
basis of these changed words.
No, they aren't because they don't match the definitons of the problem
you claim to be working on.
On Wed, 22 Jun 2022 16:58:24 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/22/2022 4:49 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 16:41:43 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <NoOne@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily
verify that the complete and correct x86 emulation of the
input to H(P,P) by H would never reach the "ret" instruction
of P because both H and P would remain stuck in infinitely
recursive emulation.
If H does correctly determine that this is the case in a finite >>>>>>>> number of steps then H could reject its input on this basis.
Here are the details of exactly how H does this in a finite
number of steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax //
push P [000010d9][00211e86][000010d2] 8b4d08 mov
ecx,[ebp+08] [000010dc][00211e82][000010d2] 51 push
ecx // push P [000010dd][00211e7e][000010e2] e820feffff >>>>>>>> call 00000f02 // call H Infinitely Recursive Simulation
Detected Simulation Stopped
// actual fully operational code in the x86utm operating system >>>>>>>> u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); //
64k; u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state,
slave_stack); Output("\nBegin Simulation Execution Trace
Stored at:", execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I)) >>>>>>>> goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily >>>>>>>> examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called
with. (b) No instructions in P could possibly escape this
otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is
invoked.
Technically competent software engineers may not know this
computer science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that >>>>>>>> is actually specified by these inputs.
computation that halts … the Turing machine will halt whenever >>>>>>>> it enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and
Automata. Lexington/Toronto: D. C. Heath and Company. (317-320) >>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided
correctly. QED.
/Flibble
You and Richard are insufficiently technically competent at
software engineering not meeting these specs:
A software engineer must be an expert in: the C programming
language, the x86 programming language, exactly how C translates
into x86 and the ability to recognize infinite recursion at the
x86 assembly language level. No knowledge of the halting problem
is required.
I cannot speak for Richard but I have 30+ years C++ experience; I
also have C and x86 assembly experience (I once wrote a Zilog Z80A
CPU emulator in 80286 assembly) and I can recognize an infinite
recursion; the problem is that you cannot recognize the fact that
the infinite recursion only manifests as part of your invalid
simulation-based omnishambles:
If you are competent then you already know this is true and lie
about it:
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to
H(Px,Px) by H would never reach the "ret" instruction of P because
both H and P would remain stuck in infinitely recursive emulation.
Otherwise you are incompetent.
the recursion simply isn't there for a "valid" halt
decider, that being a halt decider that can return an answer in
finite time to ALL invokers: H needs to return an answer to Px to
be considered a valid halt decider.
/Flibble
Why did you ignore the second part? Again:
The problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based
It is easily provably correct. That you lack the technical competence
to verify that the x86 emulated behavior of the x86 emulation of the
input to H(P,P) by H precisely matches the behavior specified by P is
far less than no rebuttal at all.
Your H doesn't return a value to its invoker, Px in this case, so isn't
a valid halt decider.
On 6/22/2022 6:05 PM, Richard Damon wrote:
On 6/22/22 10:55 AM, olcott wrote:
On 6/22/2022 7:53 AM, olcott wrote:
On 6/22/2022 7:45 AM, Malcolm McLean wrote:
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:That is an actual immutable verified fact.
On 6/21/2022 9:52 PM, Richard Damon wrote:You've dry-run P(P) and it doesn't halt. Additionally the halt
Linz and others were aware that: A halt decider must compute the >>>>>>>> mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns >>>>>>>>> 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of the >>>>>>>> actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual
behavior that
is actually specified by the inputs to a simulating halt decider >>>>>>>> is not
the same as the direct execution of these inputs. They were
unaware of
this because no one previously fully examined a simulating halt >>>>>>>> decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is >>>>>>>>> wrong.
decider H
reports it as non-halting. So it's reasonable to assume that H is >>>>>>> correct.
However, when run, P(P) halts. So what are we to conclude? That "the >>>>>>> actual behaviour that is actually specified by the inputs to a
simulating
halt decider is not the same as the direct execution of these
inputs"?
dry-run P(P), and it doesn't halt. You've run H on P(P), and it
reports "non-halting".
You've run P(P), and it halts.
So one explanation is the one you've given but, as I said, that
explanation has
rather far-reaching consequences. In these circumstances, the sensible >>>>> scientist (or I suppose mathematician, though I'm a scientist and
not a
mathematician) looks for alternative explanations which aren't
quite as
consequential.
That is like looking for alternatives to 5 > 3
5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
That would be one consequence of going with your explanation. We'dThat would have far-reaching consequences. Before going there, maybe >>>>>>> think up some simpler, alternative explanations and eliminate them. >>>>>> There are no alternatives to immutable verified facts. H(P,P)halts only
because H(P,P) correctly determines that its input never halts.
Technically competent software engineers would agree. On the basis of >>>>>> the much more complete details that I provided in my original post. >>>>>>
When P(P) is called from main its behavior depends on the return
value
of H. When H is called from main P(P) cannot possibly depend on the >>>>>> return value of H because the correctly emulated input to H(P,P)
continues to remain stuck in infinite emulation until H aborts it. >>>>>>
have to
say the behaviour of P(P) differs depending on caller. As I said,
try simpler,
less far-reaching explanations first.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
H(P,P)==0 is provably correct
H1(P,P)==1 is provably correct.
H1(P,P) reports on the behavior of P(P).
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs. The actual behavior of the actual input to
H(P,P) is non halting thus rejecting its input is necessarily correct.
You have this wrong.
A decider must compute the mapping that represents the FUNCTION it is
deciding, there is actually nothing about "behavior" in the definition.
For a HALTING decider, that mapping is based on the HALTING Behavior
of the machine the input REPRESENTS.
If you construe this as the actual behavior that the actual input
specifies then this is correct otherwise this is incorrect.
People that actually understand these things deeply on the basis of all
of the deep connected meanings will agree. People that understand these things only by the rote memorization of what textbooks say may get
confused.
This is computer science that I wrote that is verifiably correct and clarifies the misconceptions of what a halt decider must do:
A halt decider must compute the mapping from its inputs to an accept or reject state on the basis of the actual behavior that is actually
specified by these inputs. Copyright Olcott 2021
On 6/22/2022 6:11 PM, Richard Damon wrote:
On 6/22/22 1:58 PM, olcott wrote:
My words are perfectly clear and correct thus leaving the only
possible rebuttal of changing the words and forming a rebuttal on the
basis of these changed words.
No, they aren't because they don't match the definitons of the problem
you claim to be working on.
That is an entirely separate issue that cannot possibly be correctly addressed until after my words are totally agreed to in the precise
context that they are specified.
On 6/22/22 7:39 PM, olcott wrote:
On 6/22/2022 6:05 PM, Richard Damon wrote:
On 6/22/22 10:55 AM, olcott wrote:
On 6/22/2022 7:53 AM, olcott wrote:
On 6/22/2022 7:45 AM, Malcolm McLean wrote:
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've >>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:That is an actual immutable verified fact.
On 6/21/2022 9:52 PM, Richard Damon wrote:You've dry-run P(P) and it doesn't halt. Additionally the halt >>>>>>>> decider H
Linz and others were aware that: A halt decider must compute >>>>>>>>> the mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns >>>>>>>>>> 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of >>>>>>>>> the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual
behavior that
is actually specified by the inputs to a simulating halt
decider is not
the same as the direct execution of these inputs. They were
unaware of
this because no one previously fully examined a simulating halt >>>>>>>>> decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H >>>>>>>>>> is wrong.
reports it as non-halting. So it's reasonable to assume that H >>>>>>>> is correct.
However, when run, P(P) halts. So what are we to conclude? That >>>>>>>> "the
actual behaviour that is actually specified by the inputs to a >>>>>>>> simulating
halt decider is not the same as the direct execution of these
inputs"?
reports "non-halting".
You've run P(P), and it halts.
So one explanation is the one you've given but, as I said, that
explanation has
rather far-reaching consequences. In these circumstances, the
sensible
scientist (or I suppose mathematician, though I'm a scientist and
not a
mathematician) looks for alternative explanations which aren't
quite as
consequential.
That is like looking for alternatives to 5 > 3
5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
That would be one consequence of going with your explanation. We'd >>>>>> have toThat would have far-reaching consequences. Before going there, >>>>>>>> maybehalts only
think up some simpler, alternative explanations and eliminate them. >>>>>>> There are no alternatives to immutable verified facts. H(P,P)
because H(P,P) correctly determines that its input never halts.
Technically competent software engineers would agree. On the
basis of
the much more complete details that I provided in my original post. >>>>>>>
When P(P) is called from main its behavior depends on the return >>>>>>> value
of H. When H is called from main P(P) cannot possibly depend on the >>>>>>> return value of H because the correctly emulated input to H(P,P) >>>>>>> continues to remain stuck in infinite emulation until H aborts it. >>>>>>>
say the behaviour of P(P) differs depending on caller. As I said,
try simpler,
less far-reaching explanations first.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
H(P,P)==0 is provably correct
H1(P,P)==1 is provably correct.
H1(P,P) reports on the behavior of P(P).
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs. The actual behavior of the actual input
to H(P,P) is non halting thus rejecting its input is necessarily
correct.
You have this wrong.
A decider must compute the mapping that represents the FUNCTION it is
deciding, there is actually nothing about "behavior" in the definition.
For a HALTING decider, that mapping is based on the HALTING Behavior
of the machine the input REPRESENTS.
If you construe this as the actual behavior that the actual input
specifies then this is correct otherwise this is incorrect.
If it isn't the acutual behavior, then it just isn't a Halt Decider, but maybe your POOP decider.
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <NoOne@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here are
the details of exactly how H does this in a finite number of steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P); >>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) >>> * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and the ability to recognize infinite recursion at the x86 assembly language
level. No knowledge of the halting problem is required.
On 6/22/22 8:00 PM, olcott wrote:
On 6/22/2022 6:11 PM, Richard Damon wrote:
On 6/22/22 1:58 PM, olcott wrote:
My words are perfectly clear and correct thus leaving the only
possible rebuttal of changing the words and forming a rebuttal on
the basis of these changed words.
No, they aren't because they don't match the definitons of the
problem you claim to be working on.
That is an entirely separate issue that cannot possibly be correctly
addressed until after my words are totally agreed to in the precise
context that they are specified.
If you start with the wrong definitions, why do people need (or even
want to) agree with them.
On 6/22/22 4:27 PM, olcott wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <NoOne@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here are
the details of exactly how H does this in a finite number of steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P); >>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) >>>> * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax >>> ...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software
engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly
language level. No knowledge of the halting problem is required.
Except that I am probably at least as much of an expert on those fields
as you are. My one problem is that I do have knowledge of the halting problem, that seems to make me resistant to your lies.
You might have more experiance with x86, but only because I work on a
number of different architectures, but your argument really isn't x86 specific, that is just the case you are working in.
(I was producing 'production' assembly routines 50 years ago, so I have
seen a number of different types of machines)
On 6/22/2022 7:32 PM, Richard Damon wrote:
On 6/22/22 4:27 PM, olcott wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <NoOne@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify that >>>>> the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here are >>>>> the details of exactly how H does this in a finite number of steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language >>>>> ======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H >>>>> Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P); >>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) >>>>> * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack); >>>>> Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an accept >>>>> or reject state on the basis of the actual behavior that is actually >>>>> specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>> ...[000013eb][00102353][00000000] 50 push eax >>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>> ...[000013fb][0010235b][00100000] 5d pop ebp >>>> ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software
engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly
language level. No knowledge of the halting problem is required.
Except that I am probably at least as much of an expert on those
fields as you are. My one problem is that I do have knowledge of the
halting problem, that seems to make me resistant to your lies.
You might have more experiance with x86, but only because I work on a
number of different architectures, but your argument really isn't x86
specific, that is just the case you are working in.
(I was producing 'production' assembly routines 50 years ago, so I
have seen a number of different types of machines)
First you agree that my words are perfectly correct within their
specified context
The software engineering aspect of this original post
On 6/21/2022 9:38 PM, olcott wrote:
then after this we can proceed with your objection that they do not meet
the definitions.
It is required that we have incremental closure on sub-points or full
closure will be impossible to achieve.
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the context of software engineering totally ignoring the context of the halting problem.
First you agree that my words are perfectly correct within their
specified context
Since you haven't actualy defined you context, and imply that it is the halting problem, where they can not be correct, that is not possible.
On 6/22/2022 7:25 PM, Richard Damon wrote:
On 6/22/22 8:00 PM, olcott wrote:
On 6/22/2022 6:11 PM, Richard Damon wrote:
On 6/22/22 1:58 PM, olcott wrote:
My words are perfectly clear and correct thus leaving the only
possible rebuttal of changing the words and forming a rebuttal on
the basis of these changed words.
No, they aren't because they don't match the definitons of the
problem you claim to be working on.
That is an entirely separate issue that cannot possibly be correctly
addressed until after my words are totally agreed to in the precise
context that they are specified.
If you start with the wrong definitions, why do people need (or even
want to) agree with them.
First you agree that my words are perfectly correct within their
specified context then after this we can proceed with your objection
that they do not meet the definitions.
It is required that we have incremental closure on sub-points or full
closure will be impossible to achieve.
On 6/22/2022 7:22 PM, Richard Damon wrote:
On 6/22/22 7:39 PM, olcott wrote:The behavior of P(P) is provably not the actual behavior of the actual
On 6/22/2022 6:05 PM, Richard Damon wrote:
On 6/22/22 10:55 AM, olcott wrote:
On 6/22/2022 7:53 AM, olcott wrote:
On 6/22/2022 7:45 AM, Malcolm McLean wrote:
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've >>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:That is an actual immutable verified fact.
You've dry-run P(P) and it doesn't halt. Additionally the halt >>>>>>>>> decider HLinz and others were aware that: A halt decider must compute >>>>>>>>>> the mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns >>>>>>>>>>> 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of >>>>>>>>>> the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual
behavior that
is actually specified by the inputs to a simulating halt
decider is not
the same as the direct execution of these inputs. They were >>>>>>>>>> unaware of
this because no one previously fully examined a simulating >>>>>>>>>> halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H >>>>>>>>>>> is wrong.
reports it as non-halting. So it's reasonable to assume that H >>>>>>>>> is correct.
However, when run, P(P) halts. So what are we to conclude? That >>>>>>>>> "the
actual behaviour that is actually specified by the inputs to a >>>>>>>>> simulating
halt decider is not the same as the direct execution of these >>>>>>>>> inputs"?
reports "non-halting".
You've run P(P), and it halts.
So one explanation is the one you've given but, as I said, that
explanation has
rather far-reaching consequences. In these circumstances, the
sensible
scientist (or I suppose mathematician, though I'm a scientist and >>>>>>> not a
mathematician) looks for alternative explanations which aren't
quite as
consequential.
That is like looking for alternatives to 5 > 3
5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
That would be one consequence of going with your explanation.That would have far-reaching consequences. Before going there, >>>>>>>>> maybeThere are no alternatives to immutable verified facts. H(P,P)
think up some simpler, alternative explanations and eliminate >>>>>>>>> them.
halts only
because H(P,P) correctly determines that its input never halts. >>>>>>>>
Technically competent software engineers would agree. On the
basis of
the much more complete details that I provided in my original post. >>>>>>>>
When P(P) is called from main its behavior depends on the return >>>>>>>> value
of H. When H is called from main P(P) cannot possibly depend on the >>>>>>>> return value of H because the correctly emulated input to H(P,P) >>>>>>>> continues to remain stuck in infinite emulation until H aborts it. >>>>>>>>
We'd have to
say the behaviour of P(P) differs depending on caller. As I said, >>>>>>> try simpler,
less far-reaching explanations first.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
H(P,P)==0 is provably correct
H1(P,P)==1 is provably correct.
H1(P,P) reports on the behavior of P(P).
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs. The actual behavior of the
actual input to H(P,P) is non halting thus rejecting its input is
necessarily correct.
You have this wrong.
A decider must compute the mapping that represents the FUNCTION it
is deciding, there is actually nothing about "behavior" in the
definition.
For a HALTING decider, that mapping is based on the HALTING Behavior
of the machine the input REPRESENTS.
If you construe this as the actual behavior that the actual input
specifies then this is correct otherwise this is incorrect.
If it isn't the acutual behavior, then it just isn't a Halt Decider,
but maybe your POOP decider.
input to H(P,P). That you are insufficiently technically competent to
verify this is far less than no rebuttal at all.
On 6/22/22 8:30 PM, olcott wrote:
On 6/22/2022 7:22 PM, Richard Damon wrote:
On 6/22/22 7:39 PM, olcott wrote:The behavior of P(P) is provably not the actual behavior of the actual
On 6/22/2022 6:05 PM, Richard Damon wrote:
On 6/22/22 10:55 AM, olcott wrote:
On 6/22/2022 7:53 AM, olcott wrote:
On 6/22/2022 7:45 AM, Malcolm McLean wrote:
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've >>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>> reports "non-halting".
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:That is an actual immutable verified fact.
You've dry-run P(P) and it doesn't halt. Additionally the halt >>>>>>>>>> decider HLinz and others were aware that: A halt decider must compute >>>>>>>>>>> the mapping
Right, and P(P) reaches the ret instruction of H(P,P)
returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of >>>>>>>>>>> the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual >>>>>>>>>>> behavior that
is actually specified by the inputs to a simulating halt >>>>>>>>>>> decider is not
the same as the direct execution of these inputs. They were >>>>>>>>>>> unaware of
this because no one previously fully examined a simulating >>>>>>>>>>> halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H >>>>>>>>>>>> is wrong.
reports it as non-halting. So it's reasonable to assume that H >>>>>>>>>> is correct.
However, when run, P(P) halts. So what are we to conclude? >>>>>>>>>> That "the
actual behaviour that is actually specified by the inputs to a >>>>>>>>>> simulating
halt decider is not the same as the direct execution of these >>>>>>>>>> inputs"?
You've run P(P), and it halts.
So one explanation is the one you've given but, as I said, that >>>>>>>> explanation has
rather far-reaching consequences. In these circumstances, the
sensible
scientist (or I suppose mathematician, though I'm a scientist
and not a
mathematician) looks for alternative explanations which aren't >>>>>>>> quite as
consequential.
That is like looking for alternatives to 5 > 3
5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
That would be one consequence of going with your explanation.That would have far-reaching consequences. Before going there, >>>>>>>>>> maybeThere are no alternatives to immutable verified facts. H(P,P) >>>>>>>>> halts only
think up some simpler, alternative explanations and eliminate >>>>>>>>>> them.
because H(P,P) correctly determines that its input never halts. >>>>>>>>>
Technically competent software engineers would agree. On the >>>>>>>>> basis of
the much more complete details that I provided in my original >>>>>>>>> post.
When P(P) is called from main its behavior depends on the
return value
of H. When H is called from main P(P) cannot possibly depend on >>>>>>>>> the
return value of H because the correctly emulated input to H(P,P) >>>>>>>>> continues to remain stuck in infinite emulation until H aborts it. >>>>>>>>>
We'd have to
say the behaviour of P(P) differs depending on caller. As I
said, try simpler,
less far-reaching explanations first.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
H(P,P)==0 is provably correct
H1(P,P)==1 is provably correct.
H1(P,P) reports on the behavior of P(P).
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is >>>>>> actually specified by these inputs. The actual behavior of the
actual input to H(P,P) is non halting thus rejecting its input is
necessarily correct.
You have this wrong.
A decider must compute the mapping that represents the FUNCTION it
is deciding, there is actually nothing about "behavior" in the
definition.
For a HALTING decider, that mapping is based on the HALTING
Behavior of the machine the input REPRESENTS.
If you construe this as the actual behavior that the actual input
specifies then this is correct otherwise this is incorrect.
If it isn't the acutual behavior, then it just isn't a Halt Decider,
but maybe your POOP decider.
input to H(P,P). That you are insufficiently technically competent to
verify this is far less than no rebuttal at all.
THen prove it.
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:
First you agree that these words are 100% correct within the context of software engineering totally ignoring the context of the halting problem.First you agree that my words are perfectly correct within their
specified context
Since you haven't actualy defined you context, and imply that it is
the halting problem, where they can not be correct, that is not possible. >>>
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H would never reach the "ret" instruction of P because both H and P would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite number
of steps then H could reject its input on this basis. Here are the
details of exactly how H does this in a finite number of steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [000010d2][00211e8a][00211e8e] 55 push ebp [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] [000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] [000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*) Allocate(sizeof(Registers));
Registers* slave_state = (Registers*) Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:", execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
&slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily examine
its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:because H contains code to abort, and does abort, it does not do a complete emulation.
On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
On 6/22/2022 4:53 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and lie about it:
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:I cannot speak for Richard but I have 30+ years C++ experience; I also >>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU >>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion; >>>>>>> the problem is that you cannot recognize the fact that the infinite >>>>>>> recursion only manifests as part of your invalid simulation-based >>>>>>> omnishambles:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify >>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P) >>>>>>>>>> by H would never reach the "ret" instruction of P because both H >>>>>>>>>> and P would remain stuck in infinitely recursive emulation. >>>>>>>>>>
If H does correctly determine that this is the case in a finite >>>>>>>>>> number of steps then H could reject its input on this basis. Here >>>>>>>>>> are the details of exactly how H does this in a finite number of >>>>>>>>>> steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H >>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>
// actual fully operational code in the x86utm operating system >>>>>>>>>> u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack); >>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I)) >>>>>>>>>> goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily >>>>>>>>>> examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with. >>>>>>>>>> (b) No instructions in P could possibly escape this otherwise >>>>>>>>>> infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked. >>>>>>>>>>
Technically competent software engineers may not know this computer >>>>>>>>>> science:
A halt decider must compute the mapping from its inputs to an >>>>>>>>>> accept or reject state on the basis of the actual behavior that is >>>>>>>>>> actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it >>>>>>>>>> enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata. >>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly. >>>>>>>>> QED.
/Flibble
You and Richard are insufficiently technically competent at software >>>>>>>> engineering not meeting these specs:
A software engineer must be an expert in: the C programming language, >>>>>>>> the x86 programming language, exactly how C translates into x86 and >>>>>>>> the ability to recognize infinite recursion at the x86 assembly >>>>>>>> language level. No knowledge of the halting problem is required. >>>>>>>
Every sufficiently competent software engineer can easily verify that >>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H >>>>>> would never reach the "ret" instruction of P because both H and P would >>>>>> remain stuck in infinitely recursive emulation.
H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And
Your entire basis and all of assumptions was incorrect so when I
So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of Px because both H and Px
would remain stuck in infinitely recursive emulation.
So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
provided an infallible one to that cannot possibly be correctly refuted
you simply dodged it. That is a smart move for a dishonest person that
is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my
airtight correct reasoning. Another dodge will be construed as a tacit
admission of defeat.
As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
On 6/22/2022 7:56 PM, Richard Damon wrote:
On 6/22/22 8:30 PM, olcott wrote:
On 6/22/2022 7:22 PM, Richard Damon wrote:
On 6/22/22 7:39 PM, olcott wrote:The behavior of P(P) is provably not the actual behavior of the
On 6/22/2022 6:05 PM, Richard Damon wrote:
On 6/22/22 10:55 AM, olcott wrote:
On 6/22/2022 7:53 AM, olcott wrote:
On 6/22/2022 7:45 AM, Malcolm McLean wrote:
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
That's your conclusion from your observations and reasoning. >>>>>>>>> You'veOn Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:That is an actual immutable verified fact.
You've dry-run P(P) and it doesn't halt. Additionally the >>>>>>>>>>> halt decider HLinz and others were aware that: A halt decider must compute >>>>>>>>>>>> the mapping
Right, and P(P) reaches the ret instruction of H(P,P) >>>>>>>>>>>>> returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is >>>>>>>>>>>>> the
DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of >>>>>>>>>>>> the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual >>>>>>>>>>>> behavior that
is actually specified by the inputs to a simulating halt >>>>>>>>>>>> decider is not
the same as the direct execution of these inputs. They were >>>>>>>>>>>> unaware of
this because no one previously fully examined a simulating >>>>>>>>>>>> halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or >>>>>>>>>>>>> H is wrong.
reports it as non-halting. So it's reasonable to assume that >>>>>>>>>>> H is correct.
However, when run, P(P) halts. So what are we to conclude? >>>>>>>>>>> That "the
actual behaviour that is actually specified by the inputs to >>>>>>>>>>> a simulating
halt decider is not the same as the direct execution of these >>>>>>>>>>> inputs"?
dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>>> reports "non-halting".
You've run P(P), and it halts.
So one explanation is the one you've given but, as I said, that >>>>>>>>> explanation has
rather far-reaching consequences. In these circumstances, the >>>>>>>>> sensible
scientist (or I suppose mathematician, though I'm a scientist >>>>>>>>> and not a
mathematician) looks for alternative explanations which aren't >>>>>>>>> quite as
consequential.
That is like looking for alternatives to 5 > 3
5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
That would be one consequence of going with your explanation. >>>>>>>>> We'd have toThat would have far-reaching consequences. Before goingThere are no alternatives to immutable verified facts. H(P,P) >>>>>>>>>> halts only
there, maybe
think up some simpler, alternative explanations and eliminate >>>>>>>>>>> them.
because H(P,P) correctly determines that its input never halts. >>>>>>>>>>
Technically competent software engineers would agree. On the >>>>>>>>>> basis of
the much more complete details that I provided in my original >>>>>>>>>> post.
When P(P) is called from main its behavior depends on the
return value
of H. When H is called from main P(P) cannot possibly depend >>>>>>>>>> on the
return value of H because the correctly emulated input to H(P,P) >>>>>>>>>> continues to remain stuck in infinite emulation until H aborts >>>>>>>>>> it.
say the behaviour of P(P) differs depending on caller. As I
said, try simpler,
less far-reaching explanations first.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
H(P,P)==0 is provably correct
H1(P,P)==1 is provably correct.
H1(P,P) reports on the behavior of P(P).
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that
is actually specified by these inputs. The actual behavior of the >>>>>>> actual input to H(P,P) is non halting thus rejecting its input is >>>>>>> necessarily correct.
You have this wrong.
A decider must compute the mapping that represents the FUNCTION it >>>>>> is deciding, there is actually nothing about "behavior" in the
definition.
For a HALTING decider, that mapping is based on the HALTING
Behavior of the machine the input REPRESENTS.
If you construe this as the actual behavior that the actual input
specifies then this is correct otherwise this is incorrect.
If it isn't the acutual behavior, then it just isn't a Halt Decider,
but maybe your POOP decider.
actual input to H(P,P). That you are insufficiently technically
competent to verify this is far less than no rebuttal at all.
THen prove it.
I have proved it dozens of times and every fake "rebuttal" simply
ignores the proof.
On 6/22/22 8:55 PM, olcott wrote:
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the context
First you agree that my words are perfectly correct within their
specified context
Since you haven't actualy defined you context, and imply that it is
the halting problem, where they can not be correct, that is not
possible.
of software engineering totally ignoring the context of the halting
problem.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
So, if H actually is a program that does a COMPLETE and correct x86
emulation of its input, then YES, as I have said many time before, this combination is non-halting.
The fact that you need to keep going back to this, and seem to just be refusing to accept the conditions under which you have proved it just
shows the problems with your thought process.
If H does correctly determine that this is the case in a finite number
of steps then H could reject its input on this basis. Here are the
details of exactly how H does this in a finite number of steps.
Except that NOW H isn't the H we were just talking about, so you are
just proving that you are either lying or an idiot.
Remember, the first analysis had the CONDITION on it that H did a
COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long holds and
you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k; >> u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state,
&slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
(b) is NOT a correct rule. Thos has been pointed out before, and you
have ignored it.
On 6/22/22 9:03 PM, olcott wrote:
On 6/22/2022 7:56 PM, Richard Damon wrote:
On 6/22/22 8:30 PM, olcott wrote:
On 6/22/2022 7:22 PM, Richard Damon wrote:
On 6/22/22 7:39 PM, olcott wrote:The behavior of P(P) is provably not the actual behavior of the
On 6/22/2022 6:05 PM, Richard Damon wrote:
On 6/22/22 10:55 AM, olcott wrote:
On 6/22/2022 7:53 AM, olcott wrote:
On 6/22/2022 7:45 AM, Malcolm McLean wrote:
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
That's your conclusion from your observations and reasoning. >>>>>>>>>> You'veOn Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:That is an actual immutable verified fact.
You've dry-run P(P) and it doesn't halt. Additionally the >>>>>>>>>>>> halt decider HLinz and others were aware that: A halt decider must >>>>>>>>>>>>> compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) >>>>>>>>>>>>>> returns 0, so H
was incorrect in its mapping, since the behavior of P(P) >>>>>>>>>>>>>> is the
DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis >>>>>>>>>>>>> of the actual
behavior that is actually specified by these inputs. >>>>>>>>>>>>> Linz and others made the false assumption that the actual >>>>>>>>>>>>> behavior that
is actually specified by the inputs to a simulating halt >>>>>>>>>>>>> decider is not
the same as the direct execution of these inputs. They were >>>>>>>>>>>>> unaware of
this because no one previously fully examined a simulating >>>>>>>>>>>>> halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template. >>>>>>>>>>>>>>
So, either P isn't built right, or H isn't built fight, or >>>>>>>>>>>>>> H is wrong.
reports it as non-halting. So it's reasonable to assume that >>>>>>>>>>>> H is correct.
However, when run, P(P) halts. So what are we to conclude? >>>>>>>>>>>> That "the
actual behaviour that is actually specified by the inputs to >>>>>>>>>>>> a simulating
halt decider is not the same as the direct execution of >>>>>>>>>>>> these inputs"?
dry-run P(P), and it doesn't halt. You've run H on P(P), and >>>>>>>>>> it reports "non-halting".
You've run P(P), and it halts.
So one explanation is the one you've given but, as I said, >>>>>>>>>> that explanation has
rather far-reaching consequences. In these circumstances, the >>>>>>>>>> sensible
scientist (or I suppose mathematician, though I'm a scientist >>>>>>>>>> and not a
mathematician) looks for alternative explanations which aren't >>>>>>>>>> quite as
consequential.
That is like looking for alternatives to 5 > 3
5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
That would be one consequence of going with your explanation. >>>>>>>>>> We'd have toThat would have far-reaching consequences. Before going >>>>>>>>>>>> there, maybeThere are no alternatives to immutable verified facts. H(P,P) >>>>>>>>>>> halts only
think up some simpler, alternative explanations and
eliminate them.
because H(P,P) correctly determines that its input never halts. >>>>>>>>>>>
Technically competent software engineers would agree. On the >>>>>>>>>>> basis of
the much more complete details that I provided in my original >>>>>>>>>>> post.
When P(P) is called from main its behavior depends on the >>>>>>>>>>> return value
of H. When H is called from main P(P) cannot possibly depend >>>>>>>>>>> on the
return value of H because the correctly emulated input to H(P,P) >>>>>>>>>>> continues to remain stuck in infinite emulation until H
aborts it.
say the behaviour of P(P) differs depending on caller. As I >>>>>>>>>> said, try simpler,
less far-reaching explanations first.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
H(P,P)==0 is provably correct
H1(P,P)==1 is provably correct.
H1(P,P) reports on the behavior of P(P).
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that >>>>>>>> is actually specified by these inputs. The actual behavior of
the actual input to H(P,P) is non halting thus rejecting its
input is necessarily correct.
You have this wrong.
A decider must compute the mapping that represents the FUNCTION
it is deciding, there is actually nothing about "behavior" in the >>>>>>> definition.
For a HALTING decider, that mapping is based on the HALTING
Behavior of the machine the input REPRESENTS.
If you construe this as the actual behavior that the actual input
specifies then this is correct otherwise this is incorrect.
If it isn't the acutual behavior, then it just isn't a Halt
Decider, but maybe your POOP decider.
actual input to H(P,P). That you are insufficiently technically
competent to verify this is far less than no rebuttal at all.
THen prove it.
I have proved it dozens of times and every fake "rebuttal" simply
ignores the proof.
Nope, you have claimed it, and given rhetorical arguments.
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it is an
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the context
First you agree that my words are perfectly correct within their
specified context
Since you haven't actualy defined you context, and imply that it is
the halting problem, where they can not be correct, that is not
possible.
of software engineering totally ignoring the context of the halting
problem.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
So, if H actually is a program that does a COMPLETE and correct x86
emulation of its input, then YES, as I have said many time before,
this combination is non-halting.
The fact that you need to keep going back to this, and seem to just be
refusing to accept the conditions under which you have proved it just
shows the problems with your thought process.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here are
the details of exactly how H does this in a finite number of steps.
Except that NOW H isn't the H we were just talking about, so you are
just proving that you are either lying or an idiot.
Remember, the first analysis had the CONDITION on it that H did a
COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long holds
and you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state,
&slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
(b) is NOT a correct rule. Thos has been pointed out before, and you
have ignored it.
incorrect rule.
Here is an example where P does have instruction that could possibly
escape this otherwise infinitely recursive emulation:
void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:because H contains code to abort, and does abort, it does not do a complete emulation.
On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
On 6/22/2022 4:53 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and lie about it:
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:I cannot speak for Richard but I have 30+ years C++ experience; I also
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify >>>>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P) >>>>>>>>>>>> by H would never reach the "ret" instruction of P because both H >>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation. >>>>>>>>>>>>
If H does correctly determine that this is the case in a finite >>>>>>>>>>>> number of steps then H could reject its input on this basis. Here >>>>>>>>>>>> are the details of exactly how H does this in a finite number of >>>>>>>>>>>> steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H >>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>>
// actual fully operational code in the x86utm operating system >>>>>>>>>>>> u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack); >>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I)) >>>>>>>>>>>> goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily >>>>>>>>>>>> examine its stored execution_trace of P and determine: >>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with. >>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise >>>>>>>>>>>> infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked. >>>>>>>>>>>>
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an >>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is >>>>>>>>>>>> actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427 >>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476 >>>>>>>>>>> Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software >>>>>>>>>> engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and >>>>>>>>>> the ability to recognize infinite recursion at the x86 assembly >>>>>>>>>> language level. No knowledge of the halting problem is required. >>>>>>>>>
have C and x86 assembly experience (I once wrote a Zilog Z80A CPU >>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
the problem is that you cannot recognize the fact that the infinite >>>>>>>>> recursion only manifests as part of your invalid simulation-based >>>>>>>>> omnishambles:
Every sufficiently competent software engineer can easily verify that >>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H >>>>>>>> would never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely recursive emulation.
H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And
I never claimed that H(P,P) performs a complete and correct emulation ofYour entire basis and all of assumptions was incorrect so when I
So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
Every sufficiently competent software engineer can easily verify that >>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H >>>>>> would never reach the "ret" instruction of Px because both H and Px >>>>>> would remain stuck in infinitely recursive emulation.
So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
provided an infallible one to that cannot possibly be correctly refuted >>>> you simply dodged it. That is a smart move for a dishonest person that >>>> is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my
airtight correct reasoning. Another dodge will be construed as a tacit >>>> admission of defeat.
As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
its input so your rebuttal is the strawman deception.
I claimed that H(P,P) correctly predicts that its complete and correct
x86 emulation of its input would never reach the "ret" instruction of P.
But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
On 6/22/22 9:29 PM, olcott wrote:
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it is an
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the context
First you agree that my words are perfectly correct within their
specified context
Since you haven't actualy defined you context, and imply that it is
the halting problem, where they can not be correct, that is not
possible.
of software engineering totally ignoring the context of the halting
problem.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P)
by H would never reach the "ret" instruction of P because both H and
P would remain stuck in infinitely recursive emulation.
So, if H actually is a program that does a COMPLETE and correct x86
emulation of its input, then YES, as I have said many time before,
this combination is non-halting.
The fact that you need to keep going back to this, and seem to just
be refusing to accept the conditions under which you have proved it
just shows the problems with your thought process.
If H does correctly determine that this is the case in a finiteExcept that NOW H isn't the H we were just talking about, so you are
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of steps. >>>
just proving that you are either lying or an idiot.
Remember, the first analysis had the CONDITION on it that H did a
COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long holds
and you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P); >>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) >>>> * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state,
&slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
(b) is NOT a correct rule. Thos has been pointed out before, and you
have ignored it.
incorrect rule.
Here is an example where P does have instruction that could possibly
escape this otherwise infinitely recursive emulation:
void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}
FALLACY of proof by example. I never said that (b) isn't sometimes true,
just it isn't an always true condition. You fail at elementary logic.
On 6/22/2022 8:36 PM, Richard Damon wrote:
On 6/22/22 9:29 PM, olcott wrote:
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it is an
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the
First you agree that my words are perfectly correct within their >>>>>>> specified context
Since you haven't actualy defined you context, and imply that it
is the halting problem, where they can not be correct, that is not >>>>>> possible.
context of software engineering totally ignoring the context of the
halting problem.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P)
by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely recursive emulation.
So, if H actually is a program that does a COMPLETE and correct x86
emulation of its input, then YES, as I have said many time before,
this combination is non-halting.
The fact that you need to keep going back to this, and seem to just
be refusing to accept the conditions under which you have proved it
just shows the problems with your thought process.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
Except that NOW H isn't the H we were just talking about, so you are
just proving that you are either lying or an idiot.
Remember, the first analysis had the CONDITION on it that H did a
COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long holds
and you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language >>>>> ======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H >>>>> Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P); >>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state,
&slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
(b) is NOT a correct rule. Thos has been pointed out before, and you
have ignored it.
incorrect rule.
Here is an example where P does have instruction that could possibly
escape this otherwise infinitely recursive emulation:
void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}
FALLACY of proof by example. I never said that (b) isn't sometimes
true, just it isn't an always true condition. You fail at elementary
logic.
Try and find a valid counter-example. Every attempt at rebuttal that is
not a valid counter-example is one form of deception or another.
On 6/22/2022 8:19 PM, Richard Damon wrote:
On 6/22/22 9:03 PM, olcott wrote:
On 6/22/2022 7:56 PM, Richard Damon wrote:
On 6/22/22 8:30 PM, olcott wrote:
On 6/22/2022 7:22 PM, Richard Damon wrote:
On 6/22/22 7:39 PM, olcott wrote:The behavior of P(P) is provably not the actual behavior of the
On 6/22/2022 6:05 PM, Richard Damon wrote:
On 6/22/22 10:55 AM, olcott wrote:
On 6/22/2022 7:53 AM, olcott wrote:
On 6/22/2022 7:45 AM, Malcolm McLean wrote:
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
That's your conclusion from your observations and reasoning. >>>>>>>>>>> You'veOn Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:That is an actual immutable verified fact.
You've dry-run P(P) and it doesn't halt. Additionally the >>>>>>>>>>>>> halt decider HLinz and others were aware that: A halt decider must >>>>>>>>>>>>>> compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) >>>>>>>>>>>>>>> returns 0, so H
was incorrect in its mapping, since the behavior of P(P) >>>>>>>>>>>>>>> is the
DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis >>>>>>>>>>>>>> of the actual
behavior that is actually specified by these inputs. >>>>>>>>>>>>>> Linz and others made the false assumption that the actual >>>>>>>>>>>>>> behavior that
is actually specified by the inputs to a simulating halt >>>>>>>>>>>>>> decider is not
the same as the direct execution of these inputs. They >>>>>>>>>>>>>> were unaware of
this because no one previously fully examined a simulating >>>>>>>>>>>>>> halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template. >>>>>>>>>>>>>>>
So, either P isn't built right, or H isn't built fight, >>>>>>>>>>>>>>> or H is wrong.
reports it as non-halting. So it's reasonable to assume >>>>>>>>>>>>> that H is correct.
However, when run, P(P) halts. So what are we to conclude? >>>>>>>>>>>>> That "the
actual behaviour that is actually specified by the inputs >>>>>>>>>>>>> to a simulating
halt decider is not the same as the direct execution of >>>>>>>>>>>>> these inputs"?
dry-run P(P), and it doesn't halt. You've run H on P(P), and >>>>>>>>>>> it reports "non-halting".
You've run P(P), and it halts.
So one explanation is the one you've given but, as I said, >>>>>>>>>>> that explanation has
rather far-reaching consequences. In these circumstances, the >>>>>>>>>>> sensible
scientist (or I suppose mathematician, though I'm a scientist >>>>>>>>>>> and not a
mathematician) looks for alternative explanations which
aren't quite as
consequential.
That is like looking for alternatives to 5 > 3
5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
That would be one consequence of going with your explanation. >>>>>>>>>>> We'd have toThat would have far-reaching consequences. Before going >>>>>>>>>>>>> there, maybeThere are no alternatives to immutable verified facts. >>>>>>>>>>>> H(P,P) halts only
think up some simpler, alternative explanations and
eliminate them.
because H(P,P) correctly determines that its input never halts. >>>>>>>>>>>>
Technically competent software engineers would agree. On the >>>>>>>>>>>> basis of
the much more complete details that I provided in my
original post.
When P(P) is called from main its behavior depends on the >>>>>>>>>>>> return value
of H. When H is called from main P(P) cannot possibly depend >>>>>>>>>>>> on the
return value of H because the correctly emulated input to >>>>>>>>>>>> H(P,P)
continues to remain stuck in infinite emulation until H >>>>>>>>>>>> aborts it.
say the behaviour of P(P) differs depending on caller. As I >>>>>>>>>>> said, try simpler,
less far-reaching explanations first.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
H(P,P)==0 is provably correct
H1(P,P)==1 is provably correct.
H1(P,P) reports on the behavior of P(P).
A halt decider must compute the mapping from its inputs to an >>>>>>>>> accept or reject state on the basis of the actual behavior that >>>>>>>>> is actually specified by these inputs. The actual behavior of >>>>>>>>> the actual input to H(P,P) is non halting thus rejecting its >>>>>>>>> input is necessarily correct.
You have this wrong.
A decider must compute the mapping that represents the FUNCTION >>>>>>>> it is deciding, there is actually nothing about "behavior" in
the definition.
For a HALTING decider, that mapping is based on the HALTING
Behavior of the machine the input REPRESENTS.
If you construe this as the actual behavior that the actual input >>>>>>> specifies then this is correct otherwise this is incorrect.
If it isn't the acutual behavior, then it just isn't a Halt
Decider, but maybe your POOP decider.
actual input to H(P,P). That you are insufficiently technically
competent to verify this is far less than no rebuttal at all.
THen prove it.
I have proved it dozens of times and every fake "rebuttal" simply
ignores the proof.
Nope, you have claimed it, and given rhetorical arguments.
I have provided a complete provably correct execution traces of H(P,P)
and P(P) that conclusively proves that they really do have different
behavior yet people rejected it on the basis that they simply do not
"believe in" the x86 language. This is why I aptly called them
despicable liars.
On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:I never claimed that H(P,P) performs a complete and correct emulation of >>> its input so your rebuttal is the strawman deception.
On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:Your entire basis and all of assumptions was incorrect so when I
On 6/22/2022 4:53 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote: >>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and lie >>>>>>>>> about it:
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:I cannot speak for Richard but I have 30+ years C++
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily >>>>>>>>>>>>> verify
that the complete and correct x86 emulation of the input to >>>>>>>>>>>>> H(P,P)
by H would never reach the "ret" instruction of P because >>>>>>>>>>>>> both H
and P would remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>
If H does correctly determine that this is the case in a >>>>>>>>>>>>> finite
number of steps then H could reject its input on this >>>>>>>>>>>>> basis. Here
are the details of exactly how H does this in a finite >>>>>>>>>>>>> number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P >>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P >>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // >>>>>>>>>>>>> call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>>>
// actual fully operational code in the x86utm operating >>>>>>>>>>>>> system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack); >>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, >>>>>>>>>>>>> I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can >>>>>>>>>>>>> easily
examine its stored execution_trace of P and determine: >>>>>>>>>>>>> (a) P is calling H with the same arguments that H was >>>>>>>>>>>>> called with.
(b) No instructions in P could possibly escape this otherwise >>>>>>>>>>>>> infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is >>>>>>>>>>>>> invoked.
Technically competent software engineers may not know this >>>>>>>>>>>>> computer
science:
A halt decider must compute the mapping from its inputs to an >>>>>>>>>>>>> accept or reject state on the basis of the actual behavior >>>>>>>>>>>>> that is
actually specified by these inputs.
computation that halts … the Turing machine will halt >>>>>>>>>>>>> whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and >>>>>>>>>>>>> Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320) >>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427 >>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476 >>>>>>>>>>>> Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided >>>>>>>>>>>> correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at >>>>>>>>>>> software
engineering not meeting these specs:
A software engineer must be an expert in: the C programming >>>>>>>>>>> language,
the x86 programming language, exactly how C translates into >>>>>>>>>>> x86 and
the ability to recognize infinite recursion at the x86 assembly >>>>>>>>>>> language level. No knowledge of the halting problem is required. >>>>>>>>>>
experience; I also
have C and x86 assembly experience (I once wrote a Zilog Z80A CPU >>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite >>>>>>>>>> recursion;
the problem is that you cannot recognize the fact that the >>>>>>>>>> infinite
recursion only manifests as part of your invalid simulation-based >>>>>>>>>> omnishambles:
Every sufficiently competent software engineer can easily
verify that
the complete and correct x86 emulation of the input to H(Px,Px) >>>>>>>>> by H
would never reach the "ret" instruction of P because both H and >>>>>>>>> P would
remain stuck in infinitely recursive emulation.
H (if it was constructed correctly) is a computation, and a
computation *always* gives the same output for a given input. So >>>>>>>> it doesn't make sense to say what it "would" do. It either does >>>>>>>> or does not perform a complete and correct emulation. And
because H contains code to abort, and does abort, it does not do >>>>>>>> a complete emulation.
So the input must be given to a UTM, which by definition does a >>>>>>>> correct and complete simulation, to see what the actual behavior >>>>>>>> is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
Every sufficiently competent software engineer can easily verify >>>>>>> that
the complete and correct x86 emulation of the input to H(Px,Px) by H >>>>>>> would never reach the "ret" instruction of Px because both H and Px >>>>>>> would remain stuck in infinitely recursive emulation.
So you just repeated what you said instead of explaining why I'm
wrong. In other words you provided no rebuttal, which can only be
taken to mean that you have none.
provided an infallible one to that cannot possibly be correctly
refuted
you simply dodged it. That is a smart move for a dishonest person that >>>>> is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my
airtight correct reasoning. Another dodge will be construed as a tacit >>>>> admission of defeat.
As stated before H (or more accurately Ha) does not perform a
complete and correct emulation because it aborts. So by definition
it cannot be complete.
I claimed that H(P,P) correctly predicts that its complete and correct
x86 emulation of its input would never reach the "ret" instruction of P.
But since H, or more accurately Ha, *can't* do a correct and complete
emulation of its input, your point is moot.
_Infinite_Loop()
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f ...[00001082][00211e7f][00211e83] 55 push ebp ...[00001083][00211e7f][00211e83] 8bec mov ebp,esp ...[00001085][00211e7f][00211e83] ebfe jmp 00001085 ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning because H
*can't* do a correct and complete emulation of its input, H cannot
possibly determine that _Infinite_Loop() never halts.
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:And because H contains code to abort, and does abort, it does not do a complete emulation.
On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
On 6/22/2022 4:53 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote: >>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and lie about it:
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:I cannot speak for Richard but I have 30+ years C++ experience; I also
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify >>>>>>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P)
by H would never reach the "ret" instruction of P because both H >>>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>
If H does correctly determine that this is the case in a finite >>>>>>>>>>>>>> number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of >>>>>>>>>>>>>> steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P >>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P >>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>>>>
// actual fully operational code in the x86utm operating system >>>>>>>>>>>>>> u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack); >>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I)) >>>>>>>>>>>>>> goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily >>>>>>>>>>>>>> examine its stored execution_trace of P and determine: >>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise >>>>>>>>>>>>>> infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked. >>>>>>>>>>>>>>
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an >>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320) >>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427 >>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476 >>>>>>>>>>>>> Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software
engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly >>>>>>>>>>>> language level. No knowledge of the halting problem is required. >>>>>>>>>>>
have C and x86 assembly experience (I once wrote a Zilog Z80A CPU >>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
the problem is that you cannot recognize the fact that the infinite >>>>>>>>>>> recursion only manifests as part of your invalid simulation-based >>>>>>>>>>> omnishambles:
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H >>>>>>>>>> would never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely recursive emulation.
H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation.
_Infinite_Loop()But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.I never claimed that H(P,P) performs a complete and correct emulation of >>>> its input so your rebuttal is the strawman deception.Your entire basis and all of assumptions was incorrect so when I
So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
Every sufficiently competent software engineer can easily verify that >>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H >>>>>>>> would never reach the "ret" instruction of Px because both H and Px >>>>>>>> would remain stuck in infinitely recursive emulation.
So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
provided an infallible one to that cannot possibly be correctly refuted >>>>>> you simply dodged it. That is a smart move for a dishonest person that >>>>>> is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my
airtight correct reasoning. Another dodge will be construed as a tacit >>>>>> admission of defeat.
As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
I claimed that H(P,P) correctly predicts that its complete and correct >>>> x86 emulation of its input would never reach the "ret" instruction of P. >>>
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning because H
*can't* do a correct and complete emulation of its input, H cannot
possibly determine that _Infinite_Loop() never halts.
Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B
On 6/22/2022 8:45 PM, Richard Damon wrote:
On 6/22/22 9:41 PM, olcott wrote:
On 6/22/2022 8:36 PM, Richard Damon wrote:
On 6/22/22 9:29 PM, olcott wrote:
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it is an
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the
First you agree that my words are perfectly correct within
their specified context
Since you haven't actualy defined you context, and imply that it >>>>>>>> is the halting problem, where they can not be correct, that is >>>>>>>> not possible.
context of software engineering totally ignoring the context of
the halting problem.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify >>>>>>> that the complete and correct x86 emulation of the input to
H(P,P) by H would never reach the "ret" instruction of P because >>>>>>> both H and P would remain stuck in infinitely recursive emulation. >>>>>>>
So, if H actually is a program that does a COMPLETE and correct
x86 emulation of its input, then YES, as I have said many time
before, this combination is non-halting.
The fact that you need to keep going back to this, and seem to
just be refusing to accept the conditions under which you have
proved it just shows the problems with your thought process.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here >>>>>>> are the details of exactly how H does this in a finite number of >>>>>>> steps.
Except that NOW H isn't the H we were just talking about, so you
are just proving that you are either lying or an idiot.
Remember, the first analysis had the CONDITION on it that H did a
COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long
holds and you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack >>>>>>> u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly >>>>>>> address address data code language >>>>>>> ======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H >>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P); >>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18 >>>>>>> __asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack); >>>>>>> Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state,
&slave_state, &slave_stack, Address_of_H,
P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with. >>>>>>> (b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked. >>>>>>>
(b) is NOT a correct rule. Thos has been pointed out before, and
you have ignored it.
incorrect rule.
Here is an example where P does have instruction that could
possibly escape this otherwise infinitely recursive emulation:
void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}
FALLACY of proof by example. I never said that (b) isn't sometimes
true, just it isn't an always true condition. You fail at elementary
logic.
Try and find a valid counter-example. Every attempt at rebuttal that
is not a valid counter-example is one form of deception or another.
P(P)
That is not any example of (b), thus another mere strawman deception.
On 6/22/22 9:41 PM, olcott wrote:
On 6/22/2022 8:36 PM, Richard Damon wrote:
On 6/22/22 9:29 PM, olcott wrote:
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it is an
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the
First you agree that my words are perfectly correct within their >>>>>>>> specified context
Since you haven't actualy defined you context, and imply that it >>>>>>> is the halting problem, where they can not be correct, that is
not possible.
context of software engineering totally ignoring the context of
the halting problem.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P) >>>>>> by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely recursive emulation.
So, if H actually is a program that does a COMPLETE and correct x86
emulation of its input, then YES, as I have said many time before,
this combination is non-halting.
The fact that you need to keep going back to this, and seem to just
be refusing to accept the conditions under which you have proved it
just shows the problems with your thought process.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
Except that NOW H isn't the H we were just talking about, so you
are just proving that you are either lying or an idiot.
Remember, the first analysis had the CONDITION on it that H did a
COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long holds
and you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly >>>>>> address address data code language >>>>>> ======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H >>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P); >>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack); >>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state,
&slave_state, &slave_stack, Address_of_H, P,
I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with. >>>>>> (b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
(b) is NOT a correct rule. Thos has been pointed out before, and
you have ignored it.
incorrect rule.
Here is an example where P does have instruction that could possibly
escape this otherwise infinitely recursive emulation:
void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}
FALLACY of proof by example. I never said that (b) isn't sometimes
true, just it isn't an always true condition. You fail at elementary
logic.
Try and find a valid counter-example. Every attempt at rebuttal that
is not a valid counter-example is one form of deception or another.
P(P)
On 6/22/2022 8:44 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:_Infinite_Loop()
On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:I never claimed that H(P,P) performs a complete and correct
On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote: >>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:Your entire basis and all of assumptions was incorrect so when I >>>>>>> provided an infallible one to that cannot possibly be correctly
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote: >>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:Every sufficiently competent software engineer can easily
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and >>>>>>>>>>> lie about it:
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily >>>>>>>>>>>>>>> verify
that the complete and correct x86 emulation of the input >>>>>>>>>>>>>>> to H(P,P)
by H would never reach the "ret" instruction of P because >>>>>>>>>>>>>>> both H
and P would remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>
If H does correctly determine that this is the case in a >>>>>>>>>>>>>>> finite
number of steps then H could reject its input on this >>>>>>>>>>>>>>> basis. Here
are the details of exactly how H does this in a finite >>>>>>>>>>>>>>> number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P >>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P >>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 >>>>>>>>>>>>>>> // call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>>>>>
// actual fully operational code in the x86utm operating >>>>>>>>>>>>>>> system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, >>>>>>>>>>>>>>> slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, >>>>>>>>>>>>>>> P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can >>>>>>>>>>>>>>> easily
examine its stored execution_trace of P and determine: >>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was >>>>>>>>>>>>>>> called with.
(b) No instructions in P could possibly escape this >>>>>>>>>>>>>>> otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is >>>>>>>>>>>>>>> invoked.
Technically competent software engineers may not know >>>>>>>>>>>>>>> this computer
science:
A halt decider must compute the mapping from its inputs >>>>>>>>>>>>>>> to an
accept or reject state on the basis of the actual >>>>>>>>>>>>>>> behavior that is
actually specified by these inputs.
computation that halts … the Turing machine will halt >>>>>>>>>>>>>>> whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.
Linz, Peter 1990. An Introduction to Formal Languages and >>>>>>>>>>>>>>> Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320) >>>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427 >>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476 >>>>>>>>>>>>>> Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided >>>>>>>>>>>>>> correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at >>>>>>>>>>>>> software
engineering not meeting these specs:
A software engineer must be an expert in: the C programming >>>>>>>>>>>>> language,
the x86 programming language, exactly how C translates into >>>>>>>>>>>>> x86 and
the ability to recognize infinite recursion at the x86 >>>>>>>>>>>>> assembly
language level. No knowledge of the halting problem is >>>>>>>>>>>>> required.
I cannot speak for Richard but I have 30+ years C++
experience; I also
have C and x86 assembly experience (I once wrote a Zilog >>>>>>>>>>>> Z80A CPU
emulator in 80286 assembly) and I can recognize an infinite >>>>>>>>>>>> recursion;
the problem is that you cannot recognize the fact that the >>>>>>>>>>>> infinite
recursion only manifests as part of your invalid
simulation-based
omnishambles:
Every sufficiently competent software engineer can easily >>>>>>>>>>> verify that
the complete and correct x86 emulation of the input to
H(Px,Px) by H
would never reach the "ret" instruction of P because both H >>>>>>>>>>> and P would
remain stuck in infinitely recursive emulation.
H (if it was constructed correctly) is a computation, and a >>>>>>>>>> computation *always* gives the same output for a given input. >>>>>>>>>> So it doesn't make sense to say what it "would" do. It either >>>>>>>>>> does or does not perform a complete and correct emulation. And >>>>>>>>>> because H contains code to abort, and does abort, it does not >>>>>>>>>> do a complete emulation.
So the input must be given to a UTM, which by definition does >>>>>>>>>> a correct and complete simulation, to see what the actual
behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong. >>>>>>>>>
verify that
the complete and correct x86 emulation of the input to H(Px,Px) >>>>>>>>> by H
would never reach the "ret" instruction of Px because both H >>>>>>>>> and Px
would remain stuck in infinitely recursive emulation.
So you just repeated what you said instead of explaining why I'm >>>>>>>> wrong. In other words you provided no rebuttal, which can only >>>>>>>> be taken to mean that you have none.
refuted
you simply dodged it. That is a smart move for a dishonest person >>>>>>> that
is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my >>>>>>> airtight correct reasoning. Another dodge will be construed as a >>>>>>> tacit
admission of defeat.
As stated before H (or more accurately Ha) does not perform a
complete and correct emulation because it aborts. So by definition >>>>>> it cannot be complete.
emulation of
its input so your rebuttal is the strawman deception.
I claimed that H(P,P) correctly predicts that its complete and correct >>>>> x86 emulation of its input would never reach the "ret" instruction
of P.
But since H, or more accurately Ha, *can't* do a correct and
complete emulation of its input, your point is moot.
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning because H
*can't* do a correct and complete emulation of its input, H cannot
possibly determine that _Infinite_Loop() never halts.
Now who's using the strawman error? Just because H can determine that
_Infinite_Loop does not halt doesn't mean that it gets other cases
right. B
You just said that H(P,P) cannot correctly predict that the correct and complete x86 emulation of its input would never reach the "ret"
instruction of P without a compete x86 emulation of its input. I just
proved that is a very stupid thing to say.
On 6/22/22 10:15 PM, olcott wrote:
On 6/22/2022 8:44 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:_Infinite_Loop()
On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:I never claimed that H(P,P) performs a complete and correct
On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote: >>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:Your entire basis and all of assumptions was incorrect so when I >>>>>>>> provided an infallible one to that cannot possibly be correctly >>>>>>>> refuted
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:Every sufficiently competent software engineer can easily
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and >>>>>>>>>>>> lie about it:
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can >>>>>>>>>>>>>>>> easily verify
that the complete and correct x86 emulation of the input >>>>>>>>>>>>>>>> to H(P,P)
by H would never reach the "ret" instruction of P >>>>>>>>>>>>>>>> because both H
and P would remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>>
If H does correctly determine that this is the case in a >>>>>>>>>>>>>>>> finite
number of steps then H could reject its input on this >>>>>>>>>>>>>>>> basis. Here
are the details of exactly how H does this in a finite >>>>>>>>>>>>>>>> number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P >>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P >>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 >>>>>>>>>>>>>>>> // call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>>>>>>
// actual fully operational code in the x86utm operating >>>>>>>>>>>>>>>> system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, >>>>>>>>>>>>>>>> slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, >>>>>>>>>>>>>>>> P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can >>>>>>>>>>>>>>>> easily
examine its stored execution_trace of P and determine: >>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was >>>>>>>>>>>>>>>> called with.
(b) No instructions in P could possibly escape this >>>>>>>>>>>>>>>> otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is >>>>>>>>>>>>>>>> invoked.
Technically competent software engineers may not know >>>>>>>>>>>>>>>> this computer
science:
A halt decider must compute the mapping from its inputs >>>>>>>>>>>>>>>> to an
accept or reject state on the basis of the actual >>>>>>>>>>>>>>>> behavior that is
actually specified by these inputs.
computation that halts … the Turing machine will halt >>>>>>>>>>>>>>>> whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state. >>>>>>>>>>>>>>>>
Linz, Peter 1990. An Introduction to Formal Languages >>>>>>>>>>>>>>>> and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320) >>>>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427 >>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476 >>>>>>>>>>>>>>> Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided >>>>>>>>>>>>>>> correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent >>>>>>>>>>>>>> at software
engineering not meeting these specs:
A software engineer must be an expert in: the C
programming language,
the x86 programming language, exactly how C translates >>>>>>>>>>>>>> into x86 and
the ability to recognize infinite recursion at the x86 >>>>>>>>>>>>>> assembly
language level. No knowledge of the halting problem is >>>>>>>>>>>>>> required.
I cannot speak for Richard but I have 30+ years C++
experience; I also
have C and x86 assembly experience (I once wrote a Zilog >>>>>>>>>>>>> Z80A CPU
emulator in 80286 assembly) and I can recognize an infinite >>>>>>>>>>>>> recursion;
the problem is that you cannot recognize the fact that the >>>>>>>>>>>>> infinite
recursion only manifests as part of your invalid
simulation-based
omnishambles:
Every sufficiently competent software engineer can easily >>>>>>>>>>>> verify that
the complete and correct x86 emulation of the input to >>>>>>>>>>>> H(Px,Px) by H
would never reach the "ret" instruction of P because both H >>>>>>>>>>>> and P would
remain stuck in infinitely recursive emulation.
H (if it was constructed correctly) is a computation, and a >>>>>>>>>>> computation *always* gives the same output for a given input. >>>>>>>>>>> So it doesn't make sense to say what it "would" do. It either >>>>>>>>>>> does or does not perform a complete and correct emulation. >>>>>>>>>>> And because H contains code to abort, and does abort, it does >>>>>>>>>>> not do a complete emulation.
So the input must be given to a UTM, which by definition does >>>>>>>>>>> a correct and complete simulation, to see what the actual >>>>>>>>>>> behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong. >>>>>>>>>>
verify that
the complete and correct x86 emulation of the input to
H(Px,Px) by H
would never reach the "ret" instruction of Px because both H >>>>>>>>>> and Px
would remain stuck in infinitely recursive emulation.
So you just repeated what you said instead of explaining why >>>>>>>>> I'm wrong. In other words you provided no rebuttal, which can >>>>>>>>> only be taken to mean that you have none.
you simply dodged it. That is a smart move for a dishonest
person that
is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my >>>>>>>> airtight correct reasoning. Another dodge will be construed as a >>>>>>>> tacit
admission of defeat.
As stated before H (or more accurately Ha) does not perform a
complete and correct emulation because it aborts. So by
definition it cannot be complete.
emulation of
its input so your rebuttal is the strawman deception.
I claimed that H(P,P) correctly predicts that its complete and
correct
x86 emulation of its input would never reach the "ret" instruction >>>>>> of P.
But since H, or more accurately Ha, *can't* do a correct and
complete emulation of its input, your point is moot.
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning because H
*can't* do a correct and complete emulation of its input, H cannot
possibly determine that _Infinite_Loop() never halts.
Now who's using the strawman error? Just because H can determine
that _Infinite_Loop does not halt doesn't mean that it gets other
cases right. B
You just said that H(P,P) cannot correctly predict that the correct
and complete x86 emulation of its input would never reach the "ret"
instruction of P without a compete x86 emulation of its input. I just
proved that is a very stupid thing to say.
No, that isn't what he said. Just shows you can't read.
He said that an H that aborts its simulation can't do a Complete and
Correct emulation of its input.
There are no UTM's in software engineering thus yet another strawman deception.
On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote:And because H contains code to abort, and does abort, it does not do a complete emulation.
On 6/22/2022 8:44 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote: >>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and lie about it:
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:I cannot speak for Richard but I have 30+ years C++ experience; I also
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P)
by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>>
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P >>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P >>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>>>>>>
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack); >>>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine: >>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise >>>>>>>>>>>>>>>> infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an >>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state. >>>>>>>>>>>>>>>>
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320) >>>>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427 >>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476 >>>>>>>>>>>>>>> Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software
engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly >>>>>>>>>>>>>> language level. No knowledge of the halting problem is required. >>>>>>>>>>>>>
have C and x86 assembly experience (I once wrote a Zilog Z80A CPU >>>>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
the problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based >>>>>>>>>>>>> omnishambles:
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely recursive emulation.
H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation.
P), would do. And it fails to do that.You just said that H(P,P) cannot correctly predict that the correct and_Infinite_Loop()But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.I never claimed that H(P,P) performs a complete and correct emulation of >>>>>> its input so your rebuttal is the strawman deception.Your entire basis and all of assumptions was incorrect so when I >>>>>>>> provided an infallible one to that cannot possibly be correctly refuted
So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H >>>>>>>>>> would never reach the "ret" instruction of Px because both H and Px >>>>>>>>>> would remain stuck in infinitely recursive emulation.
So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
you simply dodged it. That is a smart move for a dishonest person that >>>>>>>> is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my >>>>>>>> airtight correct reasoning. Another dodge will be construed as a tacit >>>>>>>> admission of defeat.
As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
I claimed that H(P,P) correctly predicts that its complete and correct >>>>>> x86 emulation of its input would never reach the "ret" instruction of P. >>>>>
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning because H
*can't* do a correct and complete emulation of its input, H cannot
possibly determine that _Infinite_Loop() never halts.
Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B
complete x86 emulation of its input would never reach the "ret"
instruction of P without a compete x86 emulation of its input. I just
proved that is a very stupid thing to say.
You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.e. UTM(P,
On 6/22/2022 9:22 PM, Richard Damon wrote:
On 6/22/22 10:15 PM, olcott wrote:
On 6/22/2022 8:44 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:_Infinite_Loop()
On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote: >>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:I never claimed that H(P,P) performs a complete and correct
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote: >>>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:Your entire basis and all of assumptions was incorrect so when I >>>>>>>>> provided an infallible one to that cannot possibly be correctly >>>>>>>>> refuted
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote: >>>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and >>>>>>>>>>>>> lie about it:
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can >>>>>>>>>>>>>>>>> easily verify
that the complete and correct x86 emulation of the >>>>>>>>>>>>>>>>> input to H(P,P)
by H would never reach the "ret" instruction of P >>>>>>>>>>>>>>>>> because both H
and P would remain stuck in infinitely recursive >>>>>>>>>>>>>>>>> emulation.
If H does correctly determine that this is the case in >>>>>>>>>>>>>>>>> a finite
number of steps then H could reject its input on this >>>>>>>>>>>>>>>>> basis. Here
are the details of exactly how H does this in a finite >>>>>>>>>>>>>>>>> number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P >>>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P >>>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 >>>>>>>>>>>>>>>>> // call H
Infinitely Recursive Simulation Detected Simulation >>>>>>>>>>>>>>>>> Stopped
// actual fully operational code in the x86utm >>>>>>>>>>>>>>>>> operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k; >>>>>>>>>>>>>>>>> u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, >>>>>>>>>>>>>>>>> slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack,
Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it >>>>>>>>>>>>>>>>> can easily
examine its stored execution_trace of P and determine: >>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was >>>>>>>>>>>>>>>>> called with.
(b) No instructions in P could possibly escape this >>>>>>>>>>>>>>>>> otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is >>>>>>>>>>>>>>>>> invoked.
Technically competent software engineers may not know >>>>>>>>>>>>>>>>> this computer
science:
A halt decider must compute the mapping from its inputs >>>>>>>>>>>>>>>>> to an
accept or reject state on the basis of the actual >>>>>>>>>>>>>>>>> behavior that is
actually specified by these inputs.
computation that halts … the Turing machine will halt >>>>>>>>>>>>>>>>> whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state. >>>>>>>>>>>>>>>>>
Linz, Peter 1990. An Introduction to Formal Languages >>>>>>>>>>>>>>>>> and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320) >>>>>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>>>>>> }
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427 >>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476 >>>>>>>>>>>>>>>> Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been >>>>>>>>>>>>>>>> decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent >>>>>>>>>>>>>>> at software
engineering not meeting these specs:
A software engineer must be an expert in: the C
programming language,
the x86 programming language, exactly how C translates >>>>>>>>>>>>>>> into x86 and
the ability to recognize infinite recursion at the x86 >>>>>>>>>>>>>>> assembly
language level. No knowledge of the halting problem is >>>>>>>>>>>>>>> required.
I cannot speak for Richard but I have 30+ years C++ >>>>>>>>>>>>>> experience; I also
have C and x86 assembly experience (I once wrote a Zilog >>>>>>>>>>>>>> Z80A CPU
emulator in 80286 assembly) and I can recognize an >>>>>>>>>>>>>> infinite recursion;
the problem is that you cannot recognize the fact that the >>>>>>>>>>>>>> infinite
recursion only manifests as part of your invalid
simulation-based
omnishambles:
Every sufficiently competent software engineer can easily >>>>>>>>>>>>> verify that
the complete and correct x86 emulation of the input to >>>>>>>>>>>>> H(Px,Px) by H
would never reach the "ret" instruction of P because both H >>>>>>>>>>>>> and P would
remain stuck in infinitely recursive emulation.
H (if it was constructed correctly) is a computation, and a >>>>>>>>>>>> computation *always* gives the same output for a given >>>>>>>>>>>> input. So it doesn't make sense to say what it "would" do. >>>>>>>>>>>> It either does or does not perform a complete and correct >>>>>>>>>>>> emulation. And because H contains code to abort, and does >>>>>>>>>>>> abort, it does not do a complete emulation.
So the input must be given to a UTM, which by definition >>>>>>>>>>>> does a correct and complete simulation, to see what the >>>>>>>>>>>> actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 >>>>>>>>>>>> is wrong.
Every sufficiently competent software engineer can easily >>>>>>>>>>> verify that
the complete and correct x86 emulation of the input to
H(Px,Px) by H
would never reach the "ret" instruction of Px because both H >>>>>>>>>>> and Px
would remain stuck in infinitely recursive emulation.
So you just repeated what you said instead of explaining why >>>>>>>>>> I'm wrong. In other words you provided no rebuttal, which can >>>>>>>>>> only be taken to mean that you have none.
you simply dodged it. That is a smart move for a dishonest
person that
is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my >>>>>>>>> airtight correct reasoning. Another dodge will be construed as >>>>>>>>> a tacit
admission of defeat.
As stated before H (or more accurately Ha) does not perform a
complete and correct emulation because it aborts. So by
definition it cannot be complete.
emulation of
its input so your rebuttal is the strawman deception.
I claimed that H(P,P) correctly predicts that its complete and
correct
x86 emulation of its input would never reach the "ret"
instruction of P.
But since H, or more accurately Ha, *can't* do a correct and
complete emulation of its input, your point is moot.
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f >>>>> ...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning because H
*can't* do a correct and complete emulation of its input, H cannot
possibly determine that _Infinite_Loop() never halts.
Now who's using the strawman error? Just because H can determine
that _Infinite_Loop does not halt doesn't mean that it gets other
cases right. B
You just said that H(P,P) cannot correctly predict that the correct
and complete x86 emulation of its input would never reach the "ret"
instruction of P without a compete x86 emulation of its input. I just
proved that is a very stupid thing to say.
No, that isn't what he said. Just shows you can't read.
He said that an H that aborts its simulation can't do a Complete and
Correct emulation of its input.
Implying that H cannot predict the behavior of the complete and correct
x86 emulation of its input without performing an actual complete emulation.
On 6/22/22 10:18 PM, olcott wrote:
On 6/22/2022 8:45 PM, Richard Damon wrote:
On 6/22/22 9:41 PM, olcott wrote:
On 6/22/2022 8:36 PM, Richard Damon wrote:
On 6/22/22 9:29 PM, olcott wrote:
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it is an
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the
First you agree that my words are perfectly correct within >>>>>>>>>> their specified context
Since you haven't actualy defined you context, and imply that >>>>>>>>> it is the halting problem, where they can not be correct, that >>>>>>>>> is not possible.
context of software engineering totally ignoring the context of >>>>>>>> the halting problem.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify >>>>>>>> that the complete and correct x86 emulation of the input to
H(P,P) by H would never reach the "ret" instruction of P because >>>>>>>> both H and P would remain stuck in infinitely recursive emulation. >>>>>>>>
So, if H actually is a program that does a COMPLETE and correct
x86 emulation of its input, then YES, as I have said many time
before, this combination is non-halting.
The fact that you need to keep going back to this, and seem to
just be refusing to accept the conditions under which you have
proved it just shows the problems with your thought process.
If H does correctly determine that this is the case in a finite >>>>>>>> number of steps then H could reject its input on this basis.
Here are the details of exactly how H does this in a finite
number of steps.
Except that NOW H isn't the H we were just talking about, so you >>>>>>> are just proving that you are either lying or an idiot.
Remember, the first analysis had the CONDITION on it that H did a >>>>>>> COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long
holds and you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack >>>>>>>> u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly >>>>>>>> address address data code language >>>>>>>> ======== ======== ======== ========= ============= >>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H >>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system >>>>>>>> u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17 >>>>>>>> u32 code_end = get_code_end(P); >>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
__asm lea eax, HERE // 2022-06-18 >>>>>>>> __asm sub eax, 6 // 2022-06-18 >>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack); >>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state,
&slave_state, &slave_stack, Address_of_H,
P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily >>>>>>>> examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with. >>>>>>>> (b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked. >>>>>>>>
(b) is NOT a correct rule. Thos has been pointed out before, and >>>>>>> you have ignored it.
incorrect rule.
Here is an example where P does have instruction that could
possibly escape this otherwise infinitely recursive emulation:
void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}
FALLACY of proof by example. I never said that (b) isn't sometimes
true, just it isn't an always true condition. You fail at
elementary logic.
Try and find a valid counter-example. Every attempt at rebuttal that
is not a valid counter-example is one form of deception or another.
P(P)
That is not any example of (b), thus another mere strawman deception.
Why not?
On 6/22/2022 9:34 PM, Richard Damon wrote:
On 6/22/22 10:18 PM, olcott wrote:It is not an example of the simulation of the input to H(P,P) at all.
On 6/22/2022 8:45 PM, Richard Damon wrote:
On 6/22/22 9:41 PM, olcott wrote:
On 6/22/2022 8:36 PM, Richard Damon wrote:
On 6/22/22 9:29 PM, olcott wrote:
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it is an >>>>>>> incorrect rule.
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the >>>>>>>>> context of software engineering totally ignoring the context of >>>>>>>>> the halting problem.
First you agree that my words are perfectly correct within >>>>>>>>>>> their specified context
Since you haven't actualy defined you context, and imply that >>>>>>>>>> it is the halting problem, where they can not be correct, that >>>>>>>>>> is not possible.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily
verify that the complete and correct x86 emulation of the input >>>>>>>>> to H(P,P) by H would never reach the "ret" instruction of P
because both H and P would remain stuck in infinitely recursive >>>>>>>>> emulation.
So, if H actually is a program that does a COMPLETE and correct >>>>>>>> x86 emulation of its input, then YES, as I have said many time >>>>>>>> before, this combination is non-halting.
The fact that you need to keep going back to this, and seem to >>>>>>>> just be refusing to accept the conditions under which you have >>>>>>>> proved it just shows the problems with your thought process.
If H does correctly determine that this is the case in a finite >>>>>>>>> number of steps then H could reject its input on this basis. >>>>>>>>> Here are the details of exactly how H does this in a finite
number of steps.
Except that NOW H isn't the H we were just talking about, so you >>>>>>>> are just proving that you are either lying or an idiot.
Remember, the first analysis had the CONDITION on it that H did >>>>>>>> a COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long
holds and you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack >>>>>>>>> u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly >>>>>>>>> address address data code language >>>>>>>>> ======== ======== ======== ========= ============= >>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax //
push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx //
push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // >>>>>>>>> call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system >>>>>>>>> u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17 >>>>>>>>> u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
__asm lea eax, HERE // 2022-06-18 >>>>>>>>> __asm sub eax, 6 // 2022-06-18 >>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack); >>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>> &master_state,
&slave_state, &slave_stack, Address_of_H,
P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily >>>>>>>>> examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with. >>>>>>>>> (b) No instructions in P could possibly escape this otherwise >>>>>>>>> infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked. >>>>>>>>>
(b) is NOT a correct rule. Thos has been pointed out before, and >>>>>>>> you have ignored it.
Here is an example where P does have instruction that could
possibly escape this otherwise infinitely recursive emulation:
void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}
FALLACY of proof by example. I never said that (b) isn't sometimes >>>>>> true, just it isn't an always true condition. You fail at
elementary logic.
Try and find a valid counter-example. Every attempt at rebuttal
that is not a valid counter-example is one form of deception or
another.
P(P)
That is not any example of (b), thus another mere strawman deception.
Why not?
Basically you must adapt P so that when H(P,P) emulates its input it determines that P never reaches its "ret" instruction and the adapted emulated P still reaches its "ret" instruction.
On 6/22/22 10:55 PM, olcott wrote:
On 6/22/2022 9:34 PM, Richard Damon wrote:
On 6/22/22 10:18 PM, olcott wrote:It is not an example of the simulation of the input to H(P,P) at all.
On 6/22/2022 8:45 PM, Richard Damon wrote:
On 6/22/22 9:41 PM, olcott wrote:
On 6/22/2022 8:36 PM, Richard Damon wrote:
On 6/22/22 9:29 PM, olcott wrote:
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it is >>>>>>>> an incorrect rule.
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the >>>>>>>>>> context of software engineering totally ignoring the context >>>>>>>>>> of the halting problem.
First you agree that my words are perfectly correct within >>>>>>>>>>>> their specified context
Since you haven't actualy defined you context, and imply that >>>>>>>>>>> it is the halting problem, where they can not be correct, >>>>>>>>>>> that is not possible.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>> [000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>> [000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily
verify that the complete and correct x86 emulation of the
input to H(P,P) by H would never reach the "ret" instruction >>>>>>>>>> of P because both H and P would remain stuck in infinitely >>>>>>>>>> recursive emulation.
So, if H actually is a program that does a COMPLETE and correct >>>>>>>>> x86 emulation of its input, then YES, as I have said many time >>>>>>>>> before, this combination is non-halting.
The fact that you need to keep going back to this, and seem to >>>>>>>>> just be refusing to accept the conditions under which you have >>>>>>>>> proved it just shows the problems with your thought process. >>>>>>>>>
If H does correctly determine that this is the case in a
finite number of steps then H could reject its input on this >>>>>>>>>> basis. Here are the details of exactly how H does this in a >>>>>>>>>> finite number of steps.
Except that NOW H isn't the H we were just talking about, so >>>>>>>>> you are just proving that you are either lying or an idiot.
Remember, the first analysis had the CONDITION on it that H did >>>>>>>>> a COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long >>>>>>>>> holds and you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack >>>>>>>>>> u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly >>>>>>>>>> address address data code language >>>>>>>>>> ======== ======== ======== ========= ============= >>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp >>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax //
push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx //
push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // >>>>>>>>>> call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>
// actual fully operational code in the x86utm operating system >>>>>>>>>> u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17 >>>>>>>>>> u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
__asm lea eax, HERE // 2022-06-18 >>>>>>>>>> __asm sub eax, 6 // 2022-06-18 >>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack); >>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>> &master_state,
&slave_state, &slave_stack,
Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can
easily examine its stored execution_trace of P and determine: >>>>>>>>>> (a) P is calling H with the same arguments that H was called >>>>>>>>>> with.
(b) No instructions in P could possibly escape this otherwise >>>>>>>>>> infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked. >>>>>>>>>>
(b) is NOT a correct rule. Thos has been pointed out before, >>>>>>>>> and you have ignored it.
Here is an example where P does have instruction that could
possibly escape this otherwise infinitely recursive emulation: >>>>>>>>
void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}
FALLACY of proof by example. I never said that (b) isn't
sometimes true, just it isn't an always true condition. You fail >>>>>>> at elementary logic.
Try and find a valid counter-example. Every attempt at rebuttal
that is not a valid counter-example is one form of deception or
another.
P(P)
That is not any example of (b), thus another mere strawman deception.
Why not?
Why is P not P?
On 6/22/2022 10:41 PM, Richard Damon wrote:
On 6/22/22 10:55 PM, olcott wrote:
On 6/22/2022 9:34 PM, Richard Damon wrote:
On 6/22/22 10:18 PM, olcott wrote:It is not an example of the simulation of the input to H(P,P) at all.
On 6/22/2022 8:45 PM, Richard Damon wrote:
On 6/22/22 9:41 PM, olcott wrote:
On 6/22/2022 8:36 PM, Richard Damon wrote:
On 6/22/22 9:29 PM, olcott wrote:
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it is >>>>>>>>> an incorrect rule.
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the >>>>>>>>>>> context of software engineering totally ignoring the context >>>>>>>>>>> of the halting problem.
First you agree that my words are perfectly correct within >>>>>>>>>>>>> their specified context
Since you haven't actualy defined you context, and imply >>>>>>>>>>>> that it is the halting problem, where they can not be
correct, that is not possible.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>> [000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>> [000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax >>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9 >>>>>>>>>>> [000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily >>>>>>>>>>> verify that the complete and correct x86 emulation of the >>>>>>>>>>> input to H(P,P) by H would never reach the "ret" instruction >>>>>>>>>>> of P because both H and P would remain stuck in infinitely >>>>>>>>>>> recursive emulation.
So, if H actually is a program that does a COMPLETE and
correct x86 emulation of its input, then YES, as I have said >>>>>>>>>> many time before, this combination is non-halting.
The fact that you need to keep going back to this, and seem to >>>>>>>>>> just be refusing to accept the conditions under which you have >>>>>>>>>> proved it just shows the problems with your thought process. >>>>>>>>>>
If H does correctly determine that this is the case in a >>>>>>>>>>> finite number of steps then H could reject its input on this >>>>>>>>>>> basis. Here are the details of exactly how H does this in a >>>>>>>>>>> finite number of steps.
Except that NOW H isn't the H we were just talking about, so >>>>>>>>>> you are just proving that you are either lying or an idiot. >>>>>>>>>>
Remember, the first analysis had the CONDITION on it that H >>>>>>>>>> did a COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long >>>>>>>>>> holds and you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack >>>>>>>>>>> u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly >>>>>>>>>>> address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp >>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax //
push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx //
push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // >>>>>>>>>>> call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>
// actual fully operational code in the x86utm operating system >>>>>>>>>>> u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17 >>>>>>>>>>> u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*) >>>>>>>>>>> Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
__asm lea eax, HERE // 2022-06-18 >>>>>>>>>>> __asm sub eax, 6 // 2022-06-18 >>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state,
slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>> &master_state,
&slave_state, &slave_stack,
Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can >>>>>>>>>>> easily examine its stored execution_trace of P and determine: >>>>>>>>>>> (a) P is calling H with the same arguments that H was called >>>>>>>>>>> with.
(b) No instructions in P could possibly escape this otherwise >>>>>>>>>>> infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked. >>>>>>>>>>>
(b) is NOT a correct rule. Thos has been pointed out before, >>>>>>>>>> and you have ignored it.
Here is an example where P does have instruction that could
possibly escape this otherwise infinitely recursive emulation: >>>>>>>>>
void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}
FALLACY of proof by example. I never said that (b) isn't
sometimes true, just it isn't an always true condition. You fail >>>>>>>> at elementary logic.
Try and find a valid counter-example. Every attempt at rebuttal
that is not a valid counter-example is one form of deception or
another.
P(P)
That is not any example of (b), thus another mere strawman deception. >>>>>
Why not?
Why is P not P?
It is not a direct rebuttal of my original claim.
This would be a direct rebuttal:
You must adapt P so that when H(P,P) emulates its input it determines
that P never reaches its "ret" instruction and the adapted emulated P
still reaches its "ret" instruction.
On Wednesday, June 22, 2022 at 10:46:14 PM UTC-4, olcott wrote:emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
On 6/22/2022 9:23 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote:
On 6/22/2022 8:44 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote: >>>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and lie about it:
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P)
by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>>>>
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp >>>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P >>>>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P >>>>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>>>>>>>>
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k; >>>>>>>>>>>>>>>>>> u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) >>>>>>>>>>>>>>>>>> * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated >>>>>>>>>>>>>>>>>> }
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine: >>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state. >>>>>>>>>>>>>>>>>>
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320) >>>>>>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>>>>>>> }
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax >>>>>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427 >>>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476 >>>>>>>>>>>>>>>>> Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp >>>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software
engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly
language level. No knowledge of the halting problem is required.
I cannot speak for Richard but I have 30+ years C++ experience; I also
have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
emulator in 80286 assembly) and I can recognize an infinite recursion;
the problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based
omnishambles:
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely recursive emulation.
H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct
P), would do. And it fails to do that.You just said that H(P,P) cannot correctly predict that the correct and >>>> complete x86 emulation of its input would never reach the "ret"_Infinite_Loop()I never claimed that H(P,P) performs a complete and correct emulation ofYour entire basis and all of assumptions was incorrect so when I >>>>>>>>>> provided an infallible one to that cannot possibly be correctly refuted
So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of Px because both H and Px
would remain stuck in infinitely recursive emulation.
So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
you simply dodged it. That is a smart move for a dishonest person that
is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my >>>>>>>>>> airtight correct reasoning. Another dodge will be construed as a tacit
admission of defeat.
As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
its input so your rebuttal is the strawman deception.
I claimed that H(P,P) correctly predicts that its complete and correct >>>>>>>> x86 emulation of its input would never reach the "ret" instruction of P.
But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f >>>>>> ...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning because H >>>>>> *can't* do a correct and complete emulation of its input, H cannot >>>>>> possibly determine that _Infinite_Loop() never halts.
Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B
instruction of P without a compete x86 emulation of its input. I just
proved that is a very stupid thing to say.
You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.e. UTM(P,
There are no UTM's in software engineering thus yet another strawman
deception.
Now you're just making things up. Of course there are UTMs. Anything that does a correct and complete emulation is a UTM.
Just goes to show how desperate you're getting to make a statement like that.
On 6/23/2022 12:13 AM, olcott wrote:
On 6/22/2022 10:41 PM, Richard Damon wrote:
On 6/22/22 10:55 PM, olcott wrote:
On 6/22/2022 9:34 PM, Richard Damon wrote:
On 6/22/22 10:18 PM, olcott wrote:It is not an example of the simulation of the input to H(P,P) at all.
On 6/22/2022 8:45 PM, Richard Damon wrote:
On 6/22/22 9:41 PM, olcott wrote:
On 6/22/2022 8:36 PM, Richard Damon wrote:
On 6/22/22 9:29 PM, olcott wrote:
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it is >>>>>>>>>> an incorrect rule.
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the >>>>>>>>>>>> context of software engineering totally ignoring the context >>>>>>>>>>>> of the halting problem.
First you agree that my words are perfectly correct within >>>>>>>>>>>>>> their specified context
Since you haven't actualy defined you context, and imply >>>>>>>>>>>>> that it is the halting problem, where they can not be >>>>>>>>>>>>> correct, that is not possible.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp >>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp >>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>> [000010d8](01) 50 push eax >>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>> [000010dc](01) 51 push ecx >>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax >>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb >>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9 >>>>>>>>>>>> [000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily >>>>>>>>>>>> verify that the complete and correct x86 emulation of the >>>>>>>>>>>> input to H(P,P) by H would never reach the "ret" instruction >>>>>>>>>>>> of P because both H and P would remain stuck in infinitely >>>>>>>>>>>> recursive emulation.
So, if H actually is a program that does a COMPLETE and
correct x86 emulation of its input, then YES, as I have said >>>>>>>>>>> many time before, this combination is non-halting.
The fact that you need to keep going back to this, and seem >>>>>>>>>>> to just be refusing to accept the conditions under which you >>>>>>>>>>> have proved it just shows the problems with your thought >>>>>>>>>>> process.
If H does correctly determine that this is the case in a >>>>>>>>>>>> finite number of steps then H could reject its input on this >>>>>>>>>>>> basis. Here are the details of exactly how H does this in a >>>>>>>>>>>> finite number of steps.
Except that NOW H isn't the H we were just talking about, so >>>>>>>>>>> you are just proving that you are either lying or an idiot. >>>>>>>>>>>
Remember, the first analysis had the CONDITION on it that H >>>>>>>>>>> did a COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long >>>>>>>>>>> holds and you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP >>>>>>>>>>>> u32 TOS; // Current value of Top of Stack >>>>>>>>>>>> u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly >>>>>>>>>>>> address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp >>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax //
push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx //
push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // >>>>>>>>>>>> call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>>
// actual fully operational code in the x86utm operating system >>>>>>>>>>>> u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17 >>>>>>>>>>>> u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*) >>>>>>>>>>>> Allocate(sizeof(Registers));
Registers* slave_state = (Registers*) >>>>>>>>>>>> Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
__asm lea eax, HERE // 2022-06-18 >>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18 >>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18 >>>>>>>>>>>> __asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state,
slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>> &master_state,
&slave_state, &slave_stack,
Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can >>>>>>>>>>>> easily examine its stored execution_trace of P and determine: >>>>>>>>>>>> (a) P is calling H with the same arguments that H was called >>>>>>>>>>>> with.
(b) No instructions in P could possibly escape this
otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is >>>>>>>>>>>> invoked.
(b) is NOT a correct rule. Thos has been pointed out before, >>>>>>>>>>> and you have ignored it.
Here is an example where P does have instruction that could >>>>>>>>>> possibly escape this otherwise infinitely recursive emulation: >>>>>>>>>>
void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}
FALLACY of proof by example. I never said that (b) isn't
sometimes true, just it isn't an always true condition. You
fail at elementary logic.
Try and find a valid counter-example. Every attempt at rebuttal >>>>>>>> that is not a valid counter-example is one form of deception or >>>>>>>> another.
P(P)
That is not any example of (b), thus another mere strawman deception. >>>>>>
Why not?
Why is P not P?
It is not a direct rebuttal of my original claim.
This would be a direct rebuttal:
You must adapt P so that when H(P,P) emulates its input it determines
that P never reaches its "ret" instruction and the adapted emulated P
still reaches its "ret" instruction.
Unless you find that at least one input where it gets the wrong answer
you have not refuted me.
On 23/06/2022 13:13, Paul N wrote:
On Thursday, June 23, 2022 at 2:20:40 AM UTC+1, olcott wrote:
On 6/22/2022 8:05 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 8:56:08 PM UTC-4, olcott wrote:
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
I claim that H(P,P) correctly predicts that its complete and correct x86 >>> emulation of its input would never reach the "ret" instruction of P.
To split this claim down into three parts:
You are claiming that H(P,P) terminates.
You are claiming that the value returned by H(P,P) is zero/false,
indicating that P(P) would not terminate.
You are claiming that this result is correct, and that P(P) does
indeed not terminate.
This is what you are saying, correct?
So let's look at P(P). The first thing is does is call H(P,P). This,
you have stated many times including just above, terminates. It gives
a value zero. Thus the infinite loop is not entered, and the next
instruction to be executed is the "return".
So P(P) does terminate, contrary to what you claimed.
PO acknowledges that P(P) does terminate, and has posted one of his
"traces" showing this. (Note: his traces are not showing x86
instructions from a single x86 processor - the entries are from multiple "logical processors" with some of the processors being simulated - the simulation logic (including tests that may decide to terminate the
simulating activity at some point) is suppressed from the trace, so that
you won't be "confused"!)
PO claims instead that :
- H(P,P) returns 0 (as you say)
- P(p) terminates
- H(P,P) is "correct" to return 0, even though 0 is the wrong halting
problem answer, because H's /simulation/ of P(P) never reaches P's
final ret instruction - this is correct, because H only simulates
until some internal test matches, at which point it stops
simulating P(P), and indeed that happens before P(P) simulation
gets as far as the P ret instruction.
PO has lots of incoherent waffle which serves only to confuse PO into believing that H is returning the "correct" answer, when it is obviously wrong [from the HP perspective].
Mike.
On Wednesday, June 22, 2022 at 11:10:50 PM UTC+1, Jeff Barnett wrote:put a post here on comp.theory addressing the more theoretical points, which hopefully will be more to your liking; if you disagree with the points I've made there then probably best to reply to that post directly.
On 6/22/2022 12:10 PM, olcott wrote:
On 6/22/2022 12:11 PM, Jeff Barnett wrote:Let's give Paul N a little credit but not much; notice that he doesn't
On 6/21/2022 8:38 PM, olcott wrote:After 100 reviewers in a dozen forums over a period of one year:
On 6/14/2022 6:47 AM, Paul N wrote:
Yes, it is clear to us humans watching
it that the program is repeating itself.
Thus we can appreciate that it will never
reach the final "ret" - indeed, it won't
even get to the infinite loop identified above.
If H can determine that this is the case in a finite number of steps
then H could correctly reject its input on this basis.
even understand the point of the exercise which is that the *same
function* must be used for both inner and outer purposes.
Olcott has snipped part of the post where I did briefly address this. However, he did say that his purpose in posting to comp.lang.c and comp.lang.c++ was simply to check the language aspects of his posts, and they did seem OK on that basis. I've just
On 6/23/2022 12:13 AM, olcott wrote:
On 6/22/2022 10:41 PM, Richard Damon wrote:
On 6/22/22 10:55 PM, olcott wrote:
On 6/22/2022 9:34 PM, Richard Damon wrote:
On 6/22/22 10:18 PM, olcott wrote:It is not an example of the simulation of the input to H(P,P) at
On 6/22/2022 8:45 PM, Richard Damon wrote:
On 6/22/22 9:41 PM, olcott wrote:
On 6/22/2022 8:36 PM, Richard Damon wrote:
On 6/22/22 9:29 PM, olcott wrote:
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it >>>>>>>>> is an incorrect rule.
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:
First you agree that these words are 100% correct within >>>>>>>>>>> the context of software engineering totally ignoring the >>>>>>>>>>> context of the halting problem.First you agree that my words are perfectly correct >>>>>>>>>>>>> within their specified context
Since you haven't actualy defined you context, and imply >>>>>>>>>>>> that it is the halting problem, where they can not be >>>>>>>>>>>> correct, that is not possible.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
�� if (H(x, x))
���� HERE: goto HERE;
�� return;
}
int main()
{
�� Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01)� 55������������� push ebp
[000010d3](02)� 8bec����������� mov ebp,esp
[000010d5](03)� 8b4508��������� mov eax,[ebp+08]
[000010d8](01)� 50������������� push eax
[000010d9](03)� 8b4d08��������� mov ecx,[ebp+08]
[000010dc](01)� 51������������� push ecx
[000010dd](05)� e820feffff����� call 00000f02
[000010e2](03)� 83c408��������� add esp,+08
[000010e5](02)� 85c0����������� test eax,eax
[000010e7](02)� 7402����������� jz 000010eb
[000010e9](02)� ebfe����������� jmp 000010e9
[000010eb](01)� 5d������������� pop ebp
[000010ec](01)� c3������������� ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily >>>>>>>>>>> verify that the complete and correct x86 emulation of the >>>>>>>>>>> input to H(P,P) by H would never reach the "ret"
instruction of P because both H and P would remain stuck >>>>>>>>>>> in infinitely recursive emulation.
So, if H actually is a program that does a COMPLETE and >>>>>>>>>> correct x86 emulation of its input, then YES, as I have
said many time before, this combination is non-halting.
The fact that you need to keep going back to this, and
seem to just be refusing to accept the conditions under
which you have proved it just shows the problems with your >>>>>>>>>> thought process.
If H does correctly determine that this is the case in a >>>>>>>>>>> finite number of steps then H could reject its input on >>>>>>>>>>> this basis. Here are the details of exactly how H does >>>>>>>>>>> this in a finite number of steps.
Except that NOW H isn't the H we were just talking about, >>>>>>>>>> so you are just proving that you are either lying or an
idiot.
Remember, the first analysis had the CONDITION on it that >>>>>>>>>> H did a COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no >>>>>>>>>> long holds and you are shown to be a lying idiot.
typedef struct Decoded
{
�� u32 Address;
�� u32 ESP;��������� // Current value of ESP
�� u32 TOS;��������� // Current value of Top of Stack
�� u32 NumBytes;
�� u32 Simplified_Opcode;
�� u32 Decode_Target;
} Decoded_Line_Of_Code;
��machine�� stack���� stack���� machine��� assembly
��address�� address�� data����� code������ language
��========� ========� ========� =========� ============= >>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55�������� push ebp
[000010d3][00211e8a][00211e8e] 8bec������ mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508���� mov eax,[ebp+08] >>>>>>>>>>> [000010d8][00211e86][000010d2] 50�������� push eax
// push P
[000010d9][00211e86][000010d2] 8b4d08���� mov ecx,[ebp+08] >>>>>>>>>>> [000010dc][00211e82][000010d2] 51�������� push ecx
// push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 >>>>>>>>>>> // call H
Infinitely Recursive Simulation Detected Simulation
Stopped
// actual fully operational code in the x86utm operating >>>>>>>>>>> system u32 H(u32 P, u32 I)
{
HERE:
�� u32 End_Of_Code;
�� u32 Address_of_H;������������� // 2022-06-17
�� u32 code_end����������������� = get_code_end(P);
�� Decoded_Line_Of_Code *decoded =
(Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code)); Registers*
master_state����� = (Registers*)
Allocate(sizeof(Registers)); Registers*� slave_state
= (Registers*) Allocate(sizeof(Registers));
�� u32*������� slave_stack������ = Allocate(0x10000); // >>>>>>>>>>> 64k; u32� execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
�� __asm lea eax, HERE������������ // 2022-06-18
�� __asm sub eax, 6��������������� // 2022-06-18
�� __asm mov Address_of_H, eax���� // 2022-06-18
�� __asm mov eax, END_OF_CODE
�� __asm mov End_Of_Code, eax
�� Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>> �� Init_slave_state(P, I, End_Of_Code, slave_state,
slave_stack);
�� Output("\nBegin Simulation�� Execution Trace Stored >>>>>>>>>>> at:", execution_trace);
�� if (Decide_Halting(&execution_trace, &decoded,
code_end, &master_state,
��������������������� &slave_state, &slave_stack,
Address_of_H, P, I))
������ goto END_OF_CODE;
�� return 0;� // Does not halt
END_OF_CODE:
�� return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can >>>>>>>>>>> easily examine its stored execution_trace of P and
determine: (a) P is calling H with the same arguments
that H was called with.
(b) No instructions in P could possibly escape this
otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is >>>>>>>>>>> invoked.
(b) is NOT a correct rule. Thos has been pointed out
before, and you have ignored it.
Here is an example where P does have instruction that could >>>>>>>>> possibly escape this otherwise infinitely recursive
emulation:
void P(ptr x)
{
static count = 0;
�� count++;
�� if count > 3)
���� return;
�� if (H(x, x))
���� HERE: goto HERE;
�� return;
}
FALLACY of proof by example. I never said that (b) isn't
sometimes true, just it isn't an always true condition. You
fail at elementary logic.
Try and find a valid counter-example. Every attempt at
rebuttal that is not a valid counter-example is one form of
deception or another.
P(P)
That is not any example of (b), thus another mere strawman
deception.
Why not?
all.
Why is P not P?
It is not a direct rebuttal of my original claim.
This would be a direct rebuttal:
You must adapt P so that when H(P,P) emulates its input it
determines that P never reaches its "ret" instruction and the
adapted emulated P still reaches its "ret" instruction.
Unless you find that at least one input where it gets the wrong
answer you have not refuted me.
On Wednesday, June 22, 2022 at 10:13:27 PM UTC-7, olcott wrote:
On 6/22/2022 10:41 PM, Richard Damon wrote:
On 6/22/22 10:55 PM, olcott wrote:It is not a direct rebuttal of my original claim.
On 6/22/2022 9:34 PM, Richard Damon wrote:
On 6/22/22 10:18 PM, olcott wrote:It is not an example of the simulation of the input to H(P,P) at all.
On 6/22/2022 8:45 PM, Richard Damon wrote:
On 6/22/22 9:41 PM, olcott wrote:
On 6/22/2022 8:36 PM, Richard Damon wrote:
On 6/22/22 9:29 PM, olcott wrote:
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it is >>>>>>>>>> an incorrect rule.
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the >>>>>>>>>>>> context of software engineering totally ignoring the context >>>>>>>>>>>> of the halting problem.
First you agree that my words are perfectly correct within >>>>>>>>>>>>>> their specified context
Since you haven't actualy defined you context, and imply that >>>>>>>>>>>>> it is the halting problem, where they can not be correct, >>>>>>>>>>>>> that is not possible.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily >>>>>>>>>>>> verify that the complete and correct x86 emulation of the >>>>>>>>>>>> input to H(P,P) by H would never reach the "ret" instruction >>>>>>>>>>>> of P because both H and P would remain stuck in infinitely >>>>>>>>>>>> recursive emulation.
So, if H actually is a program that does a COMPLETE and correct >>>>>>>>>>> x86 emulation of its input, then YES, as I have said many time >>>>>>>>>>> before, this combination is non-halting.
The fact that you need to keep going back to this, and seem to >>>>>>>>>>> just be refusing to accept the conditions under which you have >>>>>>>>>>> proved it just shows the problems with your thought process. >>>>>>>>>>>
If H does correctly determine that this is the case in a >>>>>>>>>>>> finite number of steps then H could reject its input on this >>>>>>>>>>>> basis. Here are the details of exactly how H does this in a >>>>>>>>>>>> finite number of steps.
Except that NOW H isn't the H we were just talking about, so >>>>>>>>>>> you are just proving that you are either lying or an idiot. >>>>>>>>>>>
Remember, the first analysis had the CONDITION on it that H did >>>>>>>>>>> a COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long >>>>>>>>>>> holds and you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack >>>>>>>>>>>> u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // >>>>>>>>>>>> push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // >>>>>>>>>>>> push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // >>>>>>>>>>>> call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>>
// actual fully operational code in the x86utm operating system >>>>>>>>>>>> u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k; >>>>>>>>>>>> u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack); >>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>> &master_state,
&slave_state, &slave_stack,
Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can >>>>>>>>>>>> easily examine its stored execution_trace of P and determine: >>>>>>>>>>>> (a) P is calling H with the same arguments that H was called >>>>>>>>>>>> with.
(b) No instructions in P could possibly escape this otherwise >>>>>>>>>>>> infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked. >>>>>>>>>>>>
(b) is NOT a correct rule. Thos has been pointed out before, >>>>>>>>>>> and you have ignored it.
Here is an example where P does have instruction that could >>>>>>>>>> possibly escape this otherwise infinitely recursive emulation: >>>>>>>>>>
void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}
FALLACY of proof by example. I never said that (b) isn't
sometimes true, just it isn't an always true condition. You fail >>>>>>>>> at elementary logic.
Try and find a valid counter-example. Every attempt at rebuttal >>>>>>>> that is not a valid counter-example is one form of deception or >>>>>>>> another.
P(P)
That is not any example of (b), thus another mere strawman deception. >>>>>>
Why not?
Why is P not P?
And what exactly was your original claim?
On 6/23/2022 6:55 PM, dklei...@gmail.com wrote:
On Wednesday, June 22, 2022 at 10:13:27 PM UTC-7, olcott wrote:
On 6/22/2022 10:41 PM, Richard Damon wrote:And what exactly was your original claim?
On 6/22/22 10:55 PM, olcott wrote:It is not a direct rebuttal of my original claim.
On 6/22/2022 9:34 PM, Richard Damon wrote:
On 6/22/22 10:18 PM, olcott wrote:It is not an example of the simulation of the input to H(P,P) at all. >>>>>
On 6/22/2022 8:45 PM, Richard Damon wrote:
On 6/22/22 9:41 PM, olcott wrote:
On 6/22/2022 8:36 PM, Richard Damon wrote:
On 6/22/22 9:29 PM, olcott wrote:
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it is >>>>>>>>>>> an incorrect rule.
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the >>>>>>>>>>>>> context of software engineering totally ignoring the context >>>>>>>>>>>>> of the halting problem.
First you agree that my words are perfectly correct within >>>>>>>>>>>>>>> their specified context
Since you haven't actualy defined you context, and imply that >>>>>>>>>>>>>> it is the halting problem, where they can not be correct, >>>>>>>>>>>>>> that is not possible.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp >>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp >>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>> [000010d8](01) 50 push eax >>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>> [000010dc](01) 51 push ecx >>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08 >>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax >>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb >>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9 >>>>>>>>>>>>> [000010eb](01) 5d pop ebp >>>>>>>>>>>>> [000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily >>>>>>>>>>>>> verify that the complete and correct x86 emulation of the >>>>>>>>>>>>> input to H(P,P) by H would never reach the "ret" instruction >>>>>>>>>>>>> of P because both H and P would remain stuck in infinitely >>>>>>>>>>>>> recursive emulation.
So, if H actually is a program that does a COMPLETE and correct >>>>>>>>>>>> x86 emulation of its input, then YES, as I have said many time >>>>>>>>>>>> before, this combination is non-halting.
The fact that you need to keep going back to this, and seem to >>>>>>>>>>>> just be refusing to accept the conditions under which you have >>>>>>>>>>>> proved it just shows the problems with your thought process. >>>>>>>>>>>>
If H does correctly determine that this is the case in a >>>>>>>>>>>>> finite number of steps then H could reject its input on this >>>>>>>>>>>>> basis. Here are the details of exactly how H does this in a >>>>>>>>>>>>> finite number of steps.
Except that NOW H isn't the H we were just talking about, so >>>>>>>>>>>> you are just proving that you are either lying or an idiot. >>>>>>>>>>>>
Remember, the first analysis had the CONDITION on it that H did >>>>>>>>>>>> a COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long >>>>>>>>>>>> holds and you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP >>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp >>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax //
push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx //
push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // >>>>>>>>>>>>> call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>>>
// actual fully operational code in the x86utm operating >>>>>>>>>>>>> system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17 >>>>>>>>>>>>> u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*) >>>>>>>>>>>>> Allocate(sizeof(Registers));
Registers* slave_state = (Registers*) >>>>>>>>>>>>> Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
__asm lea eax, HERE // 2022-06-18 >>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18 >>>>>>>>>>>>> __asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, >>>>>>>>>>>>> slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>>> &master_state,
&slave_state, &slave_stack,
Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can >>>>>>>>>>>>> easily examine its stored execution_trace of P and determine: >>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called >>>>>>>>>>>>> with.
(b) No instructions in P could possibly escape this otherwise >>>>>>>>>>>>> infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is >>>>>>>>>>>>> invoked.
(b) is NOT a correct rule. Thos has been pointed out before, >>>>>>>>>>>> and you have ignored it.
Here is an example where P does have instruction that could >>>>>>>>>>> possibly escape this otherwise infinitely recursive emulation: >>>>>>>>>>>
void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}
FALLACY of proof by example. I never said that (b) isn't
sometimes true, just it isn't an always true condition. You fail >>>>>>>>>> at elementary logic.
Try and find a valid counter-example. Every attempt at rebuttal >>>>>>>>> that is not a valid counter-example is one form of deception or >>>>>>>>> another.
P(P)
That is not any example of (b), thus another mere strawman
deception.
Why not?
Why is P not P?
H is always correct when it determines that an emulated input specifies infinitely nested emulation whenever H matches the (a)(b)(c) criteria to
the behavior of this input.
Obviously a rebuttal would be to find a case where H is incorrect under
these exact same conditions.
On 6/23/22 9:38 PM, olcott wrote:
On 6/23/2022 6:55 PM, dklei...@gmail.com wrote:
On Wednesday, June 22, 2022 at 10:13:27 PM UTC-7, olcott wrote:
On 6/22/2022 10:41 PM, Richard Damon wrote:And what exactly was your original claim?
On 6/22/22 10:55 PM, olcott wrote:It is not a direct rebuttal of my original claim.
On 6/22/2022 9:34 PM, Richard Damon wrote:
On 6/22/22 10:18 PM, olcott wrote:It is not an example of the simulation of the input to H(P,P) at all. >>>>>>
On 6/22/2022 8:45 PM, Richard Damon wrote:
On 6/22/22 9:41 PM, olcott wrote:
On 6/22/2022 8:36 PM, Richard Damon wrote:
On 6/22/22 9:29 PM, olcott wrote:
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it is >>>>>>>>>>>> an incorrect rule.
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the >>>>>>>>>>>>>> context of software engineering totally ignoring the context >>>>>>>>>>>>>> of the halting problem.
First you agree that my words are perfectly correct within >>>>>>>>>>>>>>>> their specified context
Since you haven't actualy defined you context, and imply >>>>>>>>>>>>>>> that
it is the halting problem, where they can not be correct, >>>>>>>>>>>>>>> that is not possible.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp >>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp >>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>> [000010d8](01) 50 push eax >>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>> [000010dc](01) 51 push ecx >>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02 >>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08 >>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax >>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb >>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9 >>>>>>>>>>>>>> [000010eb](01) 5d pop ebp >>>>>>>>>>>>>> [000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily >>>>>>>>>>>>>> verify that the complete and correct x86 emulation of the >>>>>>>>>>>>>> input to H(P,P) by H would never reach the "ret" instruction >>>>>>>>>>>>>> of P because both H and P would remain stuck in infinitely >>>>>>>>>>>>>> recursive emulation.
So, if H actually is a program that does a COMPLETE and >>>>>>>>>>>>> correct
x86 emulation of its input, then YES, as I have said many time >>>>>>>>>>>>> before, this combination is non-halting.
The fact that you need to keep going back to this, and seem to >>>>>>>>>>>>> just be refusing to accept the conditions under which you have >>>>>>>>>>>>> proved it just shows the problems with your thought process. >>>>>>>>>>>>>
If H does correctly determine that this is the case in a >>>>>>>>>>>>>> finite number of steps then H could reject its input on this >>>>>>>>>>>>>> basis. Here are the details of exactly how H does this in a >>>>>>>>>>>>>> finite number of steps.
Except that NOW H isn't the H we were just talking about, so >>>>>>>>>>>>> you are just proving that you are either lying or an idiot. >>>>>>>>>>>>>
Remember, the first analysis had the CONDITION on it that H >>>>>>>>>>>>> did
a COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long >>>>>>>>>>>>> holds and you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP >>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp >>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax //
push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx //
push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // >>>>>>>>>>>>>> call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>>>>
// actual fully operational code in the x86utm operating >>>>>>>>>>>>>> system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17 >>>>>>>>>>>>>> u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*) >>>>>>>>>>>>>> Allocate(sizeof(Registers));
Registers* slave_state = (Registers*) >>>>>>>>>>>>>> Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); //
64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000); >>>>>>>>>>>>>>
__asm lea eax, HERE // 2022-06-18 >>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18 >>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, >>>>>>>>>>>>>> slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>>>> &master_state,
&slave_state, &slave_stack,
Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can >>>>>>>>>>>>>> easily examine its stored execution_trace of P and determine: >>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called >>>>>>>>>>>>>> with.
(b) No instructions in P could possibly escape this otherwise >>>>>>>>>>>>>> infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is >>>>>>>>>>>>>> invoked.
(b) is NOT a correct rule. Thos has been pointed out before, >>>>>>>>>>>>> and you have ignored it.
Here is an example where P does have instruction that could >>>>>>>>>>>> possibly escape this otherwise infinitely recursive emulation: >>>>>>>>>>>>
void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}
FALLACY of proof by example. I never said that (b) isn't >>>>>>>>>>> sometimes true, just it isn't an always true condition. You fail >>>>>>>>>>> at elementary logic.
Try and find a valid counter-example. Every attempt at rebuttal >>>>>>>>>> that is not a valid counter-example is one form of deception or >>>>>>>>>> another.
P(P)
That is not any example of (b), thus another mere strawman
deception.
Why not?
Why is P not P?
H is always correct when it determines that an emulated input
specifies infinitely nested emulation whenever H matches the (a)(b)(c)
criteria to the behavior of this input.
Obviously a rebuttal would be to find a case where H is incorrect
under these exact same conditions.
No, it doesn't, because what it shows is that a mythological machine was correct. The machine described is one that SIMULTANOUSLY does a complete
and correct emulation of its input, while ALSO stopping in finite time
to return the non-halting answer.
On 6/23/2022 8:59 PM, Richard Damon wrote:
On 6/23/22 9:38 PM, olcott wrote:
On 6/23/2022 6:55 PM, dklei...@gmail.com wrote:
On Wednesday, June 22, 2022 at 10:13:27 PM UTC-7, olcott wrote:
On 6/22/2022 10:41 PM, Richard Damon wrote:And what exactly was your original claim?
On 6/22/22 10:55 PM, olcott wrote:It is not a direct rebuttal of my original claim.
On 6/22/2022 9:34 PM, Richard Damon wrote:
On 6/22/22 10:18 PM, olcott wrote:It is not an example of the simulation of the input to H(P,P) at >>>>>>> all.
On 6/22/2022 8:45 PM, Richard Damon wrote:
On 6/22/22 9:41 PM, olcott wrote:
On 6/22/2022 8:36 PM, Richard Damon wrote:
On 6/22/22 9:29 PM, olcott wrote:
On 6/22/2022 8:14 PM, Richard Damon wrote:
On 6/22/22 8:55 PM, olcott wrote:That you don't understand what I mean does not mean that it is >>>>>>>>>>>>> an incorrect rule.
On 6/22/2022 7:48 PM, Richard Damon wrote:
On 6/22/22 8:37 PM, olcott wrote:First you agree that these words are 100% correct within the >>>>>>>>>>>>>>> context of software engineering totally ignoring the context >>>>>>>>>>>>>>> of the halting problem.
First you agree that my words are perfectly correct within >>>>>>>>>>>>>>>>> their specified context
Since you haven't actualy defined you context, and imply >>>>>>>>>>>>>>>> that
it is the halting problem, where they can not be correct, >>>>>>>>>>>>>>>> that is not possible.
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp >>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp >>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>> [000010d8](01) 50 push eax >>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>> [000010dc](01) 51 push ecx >>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02 >>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08 >>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax >>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb >>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9 >>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp >>>>>>>>>>>>>>> [000010ec](01) c3 ret >>>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily >>>>>>>>>>>>>>> verify that the complete and correct x86 emulation of the >>>>>>>>>>>>>>> input to H(P,P) by H would never reach the "ret" instruction >>>>>>>>>>>>>>> of P because both H and P would remain stuck in infinitely >>>>>>>>>>>>>>> recursive emulation.
So, if H actually is a program that does a COMPLETE and >>>>>>>>>>>>>> correct
x86 emulation of its input, then YES, as I have said many >>>>>>>>>>>>>> time
before, this combination is non-halting.
The fact that you need to keep going back to this, and >>>>>>>>>>>>>> seem to
just be refusing to accept the conditions under which you >>>>>>>>>>>>>> have
proved it just shows the problems with your thought process. >>>>>>>>>>>>>>
If H does correctly determine that this is the case in a >>>>>>>>>>>>>>> finite number of steps then H could reject its input on this >>>>>>>>>>>>>>> basis. Here are the details of exactly how H does this in a >>>>>>>>>>>>>>> finite number of steps.
Except that NOW H isn't the H we were just talking about, so >>>>>>>>>>>>>> you are just proving that you are either lying or an idiot. >>>>>>>>>>>>>>
Remember, the first analysis had the CONDITION on it that >>>>>>>>>>>>>> H did
a COMPLETE and correct x86 emulation.
Once you remove that property form H, that conclusion no long >>>>>>>>>>>>>> holds and you are shown to be a lying idiot.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP >>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp >>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax //
push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx //
push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // >>>>>>>>>>>>>>> call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>>>>>
// actual fully operational code in the x86utm operating >>>>>>>>>>>>>>> system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*) >>>>>>>>>>>>>>> Allocate(sizeof(Registers));
Registers* slave_state = (Registers*) >>>>>>>>>>>>>>> Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); //
64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000); >>>>>>>>>>>>>>>
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18 >>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, >>>>>>>>>>>>>>> slave_stack);
Output("\nBegin Simulation Execution Trace Stored >>>>>>>>>>>>>>> at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>>>>> &master_state,
&slave_state, &slave_stack,
Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated >>>>>>>>>>>>>>> }
H knows its own machine address and on this basis it can >>>>>>>>>>>>>>> easily examine its stored execution_trace of P and >>>>>>>>>>>>>>> determine:
(a) P is calling H with the same arguments that H was called >>>>>>>>>>>>>>> with.
(b) No instructions in P could possibly escape this >>>>>>>>>>>>>>> otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is >>>>>>>>>>>>>>> invoked.
(b) is NOT a correct rule. Thos has been pointed out before, >>>>>>>>>>>>>> and you have ignored it.
Here is an example where P does have instruction that could >>>>>>>>>>>>> possibly escape this otherwise infinitely recursive emulation: >>>>>>>>>>>>>
void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}
FALLACY of proof by example. I never said that (b) isn't >>>>>>>>>>>> sometimes true, just it isn't an always true condition. You >>>>>>>>>>>> fail
at elementary logic.
Try and find a valid counter-example. Every attempt at rebuttal >>>>>>>>>>> that is not a valid counter-example is one form of deception or >>>>>>>>>>> another.
P(P)
That is not any example of (b), thus another mere strawman
deception.
Why not?
Why is P not P?
H is always correct when it determines that an emulated input
specifies infinitely nested emulation whenever H matches the
(a)(b)(c) criteria to the behavior of this input.
Obviously a rebuttal would be to find a case where H is incorrect
under these exact same conditions.
No, it doesn't, because what it shows is that a mythological machine
was correct. The machine described is one that SIMULTANOUSLY does a
complete and correct emulation of its input, while ALSO stopping in
finite time to return the non-halting answer.
Because of this reply after I have corrected you hundreds of times I
have blocked you and all of your messages have been erased.
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:He's dry-run P(P) and established that it doesn't halt. He's invoked H on it and H reports that it doesn't halt. He's run P(P) and it halts.
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:I have no idea what parts of this analogy map to the current situation.
Malcolm McLean <malcolm.ar...@gmail.com> writes:I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:There is only one explanation. What you call the "dry-run" is not that >>>> same as the P(P). We've known this since the "line 15 commented out"
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:That is an actual immutable verified fact.
On 6/21/2022 9:52 PM, Richard Damon wrote:You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
Linz and others were aware that: A halt decider must compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H >>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of >>>>>>>> this because no one previously fully examined a simulating halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is wrong.
reports it as non-halting. So it's reasonable to assume that H is correct.
However, when run, P(P) halts. So what are we to conclude? That "the >>>>>>> actual behaviour that is actually specified by the inputs to a simulating
halt decider is not the same as the direct execution of these inputs"? >>>>>>
dry-run P(P), and it doesn't halt. You've run H on P(P), and it
reports "non-halting". You've run P(P), and it halts. So one
explanation is the one you've given but, as I said, that explanation >>>>> has rather far-reaching consequences.
days. There are two computations -- one that is not stopped and one
that is, the "dry-run" and the run, the "simulation of the input to
H(P,P)" and P(P). All PO is doing is trying to find words that hide
what's going on.
The example I always use is that you are doing an energy budget for tigers. >>> You work how much they use on running about, lactating, maintaining their >>> body temperature, and so on.
Now let's say that you find that all results are within a few percentage points
of a similar budget done for lions. You'd instantly accept this data.
Now let's say that the results are wildly different from a previous budget done
for lions. You wouldn't just accept that data. You'd check. You'd want to >>> understand the reasons tigers spend far less energy on movement than lions. >>>
Now let's say that the result show that tigers use more energy than they >>> take in food. Would you instantly conclude that the law of conservation of >>> energy must be incorrect?
The third is what PO is doing.
PO has no contradictory results about anything. There's no conflict
with any established facts in anything he is doing.
So something odd is going on there that needs an explanation.
On 6/24/2022 2:53 AM, Malcolm McLean wrote:
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:He's dry-run P(P) and established that it doesn't halt. He's invoked H
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:I have no idea what parts of this analogy map to the current situation.
Malcolm McLean <malcolm.ar...@gmail.com> writes:I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:There is only one explanation. What you call the "dry-run" is not that >>>>> same as the P(P). We've known this since the "line 15 commented out" >>>>> days. There are two computations -- one that is not stopped and one
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've >>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
On 6/21/2022 9:52 PM, Richard Damon wrote:You've dry-run P(P) and it doesn't halt. Additionally the halt >>>>>>>> decider H
Linz and others were aware that: A halt decider must compute >>>>>>>>> the mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns >>>>>>>>>> 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of >>>>>>>>> the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual
behavior that
is actually specified by the inputs to a simulating halt
decider is not
the same as the direct execution of these inputs. They were
unaware of
this because no one previously fully examined a simulating halt >>>>>>>>> decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H >>>>>>>>>> is wrong.
reports it as non-halting. So it's reasonable to assume that H >>>>>>>> is correct.
However, when run, P(P) halts. So what are we to conclude? That >>>>>>>> "the
actual behaviour that is actually specified by the inputs to a >>>>>>>> simulating
halt decider is not the same as the direct execution of these
inputs"?
That is an actual immutable verified fact.
reports "non-halting". You've run P(P), and it halts. So one
explanation is the one you've given but, as I said, that explanation >>>>>> has rather far-reaching consequences.
that is, the "dry-run" and the run, the "simulation of the input to
H(P,P)" and P(P). All PO is doing is trying to find words that hide
what's going on.
The example I always use is that you are doing an energy budget for
tigers.
You work how much they use on running about, lactating, maintaining
their
body temperature, and so on.
Now let's say that you find that all results are within a few
percentage points
of a similar budget done for lions. You'd instantly accept this data.
Now let's say that the results are wildly different from a previous
budget done
for lions. You wouldn't just accept that data. You'd check. You'd
want to
understand the reasons tigers spend far less energy on movement than
lions.
Now let's say that the result show that tigers use more energy than
they
take in food. Would you instantly conclude that the law of
conservation of
energy must be incorrect?
The third is what PO is doing.
PO has no contradictory results about anything. There's no conflict
with any established facts in anything he is doing.
on it
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
I already fully addressed that in my reply to you yesterday. P(P) has a dependency relationship on the return value of H(P,P) that the correctly emulated input to H(P,P) does not have. This changes their behavior
relative to each other.
On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:
On 6/24/2022 2:53 AM, Malcolm McLean wrote:I can see an alternative explanation. I was going to say "it is obvious" but no-one else has stepped in to point it out. Maybe because it's too obvious and they want to give other posters a chance.
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:I have no idea what parts of this analogy map to the current situation. >>>> PO has no contradictory results about anything. There's no conflict
Malcolm McLean <malcolm.ar...@gmail.com> writes:I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:There is only one explanation. What you call the "dry-run" is not that >>>>>> same as the P(P). We've known this since the "line 15 commented out" >>>>>> days. There are two computations -- one that is not stopped and one >>>>>> that is, the "dry-run" and the run, the "simulation of the input to >>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide >>>>>> what's going on.
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've >>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the halt decider HLinz and others were aware that: A halt decider must compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of
this because no one previously fully examined a simulating halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is wrong.
reports it as non-halting. So it's reasonable to assume that H is correct.
However, when run, P(P) halts. So what are we to conclude? That "the >>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
halt decider is not the same as the direct execution of these inputs"?
That is an actual immutable verified fact.
reports "non-halting". You've run P(P), and it halts. So one
explanation is the one you've given but, as I said, that explanation >>>>>>> has rather far-reaching consequences.
The example I always use is that you are doing an energy budget for tigers.
You work how much they use on running about, lactating, maintaining their >>>>> body temperature, and so on.
Now let's say that you find that all results are within a few percentage points
of a similar budget done for lions. You'd instantly accept this data. >>>>>
Now let's say that the results are wildly different from a previous budget done
for lions. You wouldn't just accept that data. You'd check. You'd want to >>>>> understand the reasons tigers spend far less energy on movement than lions.
Now let's say that the result show that tigers use more energy than they >>>>> take in food. Would you instantly conclude that the law of conservation of
energy must be incorrect?
The third is what PO is doing.
with any established facts in anything he is doing.
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
I already fully addressed that in my reply to you yesterday. P(P) has a
dependency relationship on the return value of H(P,P) that the correctly
emulated input to H(P,P) does not have. This changes their behavior
relative to each other.
On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:
On 6/24/2022 2:53 AM, Malcolm McLean wrote:I can see an alternative explanation. I was going to say "it is obvious" but no-one else has stepped in to point it out. Maybe because it's too obvious and they want to give other posters a chance.
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:I have no idea what parts of this analogy map to the current situation. >>>> PO has no contradictory results about anything. There's no conflict
Malcolm McLean <malcolm.ar...@gmail.com> writes:I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:There is only one explanation. What you call the "dry-run" is not that >>>>>> same as the P(P). We've known this since the "line 15 commented out" >>>>>> days. There are two computations -- one that is not stopped and one >>>>>> that is, the "dry-run" and the run, the "simulation of the input to >>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide >>>>>> what's going on.
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've >>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the halt decider HLinz and others were aware that: A halt decider must compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of
this because no one previously fully examined a simulating halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is wrong.
reports it as non-halting. So it's reasonable to assume that H is correct.
However, when run, P(P) halts. So what are we to conclude? That "the >>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
halt decider is not the same as the direct execution of these inputs"?
That is an actual immutable verified fact.
reports "non-halting". You've run P(P), and it halts. So one
explanation is the one you've given but, as I said, that explanation >>>>>>> has rather far-reaching consequences.
The example I always use is that you are doing an energy budget for tigers.
You work how much they use on running about, lactating, maintaining their >>>>> body temperature, and so on.
Now let's say that you find that all results are within a few percentage points
of a similar budget done for lions. You'd instantly accept this data. >>>>>
Now let's say that the results are wildly different from a previous budget done
for lions. You wouldn't just accept that data. You'd check. You'd want to >>>>> understand the reasons tigers spend far less energy on movement than lions.
Now let's say that the result show that tigers use more energy than they >>>>> take in food. Would you instantly conclude that the law of conservation of
energy must be incorrect?
The third is what PO is doing.
with any established facts in anything he is doing.
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
I already fully addressed that in my reply to you yesterday. P(P) has a
dependency relationship on the return value of H(P,P) that the correctly
emulated input to H(P,P) does not have. This changes their behavior
relative to each other.
On 6/24/2022 8:34 AM, Malcolm McLean wrote:
On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:
On 6/24/2022 2:53 AM, Malcolm McLean wrote:I can see an alternative explanation. I was going to say "it is
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:He's dry-run P(P) and established that it doesn't halt. He's invoked
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:I have no idea what parts of this analogy map to the current
I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:There is only one explanation. What you call the "dry-run" is not >>>>>>> that
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've >>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the halt >>>>>>>>>> decider HLinz and others were aware that: A halt decider must compute >>>>>>>>>>> the mapping
Right, and P(P) reaches the ret instruction of H(P,P)
returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of >>>>>>>>>>> the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual >>>>>>>>>>> behavior that
is actually specified by the inputs to a simulating halt >>>>>>>>>>> decider is not
the same as the direct execution of these inputs. They were >>>>>>>>>>> unaware of
this because no one previously fully examined a simulating >>>>>>>>>>> halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H >>>>>>>>>>>> is wrong.
reports it as non-halting. So it's reasonable to assume that H >>>>>>>>>> is correct.
However, when run, P(P) halts. So what are we to conclude? >>>>>>>>>> That "the
actual behaviour that is actually specified by the inputs to a >>>>>>>>>> simulating
halt decider is not the same as the direct execution of these >>>>>>>>>> inputs"?
That is an actual immutable verified fact.
explanation is the one you've given but, as I said, that
explanation
has rather far-reaching consequences.
same as the P(P). We've known this since the "line 15 commented out" >>>>>>> days. There are two computations -- one that is not stopped and one >>>>>>> that is, the "dry-run" and the run, the "simulation of the input to >>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide >>>>>>> what's going on.
The example I always use is that you are doing an energy budget
for tigers.
You work how much they use on running about, lactating,
maintaining their
body temperature, and so on.
Now let's say that you find that all results are within a few
percentage points
of a similar budget done for lions. You'd instantly accept this data. >>>>>>
Now let's say that the results are wildly different from a
previous budget done
for lions. You wouldn't just accept that data. You'd check. You'd
want to
understand the reasons tigers spend far less energy on movement
than lions.
Now let's say that the result show that tigers use more energy
than they
take in food. Would you instantly conclude that the law of
conservation of
energy must be incorrect?
The third is what PO is doing.
situation.
PO has no contradictory results about anything. There's no conflict
with any established facts in anything he is doing.
H on it
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
I already fully addressed that in my reply to you yesterday. P(P) has a
dependency relationship on the return value of H(P,P) that the correctly >>> emulated input to H(P,P) does not have. This changes their behavior
relative to each other.
obvious" but
no-one else has stepped in to point it out. Maybe because it's too
obvious
and they want to give other posters a chance.
The provably correct execution trace proves that the complete and
correct x86 emulation of the input to H(P,P) by H would never reach the
"ret" instruction (final state) of P, thus never halts. It is also
proven that H does determine this in a finite number of states.
The provably correct execution trace of P(P) proves that the it halts.
Because it is a fact that the actual input to H(P,P) has actual behavior
that never halts then H must report on this behavior and cannot report
on any other behavior.
If you need to verify that you have a white dog in your living room
checking for a black cat in you kitchen is the wrong criteria.
If you need to verify that an input to a halt decider reaches its final
state it must be the actual behavior of this actual input. P(P) is
provably not the actual behavior of the actual input on the basis of the ordinary semantics of the x86 language as shown in the two provably
correct execution traces.
To fully understand this code a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C translates into x86 and the ability to recognize infinite recursion at
the x86 assembly language level. No knowledge of the halting problem is required.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of P.
In computer science terminology this means that complete and correct emulation P by H would never reach its final state and halt.
The dependency relationship that P(P) has on H(P,P) causes its behavior
to be quite different than the complete and correct x86 emulation of the input to H(P,P) that has no such dependency relationship.
As shown below because P(P) depends on the return value of H(P,P) it has different behavior than the correctly emulated input to H(P,P).
The correctly emulated input to H(P,P) remains stuck in recursive
emulation that never gets to the point of receiving a return value from
H, thus lacks the dependency of the executed P(P).
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
P(P);
}
_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]
_main()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) e8d3ffffff call 000011f0
[0000121d](03) 83c404 add esp,+04
[00001220](02) 33c0 xor eax,eax
[00001222](01) 5d pop ebp
[00001223](01) c3 ret
Size in bytes:(0020) [00001223]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [00001210][00101fba][00000000] 55 push ebp [00001211][00101fba][00000000] 8bec mov ebp,esp [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
[000011f1][00101fae][00101fba] 8bec mov ebp,esp [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08] [000011f6][00101faa][000011f0] 50 push eax // push P
[000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08] [000011fa][00101fa6][000011f0] 51 push ecx // push P
[000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
Begin Simulation Execution Trace Stored at:21206e
Address_of_H:1020
[000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
[000011f1][0021205a][0021205e] 8bec mov ebp,esp [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08] [000011f6][00212056][000011f0] 50 push eax // push P
[000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08] [000011fa][00212052][000011f0] 51 push ecx // push P
[000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H Infinitely Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.
[00001200][00101fae][00101fba] 83c408 add esp,+08 // return to executed P
[00001203][00101fae][00101fba] 85c0 test eax,eax [00001205][00101fae][00101fba] 7402 jz 00001209 [00001209][00101fb2][0000121d] 5d pop ebp [0000120a][00101fb6][000011f0] c3 ret // return from
executed P
[0000121d][00101fba][00000000] 83c404 add esp,+04 [00001220][00101fba][00000000] 33c0 xor eax,eax [00001222][00101fbe][00100000] 5d pop ebp [00001223][00101fc2][00000000] c3 ret // ret from main
Number of Instructions Executed(878) / 67 = 13 pages
On 6/24/2022 11:09 AM, Malcolm McLean wrote:
On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:
On 6/24/2022 8:34 AM, Malcolm McLean wrote:I'm a C programmer and I have done machine code programming, though not
On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:To what exact extent do you have this mandatory prerequisite knowledge?
On 6/24/2022 2:53 AM, Malcolm McLean wrote:I can see an alternative explanation. I was going to say "it is
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
He's dry-run P(P) and established that it doesn't halt. He's
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:I have no idea what parts of this analogy map to the current
I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:There is only one explanation. What you call the "dry-run" is >>>>>>>>> not that
That's your conclusion from your observations and reasoning. >>>>>>>>>> You'veOn Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the >>>>>>>>>>>> halt decider HLinz and others were aware that: A halt decider must >>>>>>>>>>>>> compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) >>>>>>>>>>>>>> returns 0, so H
was incorrect in its mapping, since the behavior of P(P) >>>>>>>>>>>>>> is the
DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis >>>>>>>>>>>>> of the actual
behavior that is actually specified by these inputs. >>>>>>>>>>>>> Linz and others made the false assumption that the actual >>>>>>>>>>>>> behavior that
is actually specified by the inputs to a simulating halt >>>>>>>>>>>>> decider is not
the same as the direct execution of these inputs. They were >>>>>>>>>>>>> unaware of
this because no one previously fully examined a simulating >>>>>>>>>>>>> halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template. >>>>>>>>>>>>>>
So, either P isn't built right, or H isn't built fight, or >>>>>>>>>>>>>> H is wrong.
reports it as non-halting. So it's reasonable to assume that >>>>>>>>>>>> H is correct.
However, when run, P(P) halts. So what are we to conclude? >>>>>>>>>>>> That "the
actual behaviour that is actually specified by the inputs to >>>>>>>>>>>> a simulating
halt decider is not the same as the direct execution of >>>>>>>>>>>> these inputs"?
That is an actual immutable verified fact.
dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one >>>>>>>>>> explanation is the one you've given but, as I said, that
explanation
has rather far-reaching consequences.
same as the P(P). We've known this since the "line 15 commented >>>>>>>>> out"
days. There are two computations -- one that is not stopped and >>>>>>>>> one
that is, the "dry-run" and the run, the "simulation of the
input to
H(P,P)" and P(P). All PO is doing is trying to find words that >>>>>>>>> hide
what's going on.
The example I always use is that you are doing an energy budget >>>>>>>> for tigers.
You work how much they use on running about, lactating,
maintaining their
body temperature, and so on.
Now let's say that you find that all results are within a few
percentage points
of a similar budget done for lions. You'd instantly accept this >>>>>>>> data.
Now let's say that the results are wildly different from a
previous budget done
for lions. You wouldn't just accept that data. You'd check.
You'd want to
understand the reasons tigers spend far less energy on movement >>>>>>>> than lions.
Now let's say that the result show that tigers use more energy >>>>>>>> than they
take in food. Would you instantly conclude that the law of
conservation of
energy must be incorrect?
The third is what PO is doing.
situation.
PO has no contradictory results about anything. There's no conflict >>>>>>> with any established facts in anything he is doing.
invoked H on it
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
I already fully addressed that in my reply to you yesterday. P(P)
has a
dependency relationship on the return value of H(P,P) that the
correctly
emulated input to H(P,P) does not have. This changes their behavior
relative to each other.
obvious" but
no-one else has stepped in to point it out. Maybe because it's too
obvious
and they want to give other posters a chance.
To fully understand this code a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and the ability to recognize infinite recursion at
the x86 assembly language level.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does >>> correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of P.
The halt decider and its input are written in C compiled with a
Microsoft C compiler that generates a standard COFF object file. This
file is the input to the x86utm operating system that runs on both
Microsoft Windows and Linux.
with the x86 chip. But I'd dispute your requirements.
THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
DISAGREEMENT IS INHERENTLY INCORRECT.
From a purely software engineering perspective H is correctly defined
to correctly determine that its correct and complete x86 emulation of
its input would never reach the "ret" instruction of this input and it
is proven that H does do this correctly in a finite number of steps.
To re-tread the analogy,
our measurements show that tigers use more energy than they take in.
Now you could construct an very complicated explanation for that using
advanced quantum mechanics and other concepts. And you do need to have
a rudimentary understanding of physics to see where the difficulty lies.
But you don't need more than the rudimentary understanding to suggest the
alternative explanation, and to realise that it is overwhelmingly more
likely.
It seems that you may be saying that it is OK to disbelieve verified
facts some of the time. I vehemently disagree and this position could
cause both the end of Democracy in the USA and the extinction of
humanity in the world through lack of climate change action.
Ordinary software engineering conclusively proves that all of my claims
that I just stated are easily verified as factually correct.
Anyone that disagrees with claims that are verified as factually correct
is either insufficiently technically competent or less than totally
honest. Someone that refuses to acknowledge that claims are correct when
they know that these claims are correct is less than totally honest.
I believe that you are as honest as you can be and the issue is that you
have a lack of sufficient understanding.
On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:
On 6/24/2022 8:34 AM, Malcolm McLean wrote:I'm a C programmer and I have done machine code programming, though not
On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:To what exact extent do you have this mandatory prerequisite knowledge?
On 6/24/2022 2:53 AM, Malcolm McLean wrote:I can see an alternative explanation. I was going to say "it is obvious" but
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:I have no idea what parts of this analogy map to the current situation. >>>>>> PO has no contradictory results about anything. There's no conflict >>>>>> with any established facts in anything he is doing.
I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:There is only one explanation. What you call the "dry-run" is not that >>>>>>>> same as the P(P). We've known this since the "line 15 commented out" >>>>>>>> days. There are two computations -- one that is not stopped and one >>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to >>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide >>>>>>>> what's going on.
That's your conclusion from your observations and reasoning. You've >>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one >>>>>>>>> explanation is the one you've given but, as I said, that explanation >>>>>>>>> has rather far-reaching consequences.On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the halt decider HLinz and others were aware that: A halt decider must compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of
this because no one previously fully examined a simulating halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is wrong.
reports it as non-halting. So it's reasonable to assume that H is correct.
However, when run, P(P) halts. So what are we to conclude? That "the
actual behaviour that is actually specified by the inputs to a simulating
halt decider is not the same as the direct execution of these inputs"?
That is an actual immutable verified fact.
The example I always use is that you are doing an energy budget for tigers.
You work how much they use on running about, lactating, maintaining their
body temperature, and so on.
Now let's say that you find that all results are within a few percentage points
of a similar budget done for lions. You'd instantly accept this data. >>>>>>>
Now let's say that the results are wildly different from a previous budget done
for lions. You wouldn't just accept that data. You'd check. You'd want to
understand the reasons tigers spend far less energy on movement than lions.
Now let's say that the result show that tigers use more energy than they
take in food. Would you instantly conclude that the law of conservation of
energy must be incorrect?
The third is what PO is doing.
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
I already fully addressed that in my reply to you yesterday. P(P) has a >>>> dependency relationship on the return value of H(P,P) that the correctly >>>> emulated input to H(P,P) does not have. This changes their behavior
relative to each other.
no-one else has stepped in to point it out. Maybe because it's too obvious >>> and they want to give other posters a chance.
To fully understand this code a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and the ability to recognize infinite recursion at
the x86 assembly language level.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of P.
The halt decider and its input are written in C compiled with a
Microsoft C compiler that generates a standard COFF object file. This
file is the input to the x86utm operating system that runs on both
Microsoft Windows and Linux.
with the x86 chip. But I'd dispute your requirements.
To re-tread the analogy,
our measurements show that tigers use more energy than they take in.
Now you could construct an very complicated explanation for that using advanced quantum mechanics and other concepts. And you do need to have
a rudimentary understanding of physics to see where the difficulty lies.
But you don't need more than the rudimentary understanding to suggest the alternative explanation, and to realise that it is overwhelmingly more likely.
On 6/24/2022 11:09 AM, Malcolm McLean wrote:
On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:
On 6/24/2022 8:34 AM, Malcolm McLean wrote:I'm a C programmer and I have done machine code programming, though not
On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:To what exact extent do you have this mandatory prerequisite knowledge?
On 6/24/2022 2:53 AM, Malcolm McLean wrote:I can see an alternative explanation. I was going to say "it is
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
He's dry-run P(P) and established that it doesn't halt. He's
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:I have no idea what parts of this analogy map to the current
I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:There is only one explanation. What you call the "dry-run" is >>>>>>>>> not that
That's your conclusion from your observations and reasoning. >>>>>>>>>> You'veOn Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the >>>>>>>>>>>> halt decider HLinz and others were aware that: A halt decider must >>>>>>>>>>>>> compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) >>>>>>>>>>>>>> returns 0, so H
was incorrect in its mapping, since the behavior of P(P) >>>>>>>>>>>>>> is the
DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis >>>>>>>>>>>>> of the actual
behavior that is actually specified by these inputs. >>>>>>>>>>>>> Linz and others made the false assumption that the actual >>>>>>>>>>>>> behavior that
is actually specified by the inputs to a simulating halt >>>>>>>>>>>>> decider is not
the same as the direct execution of these inputs. They were >>>>>>>>>>>>> unaware of
this because no one previously fully examined a simulating >>>>>>>>>>>>> halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template. >>>>>>>>>>>>>>
So, either P isn't built right, or H isn't built fight, or >>>>>>>>>>>>>> H is wrong.
reports it as non-halting. So it's reasonable to assume that >>>>>>>>>>>> H is correct.
However, when run, P(P) halts. So what are we to conclude? >>>>>>>>>>>> That "the
actual behaviour that is actually specified by the inputs to >>>>>>>>>>>> a simulating
halt decider is not the same as the direct execution of >>>>>>>>>>>> these inputs"?
That is an actual immutable verified fact.
dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one >>>>>>>>>> explanation is the one you've given but, as I said, that
explanation
has rather far-reaching consequences.
same as the P(P). We've known this since the "line 15 commented >>>>>>>>> out"
days. There are two computations -- one that is not stopped and >>>>>>>>> one
that is, the "dry-run" and the run, the "simulation of the
input to
H(P,P)" and P(P). All PO is doing is trying to find words that >>>>>>>>> hide
what's going on.
The example I always use is that you are doing an energy budget >>>>>>>> for tigers.
You work how much they use on running about, lactating,
maintaining their
body temperature, and so on.
Now let's say that you find that all results are within a few
percentage points
of a similar budget done for lions. You'd instantly accept this >>>>>>>> data.
Now let's say that the results are wildly different from a
previous budget done
for lions. You wouldn't just accept that data. You'd check.
You'd want to
understand the reasons tigers spend far less energy on movement >>>>>>>> than lions.
Now let's say that the result show that tigers use more energy >>>>>>>> than they
take in food. Would you instantly conclude that the law of
conservation of
energy must be incorrect?
The third is what PO is doing.
situation.
PO has no contradictory results about anything. There's no conflict >>>>>>> with any established facts in anything he is doing.
invoked H on it
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
I already fully addressed that in my reply to you yesterday. P(P)
has a
dependency relationship on the return value of H(P,P) that the
correctly
emulated input to H(P,P) does not have. This changes their behavior
relative to each other.
obvious" but
no-one else has stepped in to point it out. Maybe because it's too
obvious
and they want to give other posters a chance.
To fully understand this code a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and the ability to recognize infinite recursion at
the x86 assembly language level.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does >>> correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of P.
The halt decider and its input are written in C compiled with a
Microsoft C compiler that generates a standard COFF object file. This
file is the input to the x86utm operating system that runs on both
Microsoft Windows and Linux.
with the x86 chip. But I'd dispute your requirements.
THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
DISAGREEMENT IS INHERENTLY INCORRECT.
From a purely software engineering perspective H is correctly defined
to correctly determine that its correct and complete x86 emulation of
its input would never reach the "ret" instruction of this input and it
is proven that H does do this correctly in a finite number of steps.
To re-tread the analogy,
our measurements show that tigers use more energy than they take in.
Now you could construct an very complicated explanation for that using
advanced quantum mechanics and other concepts. And you do need to have
a rudimentary understanding of physics to see where the difficulty lies.
But you don't need more than the rudimentary understanding to suggest the
alternative explanation, and to realise that it is overwhelmingly more
likely.
It seems that you may be saying that it is OK to disbelieve verified
facts some of the time. I vehemently disagree and this position could
cause both the end of Democracy in the USA and the extinction of
humanity in the world through lack of climate change action.
Ordinary software engineering conclusively proves that all of my claims
that I just stated are easily verified as factually correct.
Anyone that disagrees with claims that are verified as factually correct
is either insufficiently technically competent or less than totally
honest. Someone that refuses to acknowledge that claims are correct when
they know that these claims are correct is less than totally honest.
I believe that you are as honest as you can be and the issue is that you
have a lack of sufficient understanding.
On Friday, 24 June 2022 at 17:32:24 UTC+1, olcott wrote:
On 6/24/2022 11:09 AM, Malcolm McLean wrote:Let's say we do our measurements on tigers. They come back
On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
On 6/24/2022 8:34 AM, Malcolm McLean wrote:I'm a C programmer and I have done machine code programming, though not
On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:To what exact extent do you have this mandatory prerequisite knowledge? >>>> To fully understand this code a software engineer must be an expert in: >>>> the C programming language, the x86 programming language, exactly how C >>>> translates into x86 and the ability to recognize infinite recursion at >>>> the x86 assembly language level.
On 6/24/2022 2:53 AM, Malcolm McLean wrote:I can see an alternative explanation. I was going to say "it is obvious" but
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: >>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:I have no idea what parts of this analogy map to the current situation.
I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:There is only one explanation. What you call the "dry-run" is not that
That's your conclusion from your observations and reasoning. You've >>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one >>>>>>>>>>> explanation is the one you've given but, as I said, that explanationOn Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the halt decider HLinz and others were aware that: A halt decider must compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs. >>>>>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of
this because no one previously fully examined a simulating halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template. >>>>>>>>>>>>>>>
So, either P isn't built right, or H isn't built fight, or H is wrong.
reports it as non-halting. So it's reasonable to assume that H is correct.
However, when run, P(P) halts. So what are we to conclude? That "the
actual behaviour that is actually specified by the inputs to a simulating
halt decider is not the same as the direct execution of these inputs"?
That is an actual immutable verified fact.
has rather far-reaching consequences.
same as the P(P). We've known this since the "line 15 commented out" >>>>>>>>>> days. There are two computations -- one that is not stopped and one >>>>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to >>>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide >>>>>>>>>> what's going on.
The example I always use is that you are doing an energy budget for tigers.
You work how much they use on running about, lactating, maintaining their
body temperature, and so on.
Now let's say that you find that all results are within a few percentage points
of a similar budget done for lions. You'd instantly accept this data. >>>>>>>>>
Now let's say that the results are wildly different from a previous budget done
for lions. You wouldn't just accept that data. You'd check. You'd want to
understand the reasons tigers spend far less energy on movement than lions.
Now let's say that the result show that tigers use more energy than they
take in food. Would you instantly conclude that the law of conservation of
energy must be incorrect?
The third is what PO is doing.
PO has no contradictory results about anything. There's no conflict >>>>>>>> with any established facts in anything he is doing.
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
I already fully addressed that in my reply to you yesterday. P(P) has a >>>>>> dependency relationship on the return value of H(P,P) that the correctly >>>>>> emulated input to H(P,P) does not have. This changes their behavior >>>>>> relative to each other.
no-one else has stepped in to point it out. Maybe because it's too obvious
and they want to give other posters a chance.
The ordinary semantics of standard C and the conventional x86 language >>>> are the entire semantics required to conclusively prove that H(P,P) does >>>> correctly determine that its correct and complete x86 emulation of its >>>> input would never reach the "ret" instruction of P.
The halt decider and its input are written in C compiled with a
Microsoft C compiler that generates a standard COFF object file. This
file is the input to the x86utm operating system that runs on both
Microsoft Windows and Linux.
with the x86 chip. But I'd dispute your requirements.
DISAGREEMENT IS INHERENTLY INCORRECT.
From a purely software engineering perspective H is correctly defined
to correctly determine that its correct and complete x86 emulation of
its input would never reach the "ret" instruction of this input and it
is proven that H does do this correctly in a finite number of steps.
To re-tread the analogy,It seems that you may be saying that it is OK to disbelieve verified
our measurements show that tigers use more energy than they take in.
Now you could construct an very complicated explanation for that using
advanced quantum mechanics and other concepts. And you do need to have
a rudimentary understanding of physics to see where the difficulty lies.
But you don't need more than the rudimentary understanding to suggest the >>> alternative explanation, and to realise that it is overwhelmingly more likely.
facts some of the time. I vehemently disagree and this position could
cause both the end of Democracy in the USA and the extinction of
humanity in the world through lack of climate change action.
Ordinary software engineering conclusively proves that all of my claims
that I just stated are easily verified as factually correct.
Anyone that disagrees with claims that are verified as factually correct
is either insufficiently technically competent or less than totally
honest. Someone that refuses to acknowledge that claims are correct when
they know that these claims are correct is less than totally honest.
average calorie intake (prey) 2000 calories.
average outgoings
stored fat 100 calories
metabolism (body temperature) 1500 calories
movement 500 calories
lactation 200 calories.
these are averaged over a long period.
Now what is your conclusion?
See if you can work out the tiger example first.
I believe that you are as honest as you can be and the issue is that you
have a lack of sufficient understanding.
On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote:And because H contains code to abort, and does abort, it does not do a complete emulation.
On 6/22/2022 8:44 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote: >>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and lie about it:
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:I cannot speak for Richard but I have 30+ years C++ experience; I also
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P)
by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>>
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P >>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P >>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>>>>>>
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code)
* 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack); >>>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine: >>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise >>>>>>>>>>>>>>>> infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an >>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state. >>>>>>>>>>>>>>>>
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320) >>>>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427 >>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476 >>>>>>>>>>>>>>> Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software
engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly >>>>>>>>>>>>>> language level. No knowledge of the halting problem is required. >>>>>>>>>>>>>
have C and x86 assembly experience (I once wrote a Zilog Z80A CPU >>>>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
the problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based >>>>>>>>>>>>> omnishambles:
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely recursive emulation.
H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation.
P), would do. And it fails to do that.You just said that H(P,P) cannot correctly predict that the correct and_Infinite_Loop()But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.I never claimed that H(P,P) performs a complete and correct emulation of >>>>>> its input so your rebuttal is the strawman deception.Your entire basis and all of assumptions was incorrect so when I >>>>>>>> provided an infallible one to that cannot possibly be correctly refuted
So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H >>>>>>>>>> would never reach the "ret" instruction of Px because both H and Px >>>>>>>>>> would remain stuck in infinitely recursive emulation.
So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
you simply dodged it. That is a smart move for a dishonest person that >>>>>>>> is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my >>>>>>>> airtight correct reasoning. Another dodge will be construed as a tacit >>>>>>>> admission of defeat.
As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
I claimed that H(P,P) correctly predicts that its complete and correct >>>>>> x86 emulation of its input would never reach the "ret" instruction of P. >>>>>
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning because H
*can't* do a correct and complete emulation of its input, H cannot
possibly determine that _Infinite_Loop() never halts.
Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B
complete x86 emulation of its input would never reach the "ret"
instruction of P without a compete x86 emulation of its input. I just
proved that is a very stupid thing to say.
You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.e. UTM(P,
On 6/24/2022 11:32 AM, olcott wrote:
On 6/24/2022 11:09 AM, Malcolm McLean wrote:
On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:
On 6/24/2022 8:34 AM, Malcolm McLean wrote:I'm a C programmer and I have done machine code programming, though not
On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:To what exact extent do you have this mandatory prerequisite knowledge? >>>> To fully understand this code a software engineer must be an expert in: >>>> the C programming language, the x86 programming language, exactly how C >>>> translates into x86 and the ability to recognize infinite recursion at >>>> the x86 assembly language level.
On 6/24/2022 2:53 AM, Malcolm McLean wrote:I can see an alternative explanation. I was going to say "it is
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: >>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
He's dry-run P(P) and established that it doesn't halt. He's
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:I have no idea what parts of this analogy map to the current
I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:There is only one explanation. What you call the "dry-run" is >>>>>>>>>> not that
That's your conclusion from your observations and reasoning. >>>>>>>>>>> You'veOn Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the >>>>>>>>>>>>> halt decider HLinz and others were aware that: A halt decider must >>>>>>>>>>>>>> compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) >>>>>>>>>>>>>>> returns 0, so H
was incorrect in its mapping, since the behavior of P(P) >>>>>>>>>>>>>>> is the
DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis >>>>>>>>>>>>>> of the actual
behavior that is actually specified by these inputs. >>>>>>>>>>>>>> Linz and others made the false assumption that the actual >>>>>>>>>>>>>> behavior that
is actually specified by the inputs to a simulating halt >>>>>>>>>>>>>> decider is not
the same as the direct execution of these inputs. They >>>>>>>>>>>>>> were unaware of
this because no one previously fully examined a simulating >>>>>>>>>>>>>> halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template. >>>>>>>>>>>>>>>
So, either P isn't built right, or H isn't built fight, >>>>>>>>>>>>>>> or H is wrong.
reports it as non-halting. So it's reasonable to assume >>>>>>>>>>>>> that H is correct.
However, when run, P(P) halts. So what are we to conclude? >>>>>>>>>>>>> That "the
actual behaviour that is actually specified by the inputs >>>>>>>>>>>>> to a simulating
halt decider is not the same as the direct execution of >>>>>>>>>>>>> these inputs"?
That is an actual immutable verified fact.
dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one >>>>>>>>>>> explanation is the one you've given but, as I said, that >>>>>>>>>>> explanation
has rather far-reaching consequences.
same as the P(P). We've known this since the "line 15
commented out"
days. There are two computations -- one that is not stopped >>>>>>>>>> and one
that is, the "dry-run" and the run, the "simulation of the >>>>>>>>>> input to
H(P,P)" and P(P). All PO is doing is trying to find words that >>>>>>>>>> hide
what's going on.
The example I always use is that you are doing an energy budget >>>>>>>>> for tigers.
You work how much they use on running about, lactating,
maintaining their
body temperature, and so on.
Now let's say that you find that all results are within a few >>>>>>>>> percentage points
of a similar budget done for lions. You'd instantly accept this >>>>>>>>> data.
Now let's say that the results are wildly different from a
previous budget done
for lions. You wouldn't just accept that data. You'd check.
You'd want to
understand the reasons tigers spend far less energy on movement >>>>>>>>> than lions.
Now let's say that the result show that tigers use more energy >>>>>>>>> than they
take in food. Would you instantly conclude that the law of
conservation of
energy must be incorrect?
The third is what PO is doing.
situation.
PO has no contradictory results about anything. There's no conflict >>>>>>>> with any established facts in anything he is doing.
invoked H on it
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
I already fully addressed that in my reply to you yesterday. P(P)
has a
dependency relationship on the return value of H(P,P) that the
correctly
emulated input to H(P,P) does not have. This changes their behavior >>>>>> relative to each other.
obvious" but
no-one else has stepped in to point it out. Maybe because it's too
obvious
and they want to give other posters a chance.
The ordinary semantics of standard C and the conventional x86 language >>>> are the entire semantics required to conclusively prove that H(P,P)
does
correctly determine that its correct and complete x86 emulation of its >>>> input would never reach the "ret" instruction of P.
The halt decider and its input are written in C compiled with a
Microsoft C compiler that generates a standard COFF object file. This
file is the input to the x86utm operating system that runs on both
Microsoft Windows and Linux.
with the x86 chip. But I'd dispute your requirements.
THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
DISAGREEMENT IS INHERENTLY INCORRECT.
From a purely software engineering perspective H is correctly defined
to correctly determine that its correct and complete x86 emulation of
its input would never reach the "ret" instruction of this input and it
is proven that H does do this correctly in a finite number of steps.
THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
DISAGREEMENT IS INHERENTLY INCORRECT.
From a purely software engineering perspective H(P,P) is required to
to correctly determine that its correct and complete x86 emulation of
its input would never reach the "ret" instruction of this input and H
must do this in a finite number of steps.
It is proven that H does meet this requirement.
To re-tread the analogy,
our measurements show that tigers use more energy than they take in.
Now you could construct an very complicated explanation for that using
advanced quantum mechanics and other concepts. And you do need to have
a rudimentary understanding of physics to see where the difficulty lies.
But you don't need more than the rudimentary understanding to suggest
the
alternative explanation, and to realise that it is overwhelmingly
more likely.
It seems that you may be saying that it is OK to disbelieve verified
facts some of the time. I vehemently disagree and this position could
cause both the end of Democracy in the USA and the extinction of
humanity in the world through lack of climate change action.
Ordinary software engineering conclusively proves that all of my
claims that I just stated are easily verified as factually correct.
Anyone that disagrees with claims that are verified as factually
correct is either insufficiently technically competent or less than
totally honest. Someone that refuses to acknowledge that claims are
correct when they know that these claims are correct is less than
totally honest.
I believe that you are as honest as you can be and the issue is that
you have a lack of sufficient understanding.
On 6/24/2022 12:29 PM, Malcolm McLean wrote:
On Friday, 24 June 2022 at 17:32:24 UTC+1, olcott wrote:
On 6/24/2022 11:09 AM, Malcolm McLean wrote:Let's say we do our measurements on tigers. They come back
On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
On 6/24/2022 8:34 AM, Malcolm McLean wrote:I'm a C programmer and I have done machine code programming, though not >>>> with the x86 chip. But I'd dispute your requirements.
On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:To what exact extent do you have this mandatory prerequisite
On 6/24/2022 2:53 AM, Malcolm McLean wrote:I can see an alternative explanation. I was going to say "it is
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: >>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
He's dry-run P(P) and established that it doesn't halt. He's
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse >>>>>>>>>> wrote:I have no idea what parts of this analogy map to the current >>>>>>>>> situation.
Malcolm McLean <malcolm.ar...@gmail.com> writes:I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:There is only one explanation. What you call the "dry-run" is >>>>>>>>>>> not that
That's your conclusion from your observations and reasoning. >>>>>>>>>>>> You'veOn Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the >>>>>>>>>>>>>> halt decider HLinz and others were aware that: A halt decider must >>>>>>>>>>>>>>> compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) >>>>>>>>>>>>>>>> returns 0, so H
was incorrect in its mapping, since the behavior of P(P) >>>>>>>>>>>>>>>> is the
DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis >>>>>>>>>>>>>>> of the actual
behavior that is actually specified by these inputs. >>>>>>>>>>>>>>> Linz and others made the false assumption that the actual >>>>>>>>>>>>>>> behavior that
is actually specified by the inputs to a simulating halt >>>>>>>>>>>>>>> decider is not
the same as the direct execution of these inputs. They >>>>>>>>>>>>>>> were unaware of
this because no one previously fully examined a
simulating halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template. >>>>>>>>>>>>>>>>
So, either P isn't built right, or H isn't built fight, >>>>>>>>>>>>>>>> or H is wrong.
reports it as non-halting. So it's reasonable to assume >>>>>>>>>>>>>> that H is correct.
However, when run, P(P) halts. So what are we to conclude? >>>>>>>>>>>>>> That "the
actual behaviour that is actually specified by the inputs >>>>>>>>>>>>>> to a simulating
halt decider is not the same as the direct execution of >>>>>>>>>>>>>> these inputs"?
That is an actual immutable verified fact.
dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one >>>>>>>>>>>> explanation is the one you've given but, as I said, that >>>>>>>>>>>> explanation
has rather far-reaching consequences.
same as the P(P). We've known this since the "line 15
commented out"
days. There are two computations -- one that is not stopped >>>>>>>>>>> and one
that is, the "dry-run" and the run, the "simulation of the >>>>>>>>>>> input to
H(P,P)" and P(P). All PO is doing is trying to find words >>>>>>>>>>> that hide
what's going on.
The example I always use is that you are doing an energy
budget for tigers.
You work how much they use on running about, lactating,
maintaining their
body temperature, and so on.
Now let's say that you find that all results are within a few >>>>>>>>>> percentage points
of a similar budget done for lions. You'd instantly accept >>>>>>>>>> this data.
Now let's say that the results are wildly different from a >>>>>>>>>> previous budget done
for lions. You wouldn't just accept that data. You'd check. >>>>>>>>>> You'd want to
understand the reasons tigers spend far less energy on
movement than lions.
Now let's say that the result show that tigers use more energy >>>>>>>>>> than they
take in food. Would you instantly conclude that the law of >>>>>>>>>> conservation of
energy must be incorrect?
The third is what PO is doing.
PO has no contradictory results about anything. There's no
conflict
with any established facts in anything he is doing.
invoked H on it
and H reports that it doesn't halt. He's run P(P) and it halts. >>>>>>>>
So something odd is going on there that needs an explanation.
I already fully addressed that in my reply to you yesterday. P(P) >>>>>>> has a
dependency relationship on the return value of H(P,P) that the
correctly
emulated input to H(P,P) does not have. This changes their behavior >>>>>>> relative to each other.
obvious" but
no-one else has stepped in to point it out. Maybe because it's too >>>>>> obvious
and they want to give other posters a chance.
knowledge?
To fully understand this code a software engineer must be an expert
in:
the C programming language, the x86 programming language, exactly
how C
translates into x86 and the ability to recognize infinite recursion at >>>>> the x86 assembly language level.
The ordinary semantics of standard C and the conventional x86 language >>>>> are the entire semantics required to conclusively prove that H(P,P)
does
correctly determine that its correct and complete x86 emulation of its >>>>> input would never reach the "ret" instruction of P.
The halt decider and its input are written in C compiled with a
Microsoft C compiler that generates a standard COFF object file. This >>>>> file is the input to the x86utm operating system that runs on both
Microsoft Windows and Linux.
DISAGREEMENT IS INHERENTLY INCORRECT.
From a purely software engineering perspective H is correctly defined
to correctly determine that its correct and complete x86 emulation of
its input would never reach the "ret" instruction of this input and it
is proven that H does do this correctly in a finite number of steps.
To re-tread the analogy,It seems that you may be saying that it is OK to disbelieve verified
our measurements show that tigers use more energy than they take in.
Now you could construct an very complicated explanation for that using >>>> advanced quantum mechanics and other concepts. And you do need to have >>>> a rudimentary understanding of physics to see where the difficulty
lies.
But you don't need more than the rudimentary understanding to
suggest the
alternative explanation, and to realise that it is overwhelmingly
more likely.
facts some of the time. I vehemently disagree and this position could
cause both the end of Democracy in the USA and the extinction of
humanity in the world through lack of climate change action.
Ordinary software engineering conclusively proves that all of my claims
that I just stated are easily verified as factually correct.
Anyone that disagrees with claims that are verified as factually correct >>> is either insufficiently technically competent or less than totally
honest. Someone that refuses to acknowledge that claims are correct when >>> they know that these claims are correct is less than totally honest.
average calorie intake (prey) 2000 calories.
average outgoings
stored fat 100 calories
metabolism (body temperature) 1500 calories
movement 500 calories
lactation 200 calories.
these are averaged over a long period.
Now what is your conclusion?
The measurements are inaccurate as can occur with all empirical science
that relies on physical observation. It is also the case the all
empirical science utterly relies on a possibly false fundamental
assumption that is discussed at length as the problem of induction. https://en.wikipedia.org/wiki/Problem_of_induction
On the other hand when we look at the analytic side of the analytic / synthetic distinction: https://en.wikipedia.org/wiki/Analytic%E2%80%93synthetic_distinction
We can verify that an expression of language is totally true entirely on
the basis of its meaning. This proves that your analogy is not apt.
From a purely software engineering perspective H(P,P) is required to to correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of this input and H must
do this in a finite number of steps.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.
See if you can work out the tiger example first.
I believe that you are as honest as you can be and the issue is that you >>> have a lack of sufficient understanding.
On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:"Dry run" means that a human programmer looks at the code, and determines what it does, without actually executing it.
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:Then I don't know what you mean by "dry-run" and what needs an
Malcolm McLean <malcolm.ar...@gmail.com> writes:He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:I have no idea what parts of this analogy map to the current situation. >>>> PO has no contradictory results about anything. There's no conflict
Malcolm McLean <malcolm.ar...@gmail.com> writes:I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:There is only one explanation. What you call the "dry-run" is not that >>>>>> same as the P(P). We've known this since the "line 15 commented out" >>>>>> days. There are two computations -- one that is not stopped and one >>>>>> that is, the "dry-run" and the run, the "simulation of the input to >>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide >>>>>> what's going on.
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've >>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the halt decider HLinz and others were aware that: A halt decider must compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of
this because no one previously fully examined a simulating halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is wrong.
reports it as non-halting. So it's reasonable to assume that H is correct.
However, when run, P(P) halts. So what are we to conclude? That "the >>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
halt decider is not the same as the direct execution of these inputs"?
That is an actual immutable verified fact.
reports "non-halting". You've run P(P), and it halts. So one
explanation is the one you've given but, as I said, that explanation >>>>>>> has rather far-reaching consequences.
The example I always use is that you are doing an energy budget for tigers.
You work how much they use on running about, lactating, maintaining their >>>>> body temperature, and so on.
Now let's say that you find that all results are within a few percentage points
of a similar budget done for lions. You'd instantly accept this data. >>>>>
Now let's say that the results are wildly different from a previous budget done
for lions. You wouldn't just accept that data. You'd check. You'd want to >>>>> understand the reasons tigers spend far less energy on movement than lions.
Now let's say that the result show that tigers use more energy than they >>>>> take in food. Would you instantly conclude that the law of conservation of
energy must be incorrect?
The third is what PO is doing.
with any established facts in anything he is doing.
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
explanation (for me) is your description of what he's doing. Nothing in
what PO is doing needs to be explained as far as I can see.
It's a very important technique, because it's not always practical or even possible to run a debugger. Even where a debugger is available, often dry-running will reveal bugs in a fraction of the time.
In this case, PO has dry run P(P). That is, he has looked at the source, and worked out what it will do. Which is to run an infinite sequence of nested emulations. So it won't halt. H(P,P) also reports "non-halting". So this is powerful evidence that H is correct.
However when he actually executes P(P) on hardware, it terminates.
Something isn't right.
PO's explanation is that P(P) has different correct behaviour when run and when emulated by H.
I can think of an obvious alternative explanation which is much simpler and much less far-reaching in its implications. However despite a lot of coaxing, no-one else seems to have arrived at it.
On 6/24/2022 3:25 PM, Malcolm McLean wrote:
On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:"Dry run" means that a human programmer looks at the code, and determines
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:Then I don't know what you mean by "dry-run" and what needs an
Malcolm McLean <malcolm.ar...@gmail.com> writes:He's dry-run P(P) and established that it doesn't halt. He's invoked
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:I have no idea what parts of this analogy map to the current
I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:There is only one explanation. What you call the "dry-run" is not >>>>>>> that
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've >>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the halt >>>>>>>>>> decider HLinz and others were aware that: A halt decider must compute >>>>>>>>>>> the mapping
Right, and P(P) reaches the ret instruction of H(P,P)
returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of >>>>>>>>>>> the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual >>>>>>>>>>> behavior that
is actually specified by the inputs to a simulating halt >>>>>>>>>>> decider is not
the same as the direct execution of these inputs. They were >>>>>>>>>>> unaware of
this because no one previously fully examined a simulating >>>>>>>>>>> halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H >>>>>>>>>>>> is wrong.
reports it as non-halting. So it's reasonable to assume that H >>>>>>>>>> is correct.
However, when run, P(P) halts. So what are we to conclude? >>>>>>>>>> That "the
actual behaviour that is actually specified by the inputs to a >>>>>>>>>> simulating
halt decider is not the same as the direct execution of these >>>>>>>>>> inputs"?
That is an actual immutable verified fact.
explanation is the one you've given but, as I said, that
explanation
has rather far-reaching consequences.
same as the P(P). We've known this since the "line 15 commented out" >>>>>>> days. There are two computations -- one that is not stopped and one >>>>>>> that is, the "dry-run" and the run, the "simulation of the input to >>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide >>>>>>> what's going on.
The example I always use is that you are doing an energy budget
for tigers.
You work how much they use on running about, lactating,
maintaining their
body temperature, and so on.
Now let's say that you find that all results are within a few
percentage points
of a similar budget done for lions. You'd instantly accept this data. >>>>>>
Now let's say that the results are wildly different from a
previous budget done
for lions. You wouldn't just accept that data. You'd check. You'd
want to
understand the reasons tigers spend far less energy on movement
than lions.
Now let's say that the result show that tigers use more energy
than they
take in food. Would you instantly conclude that the law of
conservation of
energy must be incorrect?
The third is what PO is doing.
situation.
PO has no contradictory results about anything. There's no conflict
with any established facts in anything he is doing.
H on it
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
explanation (for me) is your description of what he's doing. Nothing in
what PO is doing needs to be explained as far as I can see.
what it does, without actually executing it.
It's a very important technique, because it's not always practical or
even
possible to run a debugger. Even where a debugger is available, often
dry-running will reveal bugs in a fraction of the time.
In this case, PO has dry run P(P). That is, he has looked at the
source, and
worked out what it will do. Which is to run an infinite sequence of
nested
emulations. So it won't halt. H(P,P) also reports "non-halting". So
this is
powerful evidence that H is correct.
Great!
However when he actually executes P(P) on hardware, it terminates.
Something isn't right.
None-the-less when everyone in the entire universe disagrees with a
verified fact then they are all necessarily incorrect.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.
PO's explanation is that P(P) has different correct behaviour when run
and
when emulated by H.
It is very easily proven as an established fact that the correctly
emulated input to H(P,P) would never halt and P(P) halts.
I can think of an obvious alternative explanation which is much
simpler and
much less far-reaching in its implications. However despite a lot of
coaxing,
no-one else seems to have arrived at it.
I think that most of my reviewers are only interested in rebuttal at the expense of an actual honest dialogue. You are certainly the exception to this.
On Friday, June 24, 2022 at 7:52:22 PM UTC+1, olcott wrote:emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
On 6/22/2022 9:23 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote:
On 6/22/2022 8:44 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote: >>>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and lie about it:
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P)
by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>>>>
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp >>>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P >>>>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P >>>>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped >>>>>>>>>>>>>>>>>>
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k; >>>>>>>>>>>>>>>>>> u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) >>>>>>>>>>>>>>>>>> * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated >>>>>>>>>>>>>>>>>> }
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine: >>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state. >>>>>>>>>>>>>>>>>>
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320) >>>>>>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>>>>>>> }
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax >>>>>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427 >>>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476 >>>>>>>>>>>>>>>>> Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp >>>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software
engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly
language level. No knowledge of the halting problem is required.
I cannot speak for Richard but I have 30+ years C++ experience; I also
have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
emulator in 80286 assembly) and I can recognize an infinite recursion;
the problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based
omnishambles:
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely recursive emulation.
H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct
P), would do. And it fails to do that.You just said that H(P,P) cannot correctly predict that the correct and >>>> complete x86 emulation of its input would never reach the "ret"_Infinite_Loop()I never claimed that H(P,P) performs a complete and correct emulation ofYour entire basis and all of assumptions was incorrect so when I >>>>>>>>>> provided an infallible one to that cannot possibly be correctly refuted
So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of Px because both H and Px
would remain stuck in infinitely recursive emulation.
So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
you simply dodged it. That is a smart move for a dishonest person that
is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my >>>>>>>>>> airtight correct reasoning. Another dodge will be construed as a tacit
admission of defeat.
As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
its input so your rebuttal is the strawman deception.
I claimed that H(P,P) correctly predicts that its complete and correct >>>>>>>> x86 emulation of its input would never reach the "ret" instruction of P.
But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f >>>>>> ...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning because H >>>>>> *can't* do a correct and complete emulation of its input, H cannot >>>>>> possibly determine that _Infinite_Loop() never halts.
Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B
instruction of P without a compete x86 emulation of its input. I just
proved that is a very stupid thing to say.
You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.e. UTM(P,
includes emulating the call to H, that this call to H would start emulating the call to P, etc, etc, and so the call to P does not terminate.From a purely software engineering perspective H(P,P) is required to to
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of this input and H must
do this in a finite number of steps.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction.
That you disagree with easily verified software engineering when you
already know that this software engineering is correct speaks loads
about your character.
The only computer science that need be added to this is that the "ret"
instruction is the final state of P and that a sequence of
configurations that cannot possibly reach its final state is a
non-halting sequence.
You say that "H(P,P) is required to to correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction of this input". You seem to be assuming that H does an emulation of P, that this emulation
However, you have said yourself that H does not work like that. You have said "H must do this in a finite number of steps" and have said that H (whose source code you have never actually shown) detects the looping and halts, returning a value.
Thus H does not keep calling P over and over again, or getting deeper and deeper into emulation. It halts. Thus P also halts.
On Friday, 24 June 2022 at 18:42:36 UTC+1, olcott wrote:
On 6/24/2022 12:29 PM, Malcolm McLean wrote:Exactly. You've got it. Either the measurements are inaccurate, or the
On Friday, 24 June 2022 at 17:32:24 UTC+1, olcott wrote:The measurements are inaccurate as can occur with all empirical science
On 6/24/2022 11:09 AM, Malcolm McLean wrote:Let's say we do our measurements on tigers. They come back
On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
On 6/24/2022 8:34 AM, Malcolm McLean wrote:I'm a C programmer and I have done machine code programming, though not >>>>> with the x86 chip. But I'd dispute your requirements.
On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:To what exact extent do you have this mandatory prerequisite knowledge? >>>>>> To fully understand this code a software engineer must be an expert in: >>>>>> the C programming language, the x86 programming language, exactly how C >>>>>> translates into x86 and the ability to recognize infinite recursion at >>>>>> the x86 assembly language level.
On 6/24/2022 2:53 AM, Malcolm McLean wrote:I can see an alternative explanation. I was going to say "it is obvious" but
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: >>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:I already fully addressed that in my reply to you yesterday. P(P) has a
He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:I have no idea what parts of this analogy map to the current situation.
I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:There is only one explanation. What you call the "dry-run" is not that
That's your conclusion from your observations and reasoning. You'veOn Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the halt decider HLinz and others were aware that: A halt decider must compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the
DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs. >>>>>>>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of
this because no one previously fully examined a simulating halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template. >>>>>>>>>>>>>>>>>
So, either P isn't built right, or H isn't built fight, or H is wrong.
reports it as non-halting. So it's reasonable to assume that H is correct.
However, when run, P(P) halts. So what are we to conclude? That "the
actual behaviour that is actually specified by the inputs to a simulating
halt decider is not the same as the direct execution of these inputs"?
That is an actual immutable verified fact.
dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one >>>>>>>>>>>>> explanation is the one you've given but, as I said, that explanation
has rather far-reaching consequences.
same as the P(P). We've known this since the "line 15 commented out"
days. There are two computations -- one that is not stopped and one
that is, the "dry-run" and the run, the "simulation of the input to
H(P,P)" and P(P). All PO is doing is trying to find words that hide
what's going on.
The example I always use is that you are doing an energy budget for tigers.
You work how much they use on running about, lactating, maintaining their
body temperature, and so on.
Now let's say that you find that all results are within a few percentage points
of a similar budget done for lions. You'd instantly accept this data.
Now let's say that the results are wildly different from a previous budget done
for lions. You wouldn't just accept that data. You'd check. You'd want to
understand the reasons tigers spend far less energy on movement than lions.
Now let's say that the result show that tigers use more energy than they
take in food. Would you instantly conclude that the law of conservation of
energy must be incorrect?
The third is what PO is doing.
PO has no contradictory results about anything. There's no conflict >>>>>>>>>> with any established facts in anything he is doing.
and H reports that it doesn't halt. He's run P(P) and it halts. >>>>>>>>>
So something odd is going on there that needs an explanation. >>>>>>>>
dependency relationship on the return value of H(P,P) that the correctly
emulated input to H(P,P) does not have. This changes their behavior >>>>>>>> relative to each other.
no-one else has stepped in to point it out. Maybe because it's too obvious
and they want to give other posters a chance.
The ordinary semantics of standard C and the conventional x86 language >>>>>> are the entire semantics required to conclusively prove that H(P,P) does >>>>>> correctly determine that its correct and complete x86 emulation of its >>>>>> input would never reach the "ret" instruction of P.
The halt decider and its input are written in C compiled with a
Microsoft C compiler that generates a standard COFF object file. This >>>>>> file is the input to the x86utm operating system that runs on both >>>>>> Microsoft Windows and Linux.
DISAGREEMENT IS INHERENTLY INCORRECT.
From a purely software engineering perspective H is correctly defined >>>> to correctly determine that its correct and complete x86 emulation of
its input would never reach the "ret" instruction of this input and it >>>> is proven that H does do this correctly in a finite number of steps.
To re-tread the analogy,It seems that you may be saying that it is OK to disbelieve verified
our measurements show that tigers use more energy than they take in. >>>>> Now you could construct an very complicated explanation for that using >>>>> advanced quantum mechanics and other concepts. And you do need to have >>>>> a rudimentary understanding of physics to see where the difficulty lies. >>>>
But you don't need more than the rudimentary understanding to suggest the >>>>> alternative explanation, and to realise that it is overwhelmingly more likely.
facts some of the time. I vehemently disagree and this position could
cause both the end of Democracy in the USA and the extinction of
humanity in the world through lack of climate change action.
Ordinary software engineering conclusively proves that all of my claims >>>> that I just stated are easily verified as factually correct.
Anyone that disagrees with claims that are verified as factually correct >>>> is either insufficiently technically competent or less than totally
honest. Someone that refuses to acknowledge that claims are correct when >>>> they know that these claims are correct is less than totally honest.
average calorie intake (prey) 2000 calories.
average outgoings
stored fat 100 calories
metabolism (body temperature) 1500 calories
movement 500 calories
lactation 200 calories.
these are averaged over a long period.
Now what is your conclusion?
that relies on physical observation. It is also the case the all
empirical science utterly relies on a possibly false fundamental
assumption that is discussed at length as the problem of induction.
https://en.wikipedia.org/wiki/Problem_of_induction
theory that energy is conserved is wrong.
On the other hand when we look at the analytic side of the analytic /I'm not sure about this.
synthetic distinction:
https://en.wikipedia.org/wiki/Analytic%E2%80%93synthetic_distinction
We can verify that an expression of language is totally true entirely on
the basis of its meaning. This proves that your analogy is not apt.
So you've dry-run P(P) and determined that it doesn't halt. Just as our hypothetical ecologists measured the tigers' energy budget.
From a purely software engineering perspective H(P,P) is required to to
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of this input and H must
do this in a finite number of steps.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.
What is the obvious conclusion?
I believe that you are as honest as you can be and the issue is that you >>>> have a lack of sufficient understanding.See if you can work out the tiger example first.
Paul N <gw7rib@aol.com> writes:
You say that "H(P,P) is required to to correctly determine that its
correct and complete x86 emulation of its input would never reach the
"ret" instruction of this input".
Can I just check that you know this is not what H is supposed to do? PO
has been searching for some from of words that can stir up enough mud
that the fact that H is wrong can be to some extent obscured. He seems
to have hit pay dirt with this latest phrasing.
Everyone seem happy to talk to PO on his own terms (and that's fine --
it's what he posts for), but in the C-function version of the problem,
H(X,Y) != 0 if and only if X(Y) "halts". I lost interest when he
stopped talking about this problem which he knows in not decidable.
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:"Dry run" means that a human programmer looks at the code, and determines
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:Then I don't know what you mean by "dry-run" and what needs an
Malcolm McLean <malcolm.ar...@gmail.com> writes:He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:I have no idea what parts of this analogy map to the current situation. >>>>> PO has no contradictory results about anything. There's no conflict
I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:There is only one explanation. What you call the "dry-run" is not that >>>>>>> same as the P(P). We've known this since the "line 15 commented out" >>>>>>> days. There are two computations -- one that is not stopped and one >>>>>>> that is, the "dry-run" and the run, the "simulation of the input to >>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide >>>>>>> what's going on.
On 6/22/2022 2:55 AM, Malcolm McLean wrote:That's your conclusion from your observations and reasoning. You've >>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the halt decider HLinz and others were aware that: A halt decider must compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of
this because no one previously fully examined a simulating halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H is wrong.
reports it as non-halting. So it's reasonable to assume that H is correct.
However, when run, P(P) halts. So what are we to conclude? That "the >>>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
halt decider is not the same as the direct execution of these inputs"?
That is an actual immutable verified fact.
explanation is the one you've given but, as I said, that explanation >>>>>>>> has rather far-reaching consequences.
The example I always use is that you are doing an energy budget for tigers.
You work how much they use on running about, lactating, maintaining their
body temperature, and so on.
Now let's say that you find that all results are within a few percentage points
of a similar budget done for lions. You'd instantly accept this data. >>>>>>
Now let's say that the results are wildly different from a previous budget done
for lions. You wouldn't just accept that data. You'd check. You'd want to
understand the reasons tigers spend far less energy on movement than lions.
Now let's say that the result show that tigers use more energy than they >>>>>> take in food. Would you instantly conclude that the law of conservation of
energy must be incorrect?
The third is what PO is doing.
with any established facts in anything he is doing.
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
explanation (for me) is your description of what he's doing. Nothing in
what PO is doing needs to be explained as far as I can see.
what it does, without actually executing it.
OK. So what value does it have in this case? Do you think PO is
competent to "dry run" any code at all?
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's invoked H
| on it and H reports that it doesn't halt. He's run P(P) and it halts.
The obvious conclusion is that PO's dry run (if he has indeed done such
a thing) is incorrect. Anyone who eyeballs some case and concludes that
it does not do what it down when actually run has just made a mistake.
Do you think it's interesting to find out what mistake PO has made when guessing what the code does? If so have fun trying to get the code from him...
The more interesting (at least at one time) is fact that H is not
correct since, by definition, H(X,Y) should report on the "halting" of
the call X(Y).
It's a very important technique, because it's not always practical or even >> possible to run a debugger. Even where a debugger is available, often
dry-running will reveal bugs in a fraction of the time.
In this case, we have the undisputed fact that P(P) halts, so there's
really no value in a "dry run" from a debugging perspective.
In this case, PO has dry run P(P).
And, if that is indeed what he's done (and I don't think it is) he knows
he's made some mistake in his "dry run".
That is, he has looked at the source, and
worked out what it will do.
But, I hope you agree, he's made some mistake or he's been lying when re reports that P(P) halts.
Which is to run an infinite sequence of nested
emulations. So it won't halt.
The execution of P(P) does not represent an infinite sequence of nested simulations. We know that because P(P) halts.
H(P,P) also reports "non-halting". So this is
powerful evidence that H is correct.
Eh? How is some code eyeballing more compelling evidence than the 100% undisputed fact that P(P) halts? How is the opinion of someone who
can't write a parity checking TM powerful evidence of anything?
However when he actually executes P(P) on hardware, it terminates.
Something isn't right.
Yes.
PO's explanation is that P(P) has different correct behaviour when run and >> when emulated by H.
That can't be an explanation of anything because, according to you, he
is wrong about the dry run of P(P) and an actual run of P(P). Both the
dry run and the actual run must take account of the fact that H is (partially) emulating P(P).
I can think of an obvious alternative explanation which is much
simpler and much less far-reaching in its implications. However
despite a lot of coaxing, no-one else seems to have arrived at it.
There is nothing here with any far-reaching implications and since I've
never shared your explanation, I'm not going to look for an alternative.
I don't think he's done a "dry run" at all. He knows P(P) halts so he's relying on sophistry. H "aborts" so P never reaches its "ret"
instruction. That's why P(P) and "the simulation of the inputs to
H(P,P)" are different. 18 years of work for what? An H that, on the
basis of his own words, obviously gets the wrong answer.
On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote:
On 6/24/2022 5:16 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:The ordinary semantics of standard C and the conventional x86 language
On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:"Dry run" means that a human programmer looks at the code, and determines >>>> what it does, without actually executing it.
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:Then I don't know what you mean by "dry-run" and what needs an
He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:I have no idea what parts of this analogy map to the current situation. >>>>>>> PO has no contradictory results about anything. There's no conflict >>>>>>> with any established facts in anything he is doing.
I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:There is only one explanation. What you call the "dry-run" is not that
That's your conclusion from your observations and reasoning. You've >>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one >>>>>>>>>> explanation is the one you've given but, as I said, that explanation >>>>>>>>>> has rather far-reaching consequences.On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the halt decider HLinz and others were aware that: A halt decider must compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs. >>>>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of
this because no one previously fully examined a simulating halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template. >>>>>>>>>>>>>>
So, either P isn't built right, or H isn't built fight, or H is wrong.
reports it as non-halting. So it's reasonable to assume that H is correct.
However, when run, P(P) halts. So what are we to conclude? That "the
actual behaviour that is actually specified by the inputs to a simulating
halt decider is not the same as the direct execution of these inputs"?
That is an actual immutable verified fact.
same as the P(P). We've known this since the "line 15 commented out" >>>>>>>>> days. There are two computations -- one that is not stopped and one >>>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to >>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide >>>>>>>>> what's going on.
The example I always use is that you are doing an energy budget for tigers.
You work how much they use on running about, lactating, maintaining their
body temperature, and so on.
Now let's say that you find that all results are within a few percentage points
of a similar budget done for lions. You'd instantly accept this data. >>>>>>>>
Now let's say that the results are wildly different from a previous budget done
for lions. You wouldn't just accept that data. You'd check. You'd want to
understand the reasons tigers spend far less energy on movement than lions.
Now let's say that the result show that tigers use more energy than they
take in food. Would you instantly conclude that the law of conservation of
energy must be incorrect?
The third is what PO is doing.
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
explanation (for me) is your description of what he's doing. Nothing in >>>>> what PO is doing needs to be explained as far as I can see.
OK. So what value does it have in this case? Do you think PO is
competent to "dry run" any code at all?
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's invoked H >>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
The obvious conclusion is that PO's dry run (if he has indeed done such
a thing) is incorrect. Anyone who eyeballs some case and concludes that
it does not do what it down when actually run has just made a mistake.
Do you think it's interesting to find out what mistake PO has made when
guessing what the code does? If so have fun trying to get the code from
him...
The more interesting (at least at one time) is fact that H is not
correct since, by definition, H(X,Y) should report on the "halting" of
the call X(Y).
It's a very important technique, because it's not always practical or even >>>> possible to run a debugger. Even where a debugger is available, often
dry-running will reveal bugs in a fraction of the time.
In this case, we have the undisputed fact that P(P) halts, so there's
really no value in a "dry run" from a debugging perspective.
In this case, PO has dry run P(P).
And, if that is indeed what he's done (and I don't think it is) he knows >>> he's made some mistake in his "dry run".
That is, he has looked at the source, and
worked out what it will do.
But, I hope you agree, he's made some mistake or he's been lying when re >>> reports that P(P) halts.
Which is to run an infinite sequence of nested
emulations. So it won't halt.
The execution of P(P) does not represent an infinite sequence of nested
simulations. We know that because P(P) halts.
H(P,P) also reports "non-halting". So this is
powerful evidence that H is correct.
Eh? How is some code eyeballing more compelling evidence than the 100%
undisputed fact that P(P) halts? How is the opinion of someone who
can't write a parity checking TM powerful evidence of anything?
However when he actually executes P(P) on hardware, it terminates.
Something isn't right.
Yes.
PO's explanation is that P(P) has different correct behaviour when run and >>>> when emulated by H.
That can't be an explanation of anything because, according to you, he
is wrong about the dry run of P(P) and an actual run of P(P). Both the
dry run and the actual run must take account of the fact that H is
(partially) emulating P(P).
I can think of an obvious alternative explanation which is much
simpler and much less far-reaching in its implications. However
despite a lot of coaxing, no-one else seems to have arrived at it.
There is nothing here with any far-reaching implications and since I've
never shared your explanation, I'm not going to look for an alternative. >>>
I don't think he's done a "dry run" at all. He knows P(P) halts so he's
relying on sophistry. H "aborts" so P never reaches its "ret"
instruction. That's why P(P) and "the simulation of the inputs to
H(P,P)" are different. 18 years of work for what? An H that, on the
basis of his own words, obviously gets the wrong answer.
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.
That your understanding of the semantics of the x86 language is
insufficient to directly confirm this is less than no rebuttal at all.
I assume the semantics of C are defined by the 1989 Standard. The
semantics of x86 assembly language are described (not actually authoritatively defined) in other documents. The mapping of C onto
the assembly language is far from unique (every compiler could be
different) PO appears to using a version of Microsoft's C# compiler.
Then we must define how a Turing machine is emulated by a C
program. All that is needed of C is the struct concept and
assignment. In that case using C seems unadvisable.
On 6/24/2022 6:58 PM, dklei...@gmail.com wrote:
On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote:
On 6/24/2022 5:16 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:The ordinary semantics of standard C and the conventional x86 language
On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:"Dry run" means that a human programmer looks at the code, and
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: >>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:Then I don't know what you mean by "dry-run" and what needs an
He's dry-run P(P) and established that it doesn't halt. He's
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:I have no idea what parts of this analogy map to the current
I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:There is only one explanation. What you call the "dry-run" is >>>>>>>>>> not that
That's your conclusion from your observations and reasoning. >>>>>>>>>>> You'veOn Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the >>>>>>>>>>>>> halt decider HLinz and others were aware that: A halt decider must >>>>>>>>>>>>>> compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) >>>>>>>>>>>>>>> returns 0, so H
was incorrect in its mapping, since the behavior of P(P) >>>>>>>>>>>>>>> is the
DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis >>>>>>>>>>>>>> of the actual
behavior that is actually specified by these inputs. >>>>>>>>>>>>>> Linz and others made the false assumption that the actual >>>>>>>>>>>>>> behavior that
is actually specified by the inputs to a simulating halt >>>>>>>>>>>>>> decider is not
the same as the direct execution of these inputs. They >>>>>>>>>>>>>> were unaware of
this because no one previously fully examined a simulating >>>>>>>>>>>>>> halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template. >>>>>>>>>>>>>>>
So, either P isn't built right, or H isn't built fight, >>>>>>>>>>>>>>> or H is wrong.
reports it as non-halting. So it's reasonable to assume >>>>>>>>>>>>> that H is correct.
However, when run, P(P) halts. So what are we to conclude? >>>>>>>>>>>>> That "the
actual behaviour that is actually specified by the inputs >>>>>>>>>>>>> to a simulating
halt decider is not the same as the direct execution of >>>>>>>>>>>>> these inputs"?
That is an actual immutable verified fact.
dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one >>>>>>>>>>> explanation is the one you've given but, as I said, that >>>>>>>>>>> explanation
has rather far-reaching consequences.
same as the P(P). We've known this since the "line 15
commented out"
days. There are two computations -- one that is not stopped >>>>>>>>>> and one
that is, the "dry-run" and the run, the "simulation of the >>>>>>>>>> input to
H(P,P)" and P(P). All PO is doing is trying to find words that >>>>>>>>>> hide
what's going on.
The example I always use is that you are doing an energy budget >>>>>>>>> for tigers.
You work how much they use on running about, lactating,
maintaining their
body temperature, and so on.
Now let's say that you find that all results are within a few >>>>>>>>> percentage points
of a similar budget done for lions. You'd instantly accept this >>>>>>>>> data.
Now let's say that the results are wildly different from a
previous budget done
for lions. You wouldn't just accept that data. You'd check.
You'd want to
understand the reasons tigers spend far less energy on movement >>>>>>>>> than lions.
Now let's say that the result show that tigers use more energy >>>>>>>>> than they
take in food. Would you instantly conclude that the law of
conservation of
energy must be incorrect?
The third is what PO is doing.
situation.
PO has no contradictory results about anything. There's no conflict >>>>>>>> with any established facts in anything he is doing.
invoked H on it
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
explanation (for me) is your description of what he's doing.
Nothing in
what PO is doing needs to be explained as far as I can see.
determines
what it does, without actually executing it.
OK. So what value does it have in this case? Do you think PO is
competent to "dry run" any code at all?
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's
invoked H
| on it and H reports that it doesn't halt. He's run P(P) and it halts. >>>>
The obvious conclusion is that PO's dry run (if he has indeed done such >>>> a thing) is incorrect. Anyone who eyeballs some case and concludes that >>>> it does not do what it down when actually run has just made a mistake. >>>> Do you think it's interesting to find out what mistake PO has made when >>>> guessing what the code does? If so have fun trying to get the code from >>>> him...
The more interesting (at least at one time) is fact that H is not
correct since, by definition, H(X,Y) should report on the "halting" of >>>> the call X(Y).
It's a very important technique, because it's not always practical
or even
possible to run a debugger. Even where a debugger is available, often >>>>> dry-running will reveal bugs in a fraction of the time.
In this case, we have the undisputed fact that P(P) halts, so there's
really no value in a "dry run" from a debugging perspective.
In this case, PO has dry run P(P).
And, if that is indeed what he's done (and I don't think it is) he
knows
he's made some mistake in his "dry run".
That is, he has looked at the source, and
worked out what it will do.
But, I hope you agree, he's made some mistake or he's been lying
when re
reports that P(P) halts.
Which is to run an infinite sequence of nested
emulations. So it won't halt.
The execution of P(P) does not represent an infinite sequence of nested >>>> simulations. We know that because P(P) halts.
H(P,P) also reports "non-halting". So this is
powerful evidence that H is correct.
Eh? How is some code eyeballing more compelling evidence than the 100% >>>> undisputed fact that P(P) halts? How is the opinion of someone who
can't write a parity checking TM powerful evidence of anything?
However when he actually executes P(P) on hardware, it terminates.
Something isn't right.
Yes.
PO's explanation is that P(P) has different correct behaviour when
run and
when emulated by H.
That can't be an explanation of anything because, according to you, he >>>> is wrong about the dry run of P(P) and an actual run of P(P). Both the >>>> dry run and the actual run must take account of the fact that H is
(partially) emulating P(P).
I can think of an obvious alternative explanation which is much
simpler and much less far-reaching in its implications. However
despite a lot of coaxing, no-one else seems to have arrived at it.
There is nothing here with any far-reaching implications and since I've >>>> never shared your explanation, I'm not going to look for an
alternative.
I don't think he's done a "dry run" at all. He knows P(P) halts so he's >>>> relying on sophistry. H "aborts" so P never reaches its "ret"
instruction. That's why P(P) and "the simulation of the inputs to
H(P,P)" are different. 18 years of work for what? An H that, on the
basis of his own words, obviously gets the wrong answer.
are the entire semantics required to conclusively prove that H(P,P) does >>> correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.
That your understanding of the semantics of the x86 language is
insufficient to directly confirm this is less than no rebuttal at all.
I assume the semantics of C are defined by the 1989 Standard. The
semantics of x86 assembly language are described (not actually
authoritatively defined) in other documents. The mapping of C onto
the assembly language is far from unique (every compiler could be
different) PO appears to using a version of Microsoft's C# compiler.
The COFF object file generated by most any Microsoft C compiler.
I used Visual Studio 2017 Community Edition.
x86 Instruction Set Reference: https://c9x.me/x86/
Then we must define how a Turing machine is emulated by a C
program. All that is needed of C is the struct concept and
assignment. In that case using C seems unadvisable.
No we don't need this at all. We only need to know that a C function
that is a pure function of its inputs is Turing equivalent.
https://en.wikipedia.org/wiki/Pure_function
By not using C my five page halt decider becomes hundreds of thousands
of indecipherable pages of TM description.
On 6/24/2022 5:23 PM, Ben Bacarisse wrote:
Paul N <gw7rib@aol.com> writes:
You say that "H(P,P) is required to to correctly determine that its
correct and complete x86 emulation of its input would never reach the
"ret" instruction of this input".
Can I just check that you know this is not what H is supposed to do? PO
has been searching for some from of words that can stir up enough mud
that the fact that H is wrong can be to some extent obscured. He seems
to have hit pay dirt with this latest phrasing.
Everyone seem happy to talk to PO on his own terms (and that's fine --
it's what he posts for), but in the C-function version of the problem,
H(X,Y) != 0 if and only if X(Y) "halts". I lost interest when he
stopped talking about this problem which he knows in not decidable.
It is common knowledge (in computer science) that a halt decider must
compute the mapping from actual its inputs to an accept or reject state
on the basis of the actual behavior that is actually specified by its
actual inputs.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.
THERE IS NO ESCAPE FROM THIS BECAUSE IT IS A TAUTOLOGY.
On Friday, June 24, 2022 at 5:12:57 PM UTC-7, olcott wrote:
On 6/24/2022 6:58 PM, dklei...@gmail.com wrote:
On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote:The COFF object file generated by most any Microsoft C compiler.
On 6/24/2022 5:16 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:The ordinary semantics of standard C and the conventional x86 language >>>> are the entire semantics required to conclusively prove that H(P,P) does >>>> correctly determine that its correct and complete x86 emulation of its >>>> input would never reach the "ret" instruction (final state) of this
On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:"Dry run" means that a human programmer looks at the code, and determines
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote: >>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:Then I don't know what you mean by "dry-run" and what needs an
He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote: >>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:I have no idea what parts of this analogy map to the current situation.
I'm a scientists, not a mathematician.
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote: >>>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:There is only one explanation. What you call the "dry-run" is not that
That's your conclusion from your observations and reasoning. You'veOn Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote: >>>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
You've dry-run P(P) and it doesn't halt. Additionally the halt decider HLinz and others were aware that: A halt decider must compute the mapping
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the
DEFINITION of the behavior of H(P,P),
from its inputs to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs. >>>>>>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of
this because no one previously fully examined a simulating halt decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template. >>>>>>>>>>>>>>>>
So, either P isn't built right, or H isn't built fight, or H is wrong.
reports it as non-halting. So it's reasonable to assume that H is correct.
However, when run, P(P) halts. So what are we to conclude? That "the
actual behaviour that is actually specified by the inputs to a simulating
halt decider is not the same as the direct execution of these inputs"?
That is an actual immutable verified fact.
dry-run P(P), and it doesn't halt. You've run H on P(P), and it >>>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one >>>>>>>>>>>> explanation is the one you've given but, as I said, that explanation
has rather far-reaching consequences.
same as the P(P). We've known this since the "line 15 commented out"
days. There are two computations -- one that is not stopped and one >>>>>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to >>>>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide >>>>>>>>>>> what's going on.
The example I always use is that you are doing an energy budget for tigers.
You work how much they use on running about, lactating, maintaining their
body temperature, and so on.
Now let's say that you find that all results are within a few percentage points
of a similar budget done for lions. You'd instantly accept this data.
Now let's say that the results are wildly different from a previous budget done
for lions. You wouldn't just accept that data. You'd check. You'd want to
understand the reasons tigers spend far less energy on movement than lions.
Now let's say that the result show that tigers use more energy than they
take in food. Would you instantly conclude that the law of conservation of
energy must be incorrect?
The third is what PO is doing.
PO has no contradictory results about anything. There's no conflict >>>>>>>>> with any established facts in anything he is doing.
and H reports that it doesn't halt. He's run P(P) and it halts. >>>>>>>>
So something odd is going on there that needs an explanation.
explanation (for me) is your description of what he's doing. Nothing in >>>>>>> what PO is doing needs to be explained as far as I can see.
what it does, without actually executing it.
OK. So what value does it have in this case? Do you think PO is
competent to "dry run" any code at all?
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's invoked H >>>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts. >>>>>
The obvious conclusion is that PO's dry run (if he has indeed done such >>>>> a thing) is incorrect. Anyone who eyeballs some case and concludes that >>>>> it does not do what it down when actually run has just made a mistake. >>>>> Do you think it's interesting to find out what mistake PO has made when >>>>> guessing what the code does? If so have fun trying to get the code from >>>>> him...
The more interesting (at least at one time) is fact that H is not
correct since, by definition, H(X,Y) should report on the "halting" of >>>>> the call X(Y).
It's a very important technique, because it's not always practical or even
possible to run a debugger. Even where a debugger is available, often >>>>>> dry-running will reveal bugs in a fraction of the time.
In this case, we have the undisputed fact that P(P) halts, so there's >>>>> really no value in a "dry run" from a debugging perspective.
In this case, PO has dry run P(P).
And, if that is indeed what he's done (and I don't think it is) he knows >>>>> he's made some mistake in his "dry run".
That is, he has looked at the source, and
worked out what it will do.
But, I hope you agree, he's made some mistake or he's been lying when re >>>>> reports that P(P) halts.
Which is to run an infinite sequence of nested
emulations. So it won't halt.
The execution of P(P) does not represent an infinite sequence of nested >>>>> simulations. We know that because P(P) halts.
H(P,P) also reports "non-halting". So this is
powerful evidence that H is correct.
Eh? How is some code eyeballing more compelling evidence than the 100% >>>>> undisputed fact that P(P) halts? How is the opinion of someone who
can't write a parity checking TM powerful evidence of anything?
However when he actually executes P(P) on hardware, it terminates. >>>>>> Something isn't right.
Yes.
PO's explanation is that P(P) has different correct behaviour when run and
when emulated by H.
That can't be an explanation of anything because, according to you, he >>>>> is wrong about the dry run of P(P) and an actual run of P(P). Both the >>>>> dry run and the actual run must take account of the fact that H is
(partially) emulating P(P).
I can think of an obvious alternative explanation which is much
simpler and much less far-reaching in its implications. However
despite a lot of coaxing, no-one else seems to have arrived at it.
There is nothing here with any far-reaching implications and since I've >>>>> never shared your explanation, I'm not going to look for an alternative. >>>>>
I don't think he's done a "dry run" at all. He knows P(P) halts so he's >>>>> relying on sophistry. H "aborts" so P never reaches its "ret"
instruction. That's why P(P) and "the simulation of the inputs to
H(P,P)" are different. 18 years of work for what? An H that, on the
basis of his own words, obviously gets the wrong answer.
input thus never halts.
That your understanding of the semantics of the x86 language is
insufficient to directly confirm this is less than no rebuttal at all.
I assume the semantics of C are defined by the 1989 Standard. The
semantics of x86 assembly language are described (not actually
authoritatively defined) in other documents. The mapping of C onto
the assembly language is far from unique (every compiler could be
different) PO appears to using a version of Microsoft's C# compiler.
I used Visual Studio 2017 Community Edition.
x86 Instruction Set Reference: https://c9x.me/x86/
Then we must define how a Turing machine is emulated by a CNo we don't need this at all. We only need to know that a C function
program. All that is needed of C is the struct concept and
assignment. In that case using C seems unadvisable.
that is a pure function of its inputs is Turing equivalent.
https://en.wikipedia.org/wiki/Pure_function
You are jumping too far in one step. What I am asking is equivalent to:
Given a Turing Machine how do its steps map into C and thence into x86?
No C functions are involved.
By not using C my five page halt decider becomes hundreds of thousands
of indecipherable pages of TM description.
That would depend on the answer to my question.
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and determines >>> what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's invoked H
| on it and H reports that it doesn't halt. He's run P(P) and it halts.
The obvious conclusion is that PO's dry run (if he has indeed done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers spend more energy
than they take in. Well potentially this is dynamite. One explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to rule out a much simpler explanation. Which is that our measurements are wrong.
Similarly, PO has worked out what he thinks P(P) should be doing, by dry-running
it, and then actually run P(P) and obtained a different result. He also found that H
agreed with the dry run. It's hard to paraphrase his conclusion, but it is extensive
and far-reaching in its implications. The behaviour of code when run is different
from the correct behaviour of the code when simulated. If that's true, then it has
similar implications for computer science that disproving the conservation law
has for physics.
But the obvious explanation is that the dry-run was incorrect. Lots of people have
suggested why it is incorrect. But they can't actually see the code. PO needs to
understand that no-one will accept the complicated, far-reaching explanation, until the simple explanation has been ruled out.
On Friday, June 24, 2022 at 9:27:27 PM UTC+1, olcott wrote:emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
On 6/24/2022 3:05 PM, Paul N wrote:
On Friday, June 24, 2022 at 7:52:22 PM UTC+1, olcott wrote:
On 6/22/2022 9:23 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote:
On 6/22/2022 8:44 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote: >>>>>>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correctOn Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and lie about it:
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote:
On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02 >>>>>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P)
by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack >>>>>>>>>>>>>>>>>>>> u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp >>>>>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P >>>>>>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P >>>>>>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code)); >>>>>>>>>>>>>>>>>>>> Registers* master_state = (Registers*) >>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k; >>>>>>>>>>>>>>>>>>>> u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) >>>>>>>>>>>>>>>>>>>> * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18 >>>>>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated >>>>>>>>>>>>>>>>>>>> }
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine: >>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
The "ret" instruction of P is its final state. >>>>>>>>>>>>>>>>>>>>
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320) >>>>>>>>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>>>>>>>>> }
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax >>>>>>>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427 >>>>>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476 >>>>>>>>>>>>>>>>>>> Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp >>>>>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret >>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software
engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly
language level. No knowledge of the halting problem is required.
I cannot speak for Richard but I have 30+ years C++ experience; I also
have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
emulator in 80286 assembly) and I can recognize an infinite recursion;
the problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based
omnishambles:
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>
P,P), would do. And it fails to do that.You just said that H(P,P) cannot correctly predict that the correct and >>>>>> complete x86 emulation of its input would never reach the "ret"_Infinite_Loop()I never claimed that H(P,P) performs a complete and correct emulation ofYour entire basis and all of assumptions was incorrect so when I >>>>>>>>>>>> provided an infallible one to that cannot possibly be correctly refutedSo you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of Px because both H and Px
would remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>
you simply dodged it. That is a smart move for a dishonest person that
is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my >>>>>>>>>>>> airtight correct reasoning. Another dodge will be construed as a tacit
admission of defeat.
As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
its input so your rebuttal is the strawman deception.
I claimed that H(P,P) correctly predicts that its complete and correct
x86 emulation of its input would never reach the "ret" instruction of P.
But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f >>>>>>>> ...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning because H >>>>>>>> *can't* do a correct and complete emulation of its input, H cannot >>>>>>>> possibly determine that _Infinite_Loop() never halts.
Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B
instruction of P without a compete x86 emulation of its input. I just >>>>>> proved that is a very stupid thing to say.
You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.e. UTM(
includes emulating the call to H, that this call to H would start emulating the call to P, etc, etc, and so the call to P does not terminate.From a purely software engineering perspective H(P,P) is required to to >>>> correctly determine that its correct and complete x86 emulation of its >>>> input would never reach the "ret" instruction of this input and H must >>>> do this in a finite number of steps.
The ordinary semantics of standard C and the conventional x86 language >>>> are the entire semantics required to conclusively prove that H(P,P) does >>>> correctly determine that its correct and complete x86 emulation of its >>>> input would never reach the "ret" instruction.
That you disagree with easily verified software engineering when you
already know that this software engineering is correct speaks loads
about your character.
The only computer science that need be added to this is that the "ret" >>>> instruction is the final state of P and that a sequence of
configurations that cannot possibly reach its final state is a
non-halting sequence.
You say that "H(P,P) is required to to correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction of this input". You seem to be assuming that H does an emulation of P, that this emulation
Thanks for continuing to review this.
No assumptions two years of software development derived fully
operational software that conclusively proves this.
It might help people's understanding if we had a few more examples. Suppose, in addition to the normal P and H, we have two more functions as follows:
void Q(void)
{
if (H(P, P))
H2: goto H2;
return;
}
void R(void)
{
H(P, P);
return;
}
Will Q return? Will R return?
On 6/24/2022 11:01 PM, Malcolm McLean wrote:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and
determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's invoked H >>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
The obvious conclusion is that PO's dry run (if he has indeed done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers spend
more energy
than they take in. Well potentially this is dynamite. One explanation
is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to rule out a
much
simpler explanation. Which is that our measurements are wrong.
Similarly, PO has worked out what he thinks P(P) should be doing, by
dry-running
it, and then actually run P(P) and obtained a different result. He
also found that H
agreed with the dry run. It's hard to paraphrase his conclusion, but
it is extensive
and far-reaching in its implications. The behaviour of code when run
is different
from the correct behaviour of the code when simulated. If that's true,
then it has
similar implications for computer science that disproving the
conservation law
has for physics.
But the obvious explanation is that the dry-run was incorrect. Lots of
people have
suggested why it is incorrect. But they can't actually see the code.
PO needs to
understand that no-one will accept the complicated, far-reaching
explanation,
until the simple explanation has been ruled out.
I already proved that the dry run is correct.
On 6/25/2022 6:56 AM, Paul N wrote:
On Friday, June 24, 2022 at 9:27:27 PM UTC+1, olcott wrote:
On 6/24/2022 3:05 PM, Paul N wrote:
On Friday, June 24, 2022 at 7:52:22 PM UTC+1, olcott wrote:Thanks for continuing to review this.
On 6/22/2022 9:23 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote:From a purely software engineering perspective H(P,P) is
On 6/22/2022 8:44 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcottYou just said that H(P,P) cannot correctly predict that the
wrote:
On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott_Infinite_Loop()
wrote:
On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott >>>>>>>>>>> wrote:I never claimed that H(P,P) performs a complete and
On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott >>>>>>>>>>>>> wrote:Your entire basis and all of assumptions was incorrect >>>>>>>>>>>> so when I provided an infallible one to that cannot
On 6/22/2022 4:53 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, >>>>>>>>>>>>>>> olcott wrote:
On 6/22/2022 4:20 PM, Mr Flibble wrote:
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is >>>>>>>>>>>>>>>> true and lie about it: Every sufficiently competent >>>>>>>>>>>>>>>> software engineer can easily verify that the >>>>>>>>>>>>>>>> complete and correct x86 emulation of the input to >>>>>>>>>>>>>>>> H(Px,Px) by H would never reach the "ret"
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02 >>>>>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer >>>>>>>>>>>>>>>>>>>> can easily verify that the complete and correct >>>>>>>>>>>>>>>>>>>> x86 emulation of the input to H(P,P) by H would >>>>>>>>>>>>>>>>>>>> never reach the "ret" instruction of P because >>>>>>>>>>>>>>>>>>>> both H and P would remain stuck in infinitely >>>>>>>>>>>>>>>>>>>> recursive emulation.
If H does correctly determine that this is the >>>>>>>>>>>>>>>>>>>> case in a finite number of steps then H could >>>>>>>>>>>>>>>>>>>> reject its input on this basis. Here are the >>>>>>>>>>>>>>>>>>>> details of exactly how H does this in a finite >>>>>>>>>>>>>>>>>>>> number of steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack >>>>>>>>>>>>>>>>>>>> u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly >>>>>>>>>>>>>>>>>>>> address address data code language
======== ======== ======== ========= >>>>>>>>>>>>>>>>>>>> ============= [000010d2][00211e8a][00211e8e] 55 >>>>>>>>>>>>>>>>>>>> push ebp [000010d3][00211e8a][00211e8e] 8bec mov >>>>>>>>>>>>>>>>>>>> ebp,esp [000010d5][00211e8a][00211e8e] 8b4508 >>>>>>>>>>>>>>>>>>>> mov eax,[ebp+08] [000010d8][00211e86][000010d2] >>>>>>>>>>>>>>>>>>>> 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov >>>>>>>>>>>>>>>>>>>> ecx,[ebp+08] [000010dc][00211e82][000010d2] 51 >>>>>>>>>>>>>>>>>>>> push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call >>>>>>>>>>>>>>>>>>>> 00000f02 // call H Infinitely Recursive >>>>>>>>>>>>>>>>>>>> Simulation Detected Simulation Stopped >>>>>>>>>>>>>>>>>>>>
// actual fully operational code in the x86utm >>>>>>>>>>>>>>>>>>>> operating system u32 H(u32 P, u32 I) >>>>>>>>>>>>>>>>>>>> {
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded =
(Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code)); >>>>>>>>>>>>>>>>>>>> Registers* master_state = (Registers*) >>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers)); Registers* >>>>>>>>>>>>>>>>>>>> slave_state = (Registers*)
Allocate(sizeof(Registers)); u32* slave_stack = >>>>>>>>>>>>>>>>>>>> Allocate(0x10000); // 64k; u32 execution_trace = >>>>>>>>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code) >>>>>>>>>>>>>>>>>>>> * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18 >>>>>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // >>>>>>>>>>>>>>>>>>>> 2022-06-11 Init_slave_state(P, I, End_Of_Code, >>>>>>>>>>>>>>>>>>>> slave_state, slave_stack); Output("\nBegin >>>>>>>>>>>>>>>>>>>> Simulation Execution Trace Stored at:", >>>>>>>>>>>>>>>>>>>> execution_trace); if
(Decide_Halting(&execution_trace, &decoded, >>>>>>>>>>>>>>>>>>>> code_end, &master_state, &slave_state, >>>>>>>>>>>>>>>>>>>> &slave_stack, Address_of_H, P, I)) goto >>>>>>>>>>>>>>>>>>>> END_OF_CODE; return 0; // Does not halt >>>>>>>>>>>>>>>>>>>> END_OF_CODE: return 1; // Input has normally >>>>>>>>>>>>>>>>>>>> terminated }
H knows its own machine address and on this >>>>>>>>>>>>>>>>>>>> basis it can easily examine its stored >>>>>>>>>>>>>>>>>>>> execution_trace of P and determine: (a) P is >>>>>>>>>>>>>>>>>>>> calling H with the same arguments that H was >>>>>>>>>>>>>>>>>>>> called with. (b) No instructions in P could >>>>>>>>>>>>>>>>>>>> possibly escape this otherwise infinitely >>>>>>>>>>>>>>>>>>>> recursive emulation. (c) H aborts its emulation >>>>>>>>>>>>>>>>>>>> of P before its call to H is invoked. >>>>>>>>>>>>>>>>>>>>
Technically competent software engineers may not >>>>>>>>>>>>>>>>>>>> know this computer science:
A halt decider must compute the mapping from its >>>>>>>>>>>>>>>>>>>> inputs to an accept or reject state on the basis >>>>>>>>>>>>>>>>>>>> of the actual behavior that is actually >>>>>>>>>>>>>>>>>>>> specified by these inputs.
computation that halts … the Turing machine will >>>>>>>>>>>>>>>>>>>> halt whenever it enters a final state. >>>>>>>>>>>>>>>>>>>> (Linz:1990:234)
The "ret" instruction of P is its final state. >>>>>>>>>>>>>>>>>>>>
Linz, Peter 1990. An Introduction to Formal >>>>>>>>>>>>>>>>>>>> Languages and Automata. Lexington/Toronto: D. C. >>>>>>>>>>>>>>>>>>>> Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>>>>>>>>> }
...[000013e8][00102357][00000000] 83c408 add >>>>>>>>>>>>>>>>>>> esp,+08 ...[000013eb][00102353][00000000] 50 push >>>>>>>>>>>>>>>>>>> eax ...[000013ec][0010234f][00000427] 6827040000 >>>>>>>>>>>>>>>>>>> push 00000427 ---[000013f1][0010234f][00000427] >>>>>>>>>>>>>>>>>>> e880f0ffff call 00000476 Input_Halts = 0 >>>>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add >>>>>>>>>>>>>>>>>>> esp,+08 ...[000013f9][00102357][00000000] 33c0 >>>>>>>>>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d >>>>>>>>>>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3 ret >>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120) >>>>>>>>>>>>>>>>>>>
It gets the answer wrong, i.e. input has not been >>>>>>>>>>>>>>>>>>> decided correctly. QED.
/Flibble
You and Richard are insufficiently technically >>>>>>>>>>>>>>>>>> competent at software engineering not meeting >>>>>>>>>>>>>>>>>> these specs:
A software engineer must be an expert in: the C >>>>>>>>>>>>>>>>>> programming language, the x86 programming >>>>>>>>>>>>>>>>>> language, exactly how C translates into x86 and >>>>>>>>>>>>>>>>>> the ability to recognize infinite recursion at the >>>>>>>>>>>>>>>>>> x86 assembly language level. No knowledge of the >>>>>>>>>>>>>>>>>> halting problem is required.
I cannot speak for Richard but I have 30+ years C++ >>>>>>>>>>>>>>>>> experience; I also have C and x86 assembly >>>>>>>>>>>>>>>>> experience (I once wrote a Zilog Z80A CPU emulator >>>>>>>>>>>>>>>>> in 80286 assembly) and I can recognize an infinite >>>>>>>>>>>>>>>>> recursion; the problem is that you cannot recognize >>>>>>>>>>>>>>>>> the fact that the infinite recursion only manifests >>>>>>>>>>>>>>>>> as part of your invalid simulation-based
omnishambles:
instruction of P because both H and P would remain >>>>>>>>>>>>>>>> stuck in infinitely recursive emulation.
H (if it was constructed correctly) is a computation, >>>>>>>>>>>>>>> and a computation *always* gives the same output for >>>>>>>>>>>>>>> a given input. So it doesn't make sense to say what >>>>>>>>>>>>>>> it "would" do. It either does or does not perform a >>>>>>>>>>>>>>> complete and correct emulation. And because H
contains code to abort, and does abort, it does not >>>>>>>>>>>>>>> do a complete emulation.
So the input must be given to a UTM, which by
definition does a correct and complete simulation, to >>>>>>>>>>>>>>> see what the actual behavior is. UTM(Px,Px) halts, >>>>>>>>>>>>>>> therefore H(Px,Px)==0 is wrong.
Every sufficiently competent software engineer can >>>>>>>>>>>>>> easily verify that the complete and correct x86
emulation of the input to H(Px,Px) by H would never >>>>>>>>>>>>>> reach the "ret" instruction of Px because both H and >>>>>>>>>>>>>> Px would remain stuck in infinitely recursive
emulation.
So you just repeated what you said instead of
explaining why I'm wrong. In other words you provided >>>>>>>>>>>>> no rebuttal, which can only be taken to mean that you >>>>>>>>>>>>> have none.
possibly be correctly refuted you simply dodged it. That >>>>>>>>>>>> is a smart move for a dishonest person that is only
interested in rebuttal.
I dare you to go back to the prior post and find any >>>>>>>>>>>> error in my airtight correct reasoning. Another dodge >>>>>>>>>>>> will be construed as a tacit admission of defeat.
As stated before H (or more accurately Ha) does not
perform a complete and correct emulation because it
aborts. So by definition it cannot be complete.
correct emulation of its input so your rebuttal is the
strawman deception.
I claimed that H(P,P) correctly predicts that its complete >>>>>>>>>> and correct x86 emulation of its input would never reach >>>>>>>>>> the "ret" instruction of P.
But since H, or more accurately Ha, *can't* do a correct
and complete emulation of its input, your point is moot.
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace Stored
at:211e8f ...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning
because H *can't* do a correct and complete emulation of its >>>>>>>> input, H cannot possibly determine that _Infinite_Loop()
never halts.
Now who's using the strawman error? Just because H can
determine that _Infinite_Loop does not halt doesn't mean that
it gets other cases right. B
correct and complete x86 emulation of its input would never
reach the "ret" instruction of P without a compete x86
emulation of its input. I just proved that is a very stupid
thing to say.
You said that H can predict what *its* correct and complete
emulation would do, and I said that doesn't make sense because
H does not do correct and complete emulation. What H *must* do
is predict what *the* correct and complete emulation, i.e.
UTM(P,P), would do. And it fails to do that.
required to to correctly determine that its correct and complete
x86 emulation of its input would never reach the "ret"
instruction of this input and H must do this in a finite number
of steps.
The ordinary semantics of standard C and the conventional x86
language are the entire semantics required to conclusively prove
that H(P,P) does correctly determine that its correct and
complete x86 emulation of its input would never reach the "ret"
instruction.
That you disagree with easily verified software engineering when
you already know that this software engineering is correct
speaks loads about your character.
The only computer science that need be added to this is that the
"ret" instruction is the final state of P and that a sequence of
configurations that cannot possibly reach its final state is a
non-halting sequence.
You say that "H(P,P) is required to to correctly determine that
its correct and complete x86 emulation of its input would never
reach the "ret" instruction of this input". You seem to be
assuming that H does an emulation of P, that this emulation
includes emulating the call to H, that this call to H would start
emulating the call to P, etc, etc, and so the call to P does not
terminate.
No assumptions two years of software development derived fully
operational software that conclusively proves this.
It might help people's understanding if we had a few more examples. Suppose, in addition to the normal P and H, we have two more
functions as follows:
void Q(void)
{
if (H(P, P))
H2: goto H2;
return;
}
void R(void)
{
H(P, P);
return;
}
Will Q return? Will R return?
Yes they both return.
void Q(void)
{
if (H(P, P))
H2: goto H2;
return;
}
void R(void)
{
H(P, P);
return;
}
_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]
_Q()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) 68f0110000 push 000011f0
[0000121d](05) e8fefdffff call 00001020
[00001222](03) 83c408 add esp,+08
[00001225](02) 85c0 test eax,eax
[00001227](02) 7402 jz 0000122b
[00001229](02) ebfe jmp 00001229
[0000122b](01) 5d pop ebp
[0000122c](01) c3 ret
Size in bytes:(0029) [0000122c]
_main()
[00001250](01) 55 push ebp
[00001251](02) 8bec mov ebp,esp
[00001253](05) e8b8ffffff call 00001210
[00001258](02) 33c0 xor eax,eax
[0000125a](01) 5d pop ebp
[0000125b](01) c3 ret
Size in bytes:(0012) [0000125b]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= ...[00001250][00102048][00000000] 55 push ebp ...[00001251][00102048][00000000] 8bec mov ebp,esp ...[00001253][00102044][00001258] e8b8ffffff call 00001210 ...[00001210][00102040][00102048] 55 push ebp ...[00001211][00102040][00102048] 8bec mov ebp,esp ...[00001213][0010203c][000011f0] 68f0110000 push 000011f0 ...[00001218][00102038][000011f0] 68f0110000 push 000011f0 ...[0000121d][00102034][00001222] e8fefdffff call 00001020
Begin Simulation Execution Trace Stored at:2120fc
Address_of_H:1020
...[000011f0][002120e8][002120ec] 55 push ebp ...[000011f1][002120e8][002120ec] 8bec mov ebp,esp ...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08] ...[000011f6][002120e4][000011f0] 50 push eax ...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08] ...[000011fa][002120e0][000011f0] 51 push ecx ...[000011fb][002120dc][00001200] e820feffff call 00001020
Infinitely Recursive Simulation Detected Simulation Stopped
...[00001222][00102040][00102048] 83c408 add esp,+08 ...[00001225][00102040][00102048] 85c0 test eax,eax ...[00001227][00102040][00102048] 7402 jz 0000122b ...[0000122b][00102044][00001258] 5d pop ebp ...[0000122c][00102048][00000000] c3 ret ...[00001258][00102048][00000000] 33c0 xor eax,eax ...[0000125a][0010204c][00100000] 5d pop ebp ...[0000125b][00102050][00000000] c3 ret
Number of Instructions Executed(874)
Above is:
int main()
{
Q();
//R();
}
---
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= ...[00001250][00102048][00000000] 55 push ebp ...[00001251][00102048][00000000] 8bec mov ebp,esp ...[00001253][00102044][00001258] e8d8ffffff call 00001230 ...[00001230][00102040][00102048] 55 push ebp ...[00001231][00102040][00102048] 8bec mov ebp,esp ...[00001233][0010203c][000011f0] 68f0110000 push 000011f0 ...[00001238][00102038][000011f0] 68f0110000 push 000011f0 ...[0000123d][00102034][00001242] e8defdffff call 00001020
Begin Simulation Execution Trace Stored at:2120fc
Address_of_H:1020
...[000011f0][002120e8][002120ec] 55 push ebp ...[000011f1][002120e8][002120ec] 8bec mov ebp,esp ...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08] ...[000011f6][002120e4][000011f0] 50 push eax ...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08] ...[000011fa][002120e0][000011f0] 51 push ecx ...[000011fb][002120dc][00001200] e820feffff call 00001020
Infinitely Recursive Simulation Detected Simulation Stopped
...[00001242][00102040][00102048] 83c408 add esp,+08 ...[00001245][00102044][00001258] 5d pop ebp ...[00001246][00102048][00000000] c3 ret ...[00001258][00102048][00000000] 33c0 xor eax,eax ...[0000125a][0010204c][00100000] 5d pop ebp ...[0000125b][00102050][00000000] c3 ret
Number of Instructions Executed(872)
Above is:
int main()
{
//Q();
R();
}
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
On 6/25/2022 12:09 AM, Malcolm McLean wrote:Sorry no. I've been programming since I was a boy and I have a PhD in a computational-
On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:It seems that you simply lack the technical competence.
On 6/24/2022 11:01 PM, Malcolm McLean wrote:Someone reports that tigers use more energy than they take in, and concludes that
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's invoked H >>>>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts. >>>>>> The obvious conclusion is that PO's dry run (if he has indeed done such >>>>>> a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers spend more energy
than they take in. Well potentially this is dynamite. One explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to rule out a much
simpler explanation. Which is that our measurements are wrong.
Similarly, PO has worked out what he thinks P(P) should be doing, by dry-running
it, and then actually run P(P) and obtained a different result. He also found that H
agreed with the dry run. It's hard to paraphrase his conclusion, but it is extensive
and far-reaching in its implications. The behaviour of code when run is different
from the correct behaviour of the code when simulated. If that's true, then it has
similar implications for computer science that disproving the conservation law
has for physics.
But the obvious explanation is that the dry-run was incorrect. Lots of people have
suggested why it is incorrect. But they can't actually see the code. PO needs to
understand that no-one will accept the complicated, far-reaching explanation,
until the simple explanation has been ruled out.
I already proved that the dry run is correct.
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some mistake. How were your
measurements taken? Show us your calculations, maybe you've got your sums wrong."
Now if they are also uncooperative about sharing the details of the investigation,
those reservations will be magnified. There can be legitimate reasons. Tigers are
rare and need to be conserved, you can't let anyone who wants have access to the
tigers to try to repeat the measurements. But there's also a common illegitimate
reason put forwards by people who make extraordinary claims. If the claims were
unexceptional, such as that tigers have a similar energy budget to lions, then no-one
would be saying "Show me your notebooks. How do you know that calorimeter was
calibrated accurately? What's the name of the person who took that measurement
and can I interview them?" Extraordinary claims are put through the wringer in a way
that ordinary ones are not. I've seen complaints about this from parapsychologists.
But if you're going to claim to have discovered a new physical principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest explanations for its behaviour.
Go back and look at my proof again.
related subject. I'm confident of my technical abilities. What I can't do of course
is tell you exactly what is going on in code I cannot see. I've got a pretty good idea,
but I can only reconstruct on the basis of what you tell me. Ben thinks that I've
got it wrong and in fact there are no nested emulations at all. I've no way of actually
disproving that idea without seeing H.
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
On 6/25/2022 12:09 AM, Malcolm McLean wrote:Sorry no. I've been programming since I was a boy and I have a PhD in
On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:It seems that you simply lack the technical competence.
On 6/24/2022 11:01 PM, Malcolm McLean wrote:Someone reports that tigers use more energy than they take in, and
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and >>>>>>>> determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's
invoked H
| on it and H reports that it doesn't halt. He's run P(P) and it >>>>>>> halts.
The obvious conclusion is that PO's dry run (if he has indeed
done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers
spend more energy
than they take in. Well potentially this is dynamite. One
explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to rule
out a much
simpler explanation. Which is that our measurements are wrong.
Similarly, PO has worked out what he thinks P(P) should be doing,
by dry-running
it, and then actually run P(P) and obtained a different result. He >>>>>> also found that H
agreed with the dry run. It's hard to paraphrase his conclusion,
but it is extensive
and far-reaching in its implications. The behaviour of code when
run is different
from the correct behaviour of the code when simulated. If that's
true, then it has
similar implications for computer science that disproving the
conservation law
has for physics.
But the obvious explanation is that the dry-run was incorrect.
Lots of people have
suggested why it is incorrect. But they can't actually see the
code. PO needs to
understand that no-one will accept the complicated, far-reaching
explanation,
until the simple explanation has been ruled out.
I already proved that the dry run is correct.
concludes that
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some mistake. How
were your
measurements taken? Show us your calculations, maybe you've got your
sums wrong."
Now if they are also uncooperative about sharing the details of the
investigation,
those reservations will be magnified. There can be legitimate
reasons. Tigers are
rare and need to be conserved, you can't let anyone who wants have
access to the
tigers to try to repeat the measurements. But there's also a common
illegitimate
reason put forwards by people who make extraordinary claims. If the
claims were
unexceptional, such as that tigers have a similar energy budget to
lions, then no-one
would be saying "Show me your notebooks. How do you know that
calorimeter was
calibrated accurately? What's the name of the person who took that
measurement
and can I interview them?" Extraordinary claims are put through the
wringer in a way
that ordinary ones are not. I've seen complaints about this from
parapsychologists.
But if you're going to claim to have discovered a new physical
principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest explanations for
its behaviour.
Go back and look at my proof again.
a computational-
related subject. I'm confident of my technical abilities. What I can't
do of course
is tell you exactly what is going on in code I cannot see. I've got a
pretty good idea,
but I can only reconstruct on the basis of what you tell me. Ben
thinks that I've
got it wrong and in fact there are no nested emulations at all. I've
no way of actually
disproving that idea without seeing H.
To fully understand this a software engineer must be an expert in:
(a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86 assembly
language level.
Anyone having the above credentials can validate my work, if you cannot validate my work then you do not sufficiently have the above credentials.
Exactly how C translates into x86 is mandatory. If you don't know how
the C calling conventions are implemented in x86 you cannot validate my
work.
From a purely software engineering perspective H(P,P) is required to to correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of this input and H must
do this in a finite number of steps.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.
The correct and complete x86 emulation of its input by H(P,P) would
never reach the "ret" instruction of P because both H and P would remain stuck in infinitely nested emulation.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01) 55 push ebp
[00001203](02) 8bec mov ebp,esp
[00001205](03) 8b4508 mov eax,[ebp+08]
[00001208](01) 50 push eax
[00001209](03) 8b4d08 mov ecx,[ebp+08]
[0000120c](01) 51 push ecx
[0000120d](05) e820feffff call 00001032
[00001212](03) 83c408 add esp,+08
[00001215](02) 85c0 test eax,eax
[00001217](02) 7402 jz 0000121b
[00001219](02) ebfe jmp 00001219
[0000121b](01) 5d pop ebp
[0000121c](01) c3 ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01) 55 push ebp
[00001223](02) 8bec mov ebp,esp
[00001225](05) 6802120000 push 00001202
[0000122a](05) 6802120000 push 00001202
[0000122f](05) e8fefdffff call 00001032
[00001234](03) 83c408 add esp,+08
[00001237](01) 50 push eax
[00001238](05) 68b3030000 push 000003b3
[0000123d](05) e8c0f1ffff call 00000402
[00001242](03) 83c408 add esp,+08
[00001245](02) 33c0 xor eax,eax
[00001247](01) 5d pop ebp
[00001248](01) c3 ret
Size in bytes:(0039) [00001248]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [00001222][0010200f][00000000] 55 push ebp [00001223][0010200f][00000000] 8bec mov ebp,esp [00001225][0010200b][00001202] 6802120000 push 00001202 // push P [0000122a][00102007][00001202] 6802120000 push 00001202 // push P [0000122f][00102003][00001234] e8fefdffff call 00001032 // call executed H
Begin Simulation Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55 push ebp [00001203][002120af][002120b3] 8bec mov ebp,esp [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08] [00001208][002120ab][00001202] 50 push eax // push P
[00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08] [0000120c][002120a7][00001202] 51 push ecx // push P
[0000120d][002120a3][00001212] e820feffff call 00001032 // call emulated H Infinitely Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.
[00001234][0010200f][00000000] 83c408 add esp,+08 [00001237][0010200b][00000000] 50 push eax [00001238][00102007][000003b3] 68b3030000 push 000003b3 [0000123d][00102007][000003b3] e8c0f1ffff call 00000402
Input_Halts = 0
[00001242][0010200f][00000000] 83c408 add esp,+08 [00001245][0010200f][00000000] 33c0 xor eax,eax [00001247][00102013][00100000] 5d pop ebp [00001248][00102017][00000004] c3 ret
Number of Instructions Executed(870) / 67 = 13 pages
On 6/25/2022 9:28 AM, olcott wrote:
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
On 6/25/2022 12:09 AM, Malcolm McLean wrote:Sorry no. I've been programming since I was a boy and I have a PhD
On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:It seems that you simply lack the technical competence.
On 6/24/2022 11:01 PM, Malcolm McLean wrote:Someone reports that tigers use more energy than they take in,
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code,
and determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt.
He's invoked H
| on it and H reports that it doesn't halt. He's run P(P) and
it halts.
The obvious conclusion is that PO's dry run (if he has indeed >>>>>>> done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers
spend more energy
than they take in. Well potentially this is dynamite. One
explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to
rule out a much
simpler explanation. Which is that our measurements are wrong.
Similarly, PO has worked out what he thinks P(P) should be
doing, by dry-running
it, and then actually run P(P) and obtained a different
result. He also found that H
agreed with the dry run. It's hard to paraphrase his
conclusion, but it is extensive
and far-reaching in its implications. The behaviour of code
when run is different
from the correct behaviour of the code when simulated. If
that's true, then it has
similar implications for computer science that disproving the
conservation law
has for physics.
But the obvious explanation is that the dry-run was incorrect.
Lots of people have
suggested why it is incorrect. But they can't actually see the
code. PO needs to
understand that no-one will accept the complicated,
far-reaching explanation,
until the simple explanation has been ruled out.
I already proved that the dry run is correct.
and concludes that
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some mistake.
How were your
measurements taken? Show us your calculations, maybe you've got
your sums wrong."
Now if they are also uncooperative about sharing the details of
the investigation,
those reservations will be magnified. There can be legitimate
reasons. Tigers are
rare and need to be conserved, you can't let anyone who wants
have access to the
tigers to try to repeat the measurements. But there's also a
common illegitimate
reason put forwards by people who make extraordinary claims. If
the claims were
unexceptional, such as that tigers have a similar energy budget
to lions, then no-one
would be saying "Show me your notebooks. How do you know that
calorimeter was
calibrated accurately? What's the name of the person who took
that measurement
and can I interview them?" Extraordinary claims are put through
the wringer in a way
that ordinary ones are not. I've seen complaints about this from
parapsychologists.
But if you're going to claim to have discovered a new physical
principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest explanations
for its behaviour.
Go back and look at my proof again.
in a computational-
related subject. I'm confident of my technical abilities. What I
can't do of course
is tell you exactly what is going on in code I cannot see. I've
got a pretty good idea,
but I can only reconstruct on the basis of what you tell me. Ben
thinks that I've
got it wrong and in fact there are no nested emulations at all.
I've no way of actually
disproving that idea without seeing H.
To fully understand this a software engineer must be an expert in:
(a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86 assembly language level.
Anyone having the above credentials can validate my work, if you
cannot validate my work then you do not sufficiently have the above credentials.
Exactly how C translates into x86 is mandatory. If you don't know
how the C calling conventions are implemented in x86 you cannot
validate my work.
From a purely software engineering perspective H(P,P) is required
to to correctly determine that its correct and complete x86
emulation of its input would never reach the "ret" instruction of
this input and H must do this in a finite number of steps.
The ordinary semantics of standard C and the conventional x86
language are the entire semantics required to conclusively prove
that H(P,P) does correctly determine that its correct and complete
x86 emulation of its input would never reach the "ret" instruction
(final state) of this input thus never halts.
The correct and complete x86 emulation of its input by H(P,P) would
never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely nested emulation.
void P(u32 x)
{
� if (H(x, x))
��� HERE: goto HERE;
� return;
}
int main()
{
� Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01)� 55������������� push ebp
[00001203](02)� 8bec����������� mov ebp,esp
[00001205](03)� 8b4508��������� mov eax,[ebp+08]
[00001208](01)� 50������������� push eax
[00001209](03)� 8b4d08��������� mov ecx,[ebp+08]
[0000120c](01)� 51������������� push ecx
[0000120d](05)� e820feffff����� call 00001032
[00001212](03)� 83c408��������� add esp,+08
[00001215](02)� 85c0����������� test eax,eax
[00001217](02)� 7402����������� jz 0000121b
[00001219](02)� ebfe����������� jmp 00001219
[0000121b](01)� 5d������������� pop ebp
[0000121c](01)� c3������������� ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01)� 55������������� push ebp
[00001223](02)� 8bec����������� mov ebp,esp
[00001225](05)� 6802120000����� push 00001202
[0000122a](05)� 6802120000����� push 00001202
[0000122f](05)� e8fefdffff����� call 00001032
[00001234](03)� 83c408��������� add esp,+08
[00001237](01)� 50������������� push eax
[00001238](05)� 68b3030000����� push 000003b3
[0000123d](05)� e8c0f1ffff����� call 00000402
[00001242](03)� 83c408��������� add esp,+08
[00001245](02)� 33c0����������� xor eax,eax
[00001247](01)� 5d������������� pop ebp
[00001248](01)� c3������������� ret
Size in bytes:(0039) [00001248]
�machine�� stack���� stack���� machine��� assembly
�address�� address�� data����� code������ language
�========� ========� ========� =========� ============= [00001222][0010200f][00000000] 55�������� push ebp [00001223][0010200f][00000000] 8bec������ mov ebp,esp [00001225][0010200b][00001202] 6802120000 push 00001202 // push P [0000122a][00102007][00001202] 6802120000 push 00001202 // push P [0000122f][00102003][00001234] e8fefdffff call 00001032 // call
executed H
Begin Simulation�� Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55�������� push ebp [00001203][002120af][002120b3] 8bec������ mov ebp,esp [00001205][002120af][002120b3] 8b4508���� mov eax,[ebp+08] [00001208][002120ab][00001202] 50�������� push eax����� // push P [00001209][002120ab][00001202] 8b4d08���� mov ecx,[ebp+08] [0000120c][002120a7][00001202] 51�������� push ecx����� // push P [0000120d][002120a3][00001212] e820feffff call 00001032 // call
emulated H Infinitely Recursive Simulation Detected Simulation
Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.
When you know that H simply implements the above algorithm there is
no need to see its source code. I am reserving the publication of the
5 pages of the source code of the halt decider for journal
publication.
On Sat, 25 Jun 2022 10:19:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:09 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:03:17 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:28 AM, olcott wrote:
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
On 6/25/2022 12:09 AM, Malcolm McLean wrote:Sorry no. I've been programming since I was a boy and I have a
On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:It seems that you simply lack the technical competence.
On 6/24/2022 11:01 PM, Malcolm McLean wrote:Someone reports that tigers use more energy than they take in, >>>>>>>> and concludes that
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, >>>>>>>>>>>> and determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved: >>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt. >>>>>>>>>>> He's invoked H
| on it and H reports that it doesn't halt. He's run P(P) >>>>>>>>>>> and it halts.
The obvious conclusion is that PO's dry run (if he has
indeed done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that
tigers spend more energy
than they take in. Well potentially this is dynamite. One
explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to >>>>>>>>>> rule out a much
simpler explanation. Which is that our measurements are
wrong.
Similarly, PO has worked out what he thinks P(P) should be >>>>>>>>>> doing, by dry-running
it, and then actually run P(P) and obtained a different
result. He also found that H
agreed with the dry run. It's hard to paraphrase his
conclusion, but it is extensive
and far-reaching in its implications. The behaviour of code >>>>>>>>>> when run is different
from the correct behaviour of the code when simulated. If
that's true, then it has
similar implications for computer science that disproving the >>>>>>>>>> conservation law
has for physics.
But the obvious explanation is that the dry-run was
incorrect. Lots of people have
suggested why it is incorrect. But they can't actually see >>>>>>>>>> the code. PO needs to
understand that no-one will accept the complicated,
far-reaching explanation,
until the simple explanation has been ruled out.
I already proved that the dry run is correct.
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some
mistake. How were your
measurements taken? Show us your calculations, maybe you've got >>>>>>>> your sums wrong."
Now if they are also uncooperative about sharing the details of >>>>>>>> the investigation,
those reservations will be magnified. There can be legitimate
reasons. Tigers are
rare and need to be conserved, you can't let anyone who wants
have access to the
tigers to try to repeat the measurements. But there's also a
common illegitimate
reason put forwards by people who make extraordinary claims. If >>>>>>>> the claims were
unexceptional, such as that tigers have a similar energy budget >>>>>>>> to lions, then no-one
would be saying "Show me your notebooks. How do you know that
calorimeter was
calibrated accurately? What's the name of the person who took
that measurement
and can I interview them?" Extraordinary claims are put through >>>>>>>> the wringer in a way
that ordinary ones are not. I've seen complaints about this
from parapsychologists.
But if you're going to claim to have discovered a new physical >>>>>>>> principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest explanations >>>>>>>> for its behaviour.
Go back and look at my proof again.
PhD in a computational-
related subject. I'm confident of my technical abilities. What I
can't do of course
is tell you exactly what is going on in code I cannot see. I've
got a pretty good idea,
but I can only reconstruct on the basis of what you tell me. Ben
thinks that I've
got it wrong and in fact there are no nested emulations at all.
I've no way of actually
disproving that idea without seeing H.
To fully understand this a software engineer must be an expert in:
(a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86
assembly language level.
Anyone having the above credentials can validate my work, if you
cannot validate my work then you do not sufficiently have the
above credentials.
Exactly how C translates into x86 is mandatory. If you don't know
how the C calling conventions are implemented in x86 you cannot
validate my work.
From a purely software engineering perspective H(P,P) is
required to to correctly determine that its correct and complete
x86 emulation of its input would never reach the "ret"
instruction of this input and H must do this in a finite number
of steps.
The ordinary semantics of standard C and the conventional x86
language are the entire semantics required to conclusively prove
that H(P,P) does correctly determine that its correct and complete
x86 emulation of its input would never reach the "ret" instruction
(final state) of this input thus never halts.
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely nested emulation.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01) 55 push ebp
[00001203](02) 8bec mov ebp,esp
[00001205](03) 8b4508 mov eax,[ebp+08]
[00001208](01) 50 push eax
[00001209](03) 8b4d08 mov ecx,[ebp+08]
[0000120c](01) 51 push ecx
[0000120d](05) e820feffff call 00001032
[00001212](03) 83c408 add esp,+08
[00001215](02) 85c0 test eax,eax
[00001217](02) 7402 jz 0000121b
[00001219](02) ebfe jmp 00001219
[0000121b](01) 5d pop ebp
[0000121c](01) c3 ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01) 55 push ebp
[00001223](02) 8bec mov ebp,esp
[00001225](05) 6802120000 push 00001202
[0000122a](05) 6802120000 push 00001202
[0000122f](05) e8fefdffff call 00001032
[00001234](03) 83c408 add esp,+08
[00001237](01) 50 push eax
[00001238](05) 68b3030000 push 000003b3
[0000123d](05) e8c0f1ffff call 00000402
[00001242](03) 83c408 add esp,+08
[00001245](02) 33c0 xor eax,eax
[00001247](01) 5d pop ebp
[00001248](01) c3 ret
Size in bytes:(0039) [00001248]
machine stack stack machine assembly
address address data code language >>>>> ======== ======== ======== ========= =============
[00001222][0010200f][00000000] 55 push ebp
[00001223][0010200f][00000000] 8bec mov ebp,esp
[00001225][0010200b][00001202] 6802120000 push 00001202 // push P
[0000122a][00102007][00001202] 6802120000 push 00001202 // push P
[0000122f][00102003][00001234] e8fefdffff call 00001032 // call
executed H
Begin Simulation Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55 push ebp
[00001203][002120af][002120b3] 8bec mov ebp,esp
[00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
[00001208][002120ab][00001202] 50 push eax // push P
[00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
[0000120c][002120a7][00001202] 51 push ecx // push P
[0000120d][002120a3][00001212] e820feffff call 00001032 // call
emulated H Infinitely Recursive Simulation Detected Simulation
Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.
When you know that H simply implements the above algorithm there is
no need to see its source code. I am reserving the publication of
the 5 pages of the source code of the halt decider for journal
publication.
Your H is not a pure function as it behaves differently depending on
what is invoking it (it returns a decision answer to main() but not
to P()) and it has side effects (aborting a simulation).
/Flibble
Finally a critique that has a reasonable basis.
When I transformed H into a pure function of its inputs it always has
the same behavior no matter how it is invoked.
The x86 emulation of P is aborted before P invokes H.
Nope. Preventing a call to H is equivalent to H behaving differently
for same inputs. Aborting a simulation is a side effect: pure functions
do not have side effects.
/Flibble
On Sat, 25 Jun 2022 10:03:17 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:28 AM, olcott wrote:
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
On 6/25/2022 12:09 AM, Malcolm McLean wrote:Sorry no. I've been programming since I was a boy and I have a PhD
On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:It seems that you simply lack the technical competence.
On 6/24/2022 11:01 PM, Malcolm McLean wrote:Someone reports that tigers use more energy than they take in,
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, >>>>>>>>>> and determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt.
He's invoked H
| on it and H reports that it doesn't halt. He's run P(P) and >>>>>>>>> it halts.
The obvious conclusion is that PO's dry run (if he has indeed >>>>>>>>> done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers >>>>>>>> spend more energy
than they take in. Well potentially this is dynamite. One
explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to
rule out a much
simpler explanation. Which is that our measurements are wrong. >>>>>>>>
Similarly, PO has worked out what he thinks P(P) should be
doing, by dry-running
it, and then actually run P(P) and obtained a different
result. He also found that H
agreed with the dry run. It's hard to paraphrase his
conclusion, but it is extensive
and far-reaching in its implications. The behaviour of code
when run is different
from the correct behaviour of the code when simulated. If
that's true, then it has
similar implications for computer science that disproving the
conservation law
has for physics.
But the obvious explanation is that the dry-run was incorrect. >>>>>>>> Lots of people have
suggested why it is incorrect. But they can't actually see the >>>>>>>> code. PO needs to
understand that no-one will accept the complicated,
far-reaching explanation,
until the simple explanation has been ruled out.
I already proved that the dry run is correct.
and concludes that
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some mistake.
How were your
measurements taken? Show us your calculations, maybe you've got
your sums wrong."
Now if they are also uncooperative about sharing the details of
the investigation,
those reservations will be magnified. There can be legitimate
reasons. Tigers are
rare and need to be conserved, you can't let anyone who wants
have access to the
tigers to try to repeat the measurements. But there's also a
common illegitimate
reason put forwards by people who make extraordinary claims. If
the claims were
unexceptional, such as that tigers have a similar energy budget
to lions, then no-one
would be saying "Show me your notebooks. How do you know that
calorimeter was
calibrated accurately? What's the name of the person who took
that measurement
and can I interview them?" Extraordinary claims are put through
the wringer in a way
that ordinary ones are not. I've seen complaints about this from
parapsychologists.
But if you're going to claim to have discovered a new physical
principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest explanations
for its behaviour.
Go back and look at my proof again.
in a computational-
related subject. I'm confident of my technical abilities. What I
can't do of course
is tell you exactly what is going on in code I cannot see. I've
got a pretty good idea,
but I can only reconstruct on the basis of what you tell me. Ben
thinks that I've
got it wrong and in fact there are no nested emulations at all.
I've no way of actually
disproving that idea without seeing H.
To fully understand this a software engineer must be an expert in:
(a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86 assembly
language level.
Anyone having the above credentials can validate my work, if you
cannot validate my work then you do not sufficiently have the above
credentials.
Exactly how C translates into x86 is mandatory. If you don't know
how the C calling conventions are implemented in x86 you cannot
validate my work.
From a purely software engineering perspective H(P,P) is required
to to correctly determine that its correct and complete x86
emulation of its input would never reach the "ret" instruction of
this input and H must do this in a finite number of steps.
The ordinary semantics of standard C and the conventional x86
language are the entire semantics required to conclusively prove
that H(P,P) does correctly determine that its correct and complete
x86 emulation of its input would never reach the "ret" instruction
(final state) of this input thus never halts.
The correct and complete x86 emulation of its input by H(P,P) would
never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely nested emulation.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01) 55 push ebp
[00001203](02) 8bec mov ebp,esp
[00001205](03) 8b4508 mov eax,[ebp+08]
[00001208](01) 50 push eax
[00001209](03) 8b4d08 mov ecx,[ebp+08]
[0000120c](01) 51 push ecx
[0000120d](05) e820feffff call 00001032
[00001212](03) 83c408 add esp,+08
[00001215](02) 85c0 test eax,eax
[00001217](02) 7402 jz 0000121b
[00001219](02) ebfe jmp 00001219
[0000121b](01) 5d pop ebp
[0000121c](01) c3 ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01) 55 push ebp
[00001223](02) 8bec mov ebp,esp
[00001225](05) 6802120000 push 00001202
[0000122a](05) 6802120000 push 00001202
[0000122f](05) e8fefdffff call 00001032
[00001234](03) 83c408 add esp,+08
[00001237](01) 50 push eax
[00001238](05) 68b3030000 push 000003b3
[0000123d](05) e8c0f1ffff call 00000402
[00001242](03) 83c408 add esp,+08
[00001245](02) 33c0 xor eax,eax
[00001247](01) 5d pop ebp
[00001248](01) c3 ret
Size in bytes:(0039) [00001248]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001222][0010200f][00000000] 55 push ebp
[00001223][0010200f][00000000] 8bec mov ebp,esp
[00001225][0010200b][00001202] 6802120000 push 00001202 // push P
[0000122a][00102007][00001202] 6802120000 push 00001202 // push P
[0000122f][00102003][00001234] e8fefdffff call 00001032 // call
executed H
Begin Simulation Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55 push ebp
[00001203][002120af][002120b3] 8bec mov ebp,esp
[00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
[00001208][002120ab][00001202] 50 push eax // push P
[00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
[0000120c][002120a7][00001202] 51 push ecx // push P
[0000120d][002120a3][00001212] e820feffff call 00001032 // call
emulated H Infinitely Recursive Simulation Detected Simulation
Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.
When you know that H simply implements the above algorithm there is
no need to see its source code. I am reserving the publication of the
5 pages of the source code of the halt decider for journal
publication.
Your H is not a pure function as it behaves differently depending on
what is invoking it (it returns a decision answer to main() but not
to P()) and it has side effects (aborting a simulation).
/Flibble
On 6/25/2022 10:09 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:03:17 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:28 AM, olcott wrote:
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
On 6/25/2022 12:09 AM, Malcolm McLean wrote:Sorry no. I've been programming since I was a boy and I have a
On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:It seems that you simply lack the technical competence.
On 6/24/2022 11:01 PM, Malcolm McLean wrote:Someone reports that tigers use more energy than they take in,
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, >>>>>>>>>> and determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt.
He's invoked H
| on it and H reports that it doesn't halt. He's run P(P)
and it halts.
The obvious conclusion is that PO's dry run (if he has
indeed done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that
tigers spend more energy
than they take in. Well potentially this is dynamite. One
explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to
rule out a much
simpler explanation. Which is that our measurements are
wrong.
Similarly, PO has worked out what he thinks P(P) should be
doing, by dry-running
it, and then actually run P(P) and obtained a different
result. He also found that H
agreed with the dry run. It's hard to paraphrase his
conclusion, but it is extensive
and far-reaching in its implications. The behaviour of code
when run is different
from the correct behaviour of the code when simulated. If
that's true, then it has
similar implications for computer science that disproving the >>>>>>>> conservation law
has for physics.
But the obvious explanation is that the dry-run was
incorrect. Lots of people have
suggested why it is incorrect. But they can't actually see
the code. PO needs to
understand that no-one will accept the complicated,
far-reaching explanation,
until the simple explanation has been ruled out.
I already proved that the dry run is correct.
and concludes that
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some
mistake. How were your
measurements taken? Show us your calculations, maybe you've got
your sums wrong."
Now if they are also uncooperative about sharing the details of
the investigation,
those reservations will be magnified. There can be legitimate
reasons. Tigers are
rare and need to be conserved, you can't let anyone who wants
have access to the
tigers to try to repeat the measurements. But there's also a
common illegitimate
reason put forwards by people who make extraordinary claims. If
the claims were
unexceptional, such as that tigers have a similar energy budget
to lions, then no-one
would be saying "Show me your notebooks. How do you know that
calorimeter was
calibrated accurately? What's the name of the person who took
that measurement
and can I interview them?" Extraordinary claims are put through
the wringer in a way
that ordinary ones are not. I've seen complaints about this
from parapsychologists.
But if you're going to claim to have discovered a new physical
principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest explanations
for its behaviour.
Go back and look at my proof again.
PhD in a computational-
related subject. I'm confident of my technical abilities. What I
can't do of course
is tell you exactly what is going on in code I cannot see. I've
got a pretty good idea,
but I can only reconstruct on the basis of what you tell me. Ben
thinks that I've
got it wrong and in fact there are no nested emulations at all.
I've no way of actually
disproving that idea without seeing H.
To fully understand this a software engineer must be an expert in:
(a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86
assembly language level.
Anyone having the above credentials can validate my work, if you
cannot validate my work then you do not sufficiently have the
above credentials.
Exactly how C translates into x86 is mandatory. If you don't know
how the C calling conventions are implemented in x86 you cannot
validate my work.
From a purely software engineering perspective H(P,P) is
required to to correctly determine that its correct and complete
x86 emulation of its input would never reach the "ret"
instruction of this input and H must do this in a finite number
of steps.
The ordinary semantics of standard C and the conventional x86
language are the entire semantics required to conclusively prove
that H(P,P) does correctly determine that its correct and complete
x86 emulation of its input would never reach the "ret" instruction
(final state) of this input thus never halts.
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely nested emulation.
void P(u32 x)
{
� if (H(x, x))
��� HERE: goto HERE;
� return;
}
int main()
{
� Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01)� 55������������� push ebp
[00001203](02)� 8bec����������� mov ebp,esp
[00001205](03)� 8b4508��������� mov eax,[ebp+08]
[00001208](01)� 50������������� push eax
[00001209](03)� 8b4d08��������� mov ecx,[ebp+08]
[0000120c](01)� 51������������� push ecx
[0000120d](05)� e820feffff����� call 00001032
[00001212](03)� 83c408��������� add esp,+08
[00001215](02)� 85c0����������� test eax,eax
[00001217](02)� 7402����������� jz 0000121b
[00001219](02)� ebfe����������� jmp 00001219
[0000121b](01)� 5d������������� pop ebp
[0000121c](01)� c3������������� ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01)� 55������������� push ebp
[00001223](02)� 8bec����������� mov ebp,esp
[00001225](05)� 6802120000����� push 00001202
[0000122a](05)� 6802120000����� push 00001202
[0000122f](05)� e8fefdffff����� call 00001032
[00001234](03)� 83c408��������� add esp,+08
[00001237](01)� 50������������� push eax
[00001238](05)� 68b3030000����� push 000003b3
[0000123d](05)� e8c0f1ffff����� call 00000402
[00001242](03)� 83c408��������� add esp,+08
[00001245](02)� 33c0����������� xor eax,eax
[00001247](01)� 5d������������� pop ebp
[00001248](01)� c3������������� ret
Size in bytes:(0039) [00001248]
�machine�� stack���� stack���� machine��� assembly
�address�� address�� data����� code������ language
�========� ========� ========� =========� =============
[00001222][0010200f][00000000] 55�������� push ebp
[00001223][0010200f][00000000] 8bec������ mov ebp,esp
[00001225][0010200b][00001202] 6802120000 push 00001202 // push P
[0000122a][00102007][00001202] 6802120000 push 00001202 // push P
[0000122f][00102003][00001234] e8fefdffff call 00001032 // call
executed H
Begin Simulation�� Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55�������� push ebp
[00001203][002120af][002120b3] 8bec������ mov ebp,esp
[00001205][002120af][002120b3] 8b4508���� mov eax,[ebp+08]
[00001208][002120ab][00001202] 50�������� push eax����� // push P
[00001209][002120ab][00001202] 8b4d08���� mov ecx,[ebp+08]
[0000120c][002120a7][00001202] 51�������� push ecx����� // push P
[0000120d][002120a3][00001212] e820feffff call 00001032 // call
emulated H Infinitely Recursive Simulation Detected Simulation
Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.
When you know that H simply implements the above algorithm there is
no need to see its source code. I am reserving the publication of
the 5 pages of the source code of the halt decider for journal
publication.
Your H is not a pure function as it behaves differently depending on
what is invoking it (it returns a decision answer to main() but not
to P()) and it has side effects (aborting a simulation).
/Flibble
Finally a critique that has a reasonable basis.
When I transformed H into a pure function of its inputs it always has
the same behavior no matter how it is invoked.
The x86 emulation of P is aborted before P invokes H.
On 6/25/2022 10:21 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:19:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:09 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:03:17 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:28 AM, olcott wrote:
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
On 6/25/2022 12:09 AM, Malcolm McLean wrote:Sorry no. I've been programming since I was a boy and I have a
On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote: >>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:It seems that you simply lack the technical competence.
Someone reports that tigers use more energy than they takeOn Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse >>>>>>>>>> wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the >>>>>>>>>>>> code, and determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved: >>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt. >>>>>>>>>>> He's invoked H
| on it and H reports that it doesn't halt. He's run P(P) >>>>>>>>>>> and it halts.
The obvious conclusion is that PO's dry run (if he has >>>>>>>>>>> indeed done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that
tigers spend more energy
than they take in. Well potentially this is dynamite. One >>>>>>>>>> explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to >>>>>>>>>> rule out a much
simpler explanation. Which is that our measurements are
wrong.
Similarly, PO has worked out what he thinks P(P) should be >>>>>>>>>> doing, by dry-running
it, and then actually run P(P) and obtained a different
result. He also found that H
agreed with the dry run. It's hard to paraphrase his
conclusion, but it is extensive
and far-reaching in its implications. The behaviour of code >>>>>>>>>> when run is different
from the correct behaviour of the code when simulated. If >>>>>>>>>> that's true, then it has
similar implications for computer science that disproving >>>>>>>>>> the conservation law
has for physics.
But the obvious explanation is that the dry-run was
incorrect. Lots of people have
suggested why it is incorrect. But they can't actually see >>>>>>>>>> the code. PO needs to
understand that no-one will accept the complicated,
far-reaching explanation,
until the simple explanation has been ruled out.
I already proved that the dry run is correct.
in, and concludes that
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some
mistake. How were your
measurements taken? Show us your calculations, maybe you've
got your sums wrong."
Now if they are also uncooperative about sharing the details >>>>>>>> of the investigation,
those reservations will be magnified. There can be legitimate >>>>>>>> reasons. Tigers are
rare and need to be conserved, you can't let anyone who wants >>>>>>>> have access to the
tigers to try to repeat the measurements. But there's also a >>>>>>>> common illegitimate
reason put forwards by people who make extraordinary claims. >>>>>>>> If the claims were
unexceptional, such as that tigers have a similar energy
budget to lions, then no-one
would be saying "Show me your notebooks. How do you know that >>>>>>>> calorimeter was
calibrated accurately? What's the name of the person who took >>>>>>>> that measurement
and can I interview them?" Extraordinary claims are put
through the wringer in a way
that ordinary ones are not. I've seen complaints about this
from parapsychologists.
But if you're going to claim to have discovered a new
physical principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest
explanations for its behaviour.
Go back and look at my proof again.
PhD in a computational-
related subject. I'm confident of my technical abilities. What
I can't do of course
is tell you exactly what is going on in code I cannot see. I've
got a pretty good idea,
but I can only reconstruct on the basis of what you tell me.
Ben thinks that I've
got it wrong and in fact there are no nested emulations at all.
I've no way of actually
disproving that idea without seeing H.
To fully understand this a software engineer must be an expert
in: (a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86
assembly language level.
Anyone having the above credentials can validate my work, if you
cannot validate my work then you do not sufficiently have the
above credentials.
Exactly how C translates into x86 is mandatory. If you don't
know how the C calling conventions are implemented in x86 you
cannot validate my work.
From a purely software engineering perspective H(P,P) is
required to to correctly determine that its correct and complete
x86 emulation of its input would never reach the "ret"
instruction of this input and H must do this in a finite number
of steps.
The ordinary semantics of standard C and the conventional x86
language are the entire semantics required to conclusively prove
that H(P,P) does correctly determine that its correct and
complete x86 emulation of its input would never reach the "ret"
instruction (final state) of this input thus never halts.
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and
P would remain stuck in infinitely nested emulation.
void P(u32 x)
{
� if (H(x, x))
��� HERE: goto HERE;
� return;
}
int main()
{
� Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01)� 55������������� push ebp
[00001203](02)� 8bec����������� mov ebp,esp
[00001205](03)� 8b4508��������� mov eax,[ebp+08]
[00001208](01)� 50������������� push eax
[00001209](03)� 8b4d08��������� mov ecx,[ebp+08]
[0000120c](01)� 51������������� push ecx
[0000120d](05)� e820feffff����� call 00001032
[00001212](03)� 83c408��������� add esp,+08
[00001215](02)� 85c0����������� test eax,eax
[00001217](02)� 7402����������� jz 0000121b
[00001219](02)� ebfe����������� jmp 00001219
[0000121b](01)� 5d������������� pop ebp
[0000121c](01)� c3������������� ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01)� 55������������� push ebp
[00001223](02)� 8bec����������� mov ebp,esp
[00001225](05)� 6802120000����� push 00001202
[0000122a](05)� 6802120000����� push 00001202
[0000122f](05)� e8fefdffff����� call 00001032
[00001234](03)� 83c408��������� add esp,+08
[00001237](01)� 50������������� push eax
[00001238](05)� 68b3030000����� push 000003b3
[0000123d](05)� e8c0f1ffff����� call 00000402
[00001242](03)� 83c408��������� add esp,+08
[00001245](02)� 33c0����������� xor eax,eax
[00001247](01)� 5d������������� pop ebp
[00001248](01)� c3������������� ret
Size in bytes:(0039) [00001248]
�machine�� stack���� stack���� machine��� assembly
�address�� address�� data����� code������ language
�========� ========� ========� =========� =============
[00001222][0010200f][00000000] 55�������� push ebp
[00001223][0010200f][00000000] 8bec������ mov ebp,esp
[00001225][0010200b][00001202] 6802120000 push 00001202 // push
P [0000122a][00102007][00001202] 6802120000 push 00001202 //
push P [0000122f][00102003][00001234] e8fefdffff call 00001032
// call executed H
Begin Simulation�� Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55�������� push ebp
[00001203][002120af][002120b3] 8bec������ mov ebp,esp
[00001205][002120af][002120b3] 8b4508���� mov eax,[ebp+08]
[00001208][002120ab][00001202] 50�������� push eax����� // push
P [00001209][002120ab][00001202] 8b4d08���� mov ecx,[ebp+08]
[0000120c][002120a7][00001202] 51�������� push ecx����� // push
P [0000120d][002120a3][00001212] e820feffff call 00001032 //
call emulated H Infinitely Recursive Simulation Detected
Simulation Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to
determine: (a) P is calling H with the same arguments that H
was called with. (b) No instructions in P could possibly escape
this otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is
emulated.
When you know that H simply implements the above algorithm there
is no need to see its source code. I am reserving the
publication of the 5 pages of the source code of the halt
decider for journal publication.
Your H is not a pure function as it behaves differently depending
on what is invoking it (it returns a decision answer to main()
but not to P()) and it has side effects (aborting a simulation).
/Flibble
Finally a critique that has a reasonable basis.
When I transformed H into a pure function of its inputs it always
has the same behavior no matter how it is invoked.
The x86 emulation of P is aborted before P invokes H.
Nope. Preventing a call to H is equivalent to H behaving differently
for same inputs. Aborting a simulation is a side effect: pure
functions do not have side effects.
/Flibble
In other words you are saying that a halt decider is simply not
allowed to report when it correctly detects that it is being called
in infinitely recursive simulation.
On Sat, 25 Jun 2022 10:54:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:21 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:19:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:09 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:03:17 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:28 AM, olcott wrote:
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
On 6/25/2022 12:09 AM, Malcolm McLean wrote:Sorry no. I've been programming since I was a boy and I have a >>>>>>>> PhD in a computational-
On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote: >>>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:It seems that you simply lack the technical competence.
Someone reports that tigers use more energy than they take >>>>>>>>>> in, and concludes thatOn Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse >>>>>>>>>>>> wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the >>>>>>>>>>>>>> code, and determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved: >>>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt. >>>>>>>>>>>>> He's invoked H
| on it and H reports that it doesn't halt. He's run P(P) >>>>>>>>>>>>> and it halts.
The obvious conclusion is that PO's dry run (if he has >>>>>>>>>>>>> indeed done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that >>>>>>>>>>>> tigers spend more energy
than they take in. Well potentially this is dynamite. One >>>>>>>>>>>> explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to >>>>>>>>>>>> rule out a much
simpler explanation. Which is that our measurements are >>>>>>>>>>>> wrong.
Similarly, PO has worked out what he thinks P(P) should be >>>>>>>>>>>> doing, by dry-running
it, and then actually run P(P) and obtained a different >>>>>>>>>>>> result. He also found that H
agreed with the dry run. It's hard to paraphrase his
conclusion, but it is extensive
and far-reaching in its implications. The behaviour of code >>>>>>>>>>>> when run is different
from the correct behaviour of the code when simulated. If >>>>>>>>>>>> that's true, then it has
similar implications for computer science that disproving >>>>>>>>>>>> the conservation law
has for physics.
But the obvious explanation is that the dry-run was
incorrect. Lots of people have
suggested why it is incorrect. But they can't actually see >>>>>>>>>>>> the code. PO needs to
understand that no-one will accept the complicated,
far-reaching explanation,
until the simple explanation has been ruled out.
I already proved that the dry run is correct.
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some
mistake. How were your
measurements taken? Show us your calculations, maybe you've >>>>>>>>>> got your sums wrong."
Now if they are also uncooperative about sharing the details >>>>>>>>>> of the investigation,
those reservations will be magnified. There can be legitimate >>>>>>>>>> reasons. Tigers are
rare and need to be conserved, you can't let anyone who wants >>>>>>>>>> have access to the
tigers to try to repeat the measurements. But there's also a >>>>>>>>>> common illegitimate
reason put forwards by people who make extraordinary claims. >>>>>>>>>> If the claims were
unexceptional, such as that tigers have a similar energy
budget to lions, then no-one
would be saying "Show me your notebooks. How do you know that >>>>>>>>>> calorimeter was
calibrated accurately? What's the name of the person who took >>>>>>>>>> that measurement
and can I interview them?" Extraordinary claims are put
through the wringer in a way
that ordinary ones are not. I've seen complaints about this >>>>>>>>>> from parapsychologists.
But if you're going to claim to have discovered a new
physical principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest
explanations for its behaviour.
Go back and look at my proof again.
related subject. I'm confident of my technical abilities. What >>>>>>>> I can't do of course
is tell you exactly what is going on in code I cannot see. I've >>>>>>>> got a pretty good idea,
but I can only reconstruct on the basis of what you tell me.
Ben thinks that I've
got it wrong and in fact there are no nested emulations at all. >>>>>>>> I've no way of actually
disproving that idea without seeing H.
To fully understand this a software engineer must be an expert
in: (a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86
assembly language level.
Anyone having the above credentials can validate my work, if you >>>>>>> cannot validate my work then you do not sufficiently have the
above credentials.
Exactly how C translates into x86 is mandatory. If you don't
know how the C calling conventions are implemented in x86 you
cannot validate my work.
From a purely software engineering perspective H(P,P) is
required to to correctly determine that its correct and complete >>>>>>> x86 emulation of its input would never reach the "ret"
instruction of this input and H must do this in a finite number
of steps.
The ordinary semantics of standard C and the conventional x86
language are the entire semantics required to conclusively prove >>>>>>> that H(P,P) does correctly determine that its correct and
complete x86 emulation of its input would never reach the "ret"
instruction (final state) of this input thus never halts.
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and
P would remain stuck in infinitely nested emulation.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01) 55 push ebp
[00001203](02) 8bec mov ebp,esp
[00001205](03) 8b4508 mov eax,[ebp+08]
[00001208](01) 50 push eax
[00001209](03) 8b4d08 mov ecx,[ebp+08]
[0000120c](01) 51 push ecx
[0000120d](05) e820feffff call 00001032
[00001212](03) 83c408 add esp,+08
[00001215](02) 85c0 test eax,eax
[00001217](02) 7402 jz 0000121b
[00001219](02) ebfe jmp 00001219
[0000121b](01) 5d pop ebp
[0000121c](01) c3 ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01) 55 push ebp
[00001223](02) 8bec mov ebp,esp
[00001225](05) 6802120000 push 00001202
[0000122a](05) 6802120000 push 00001202
[0000122f](05) e8fefdffff call 00001032
[00001234](03) 83c408 add esp,+08
[00001237](01) 50 push eax
[00001238](05) 68b3030000 push 000003b3
[0000123d](05) e8c0f1ffff call 00000402
[00001242](03) 83c408 add esp,+08
[00001245](02) 33c0 xor eax,eax
[00001247](01) 5d pop ebp
[00001248](01) c3 ret
Size in bytes:(0039) [00001248]
machine stack stack machine assembly >>>>>>> address address data code language >>>>>>> ======== ======== ======== ========= ============= >>>>>>> [00001222][0010200f][00000000] 55 push ebp
[00001223][0010200f][00000000] 8bec mov ebp,esp
[00001225][0010200b][00001202] 6802120000 push 00001202 // push
P [0000122a][00102007][00001202] 6802120000 push 00001202 //
push P [0000122f][00102003][00001234] e8fefdffff call 00001032
// call executed H
Begin Simulation Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55 push ebp
[00001203][002120af][002120b3] 8bec mov ebp,esp
[00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
[00001208][002120ab][00001202] 50 push eax // push
P [00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08] >>>>>>> [0000120c][002120a7][00001202] 51 push ecx // push
P [0000120d][002120a3][00001212] e820feffff call 00001032 //
call emulated H Infinitely Recursive Simulation Detected
Simulation Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to
determine: (a) P is calling H with the same arguments that H
was called with. (b) No instructions in P could possibly escape
this otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is
emulated.
When you know that H simply implements the above algorithm there
is no need to see its source code. I am reserving the
publication of the 5 pages of the source code of the halt
decider for journal publication.
Your H is not a pure function as it behaves differently depending
on what is invoking it (it returns a decision answer to main()
but not to P()) and it has side effects (aborting a simulation).
/Flibble
Finally a critique that has a reasonable basis.
When I transformed H into a pure function of its inputs it always
has the same behavior no matter how it is invoked.
The x86 emulation of P is aborted before P invokes H.
Nope. Preventing a call to H is equivalent to H behaving differently
for same inputs. Aborting a simulation is a side effect: pure
functions do not have side effects.
/Flibble
In other words you are saying that a halt decider is simply not
allowed to report when it correctly detects that it is being called
in infinitely recursive simulation.
I keep telling you this: the infinite recursion is NOT present when
using a valid halt decider: your H is NOT a valid halt
decider.
Simulation is an erroneous approach as a simulating halt decider
can not answer in finite time for a non-halting input as there is no
proven general solution for detecting non-halting behaviour.
/Flibble
On 6/25/2022 10:59 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:54:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:21 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:19:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:09 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:03:17 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:28 AM, olcott wrote:
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote: >>>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
Sorry no. I've been programming since I was a boy and I have >>>>>>>> a PhD in a computational-On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote: >>>>>>>>>>It seems that you simply lack the technical competence.
On 6/24/2022 11:01 PM, Malcolm McLean wrote:Someone reports that tigers use more energy than they take >>>>>>>>>> in, and concludes that
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse >>>>>>>>>>>> wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the >>>>>>>>>>>>>> code, and determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved: >>>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't >>>>>>>>>>>>> halt. He's invoked H
| on it and H reports that it doesn't halt. He's run >>>>>>>>>>>>> P(P) and it halts.
The obvious conclusion is that PO's dry run (if he has >>>>>>>>>>>>> indeed done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that >>>>>>>>>>>> tigers spend more energy
than they take in. Well potentially this is dynamite. One >>>>>>>>>>>> explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need >>>>>>>>>>>> to rule out a much
simpler explanation. Which is that our measurements are >>>>>>>>>>>> wrong.
Similarly, PO has worked out what he thinks P(P) should >>>>>>>>>>>> be doing, by dry-running
it, and then actually run P(P) and obtained a different >>>>>>>>>>>> result. He also found that H
agreed with the dry run. It's hard to paraphrase his >>>>>>>>>>>> conclusion, but it is extensive
and far-reaching in its implications. The behaviour of >>>>>>>>>>>> code when run is different
from the correct behaviour of the code when simulated. If >>>>>>>>>>>> that's true, then it has
similar implications for computer science that disproving >>>>>>>>>>>> the conservation law
has for physics.
But the obvious explanation is that the dry-run was
incorrect. Lots of people have
suggested why it is incorrect. But they can't actually >>>>>>>>>>>> see the code. PO needs to
understand that no-one will accept the complicated,
far-reaching explanation,
until the simple explanation has been ruled out.
I already proved that the dry run is correct.
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some
mistake. How were your
measurements taken? Show us your calculations, maybe you've >>>>>>>>>> got your sums wrong."
Now if they are also uncooperative about sharing the
details of the investigation,
those reservations will be magnified. There can be
legitimate reasons. Tigers are
rare and need to be conserved, you can't let anyone who
wants have access to the
tigers to try to repeat the measurements. But there's also >>>>>>>>>> a common illegitimate
reason put forwards by people who make extraordinary
claims. If the claims were
unexceptional, such as that tigers have a similar energy >>>>>>>>>> budget to lions, then no-one
would be saying "Show me your notebooks. How do you know >>>>>>>>>> that calorimeter was
calibrated accurately? What's the name of the person who >>>>>>>>>> took that measurement
and can I interview them?" Extraordinary claims are put
through the wringer in a way
that ordinary ones are not. I've seen complaints about this >>>>>>>>>> from parapsychologists.
But if you're going to claim to have discovered a new
physical principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest
explanations for its behaviour.
Go back and look at my proof again.
related subject. I'm confident of my technical abilities.
What I can't do of course
is tell you exactly what is going on in code I cannot see.
I've got a pretty good idea,
but I can only reconstruct on the basis of what you tell me. >>>>>>>> Ben thinks that I've
got it wrong and in fact there are no nested emulations at
all. I've no way of actually
disproving that idea without seeing H.
To fully understand this a software engineer must be an expert >>>>>>> in: (a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86
assembly language level.
Anyone having the above credentials can validate my work, if
you cannot validate my work then you do not sufficiently have
the above credentials.
Exactly how C translates into x86 is mandatory. If you don't
know how the C calling conventions are implemented in x86 you
cannot validate my work.
From a purely software engineering perspective H(P,P) is
required to to correctly determine that its correct and
complete x86 emulation of its input would never reach the
"ret" instruction of this input and H must do this in a
finite number of steps.
The ordinary semantics of standard C and the conventional x86
language are the entire semantics required to conclusively
prove that H(P,P) does correctly determine that its correct
and complete x86 emulation of its input would never reach the
"ret" instruction (final state) of this input thus never
halts.
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely nested emulation.
void P(u32 x)
{
� if (H(x, x))
��� HERE: goto HERE;
� return;
}
int main()
{
� Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01)� 55������������� push ebp
[00001203](02)� 8bec����������� mov ebp,esp
[00001205](03)� 8b4508��������� mov eax,[ebp+08]
[00001208](01)� 50������������� push eax
[00001209](03)� 8b4d08��������� mov ecx,[ebp+08]
[0000120c](01)� 51������������� push ecx
[0000120d](05)� e820feffff����� call 00001032
[00001212](03)� 83c408��������� add esp,+08
[00001215](02)� 85c0����������� test eax,eax
[00001217](02)� 7402����������� jz 0000121b
[00001219](02)� ebfe����������� jmp 00001219
[0000121b](01)� 5d������������� pop ebp
[0000121c](01)� c3������������� ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01)� 55������������� push ebp
[00001223](02)� 8bec����������� mov ebp,esp
[00001225](05)� 6802120000����� push 00001202
[0000122a](05)� 6802120000����� push 00001202
[0000122f](05)� e8fefdffff����� call 00001032
[00001234](03)� 83c408��������� add esp,+08
[00001237](01)� 50������������� push eax
[00001238](05)� 68b3030000����� push 000003b3
[0000123d](05)� e8c0f1ffff����� call 00000402
[00001242](03)� 83c408��������� add esp,+08
[00001245](02)� 33c0����������� xor eax,eax
[00001247](01)� 5d������������� pop ebp
[00001248](01)� c3������������� ret
Size in bytes:(0039) [00001248]
�machine�� stack���� stack���� machine��� assembly
�address�� address�� data����� code������ language
�========� ========� ========� =========� =============
[00001222][0010200f][00000000] 55�������� push ebp
[00001223][0010200f][00000000] 8bec������ mov ebp,esp
[00001225][0010200b][00001202] 6802120000 push 00001202 //
push P [0000122a][00102007][00001202] 6802120000 push
00001202 // push P [0000122f][00102003][00001234] e8fefdffff
call 00001032 // call executed H
Begin Simulation�� Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55�������� push ebp
[00001203][002120af][002120b3] 8bec������ mov ebp,esp
[00001205][002120af][002120b3] 8b4508���� mov eax,[ebp+08]
[00001208][002120ab][00001202] 50�������� push eax����� //
push P [00001209][002120ab][00001202] 8b4d08���� mov
ecx,[ebp+08] [0000120c][002120a7][00001202] 51�������� push
ecx����� // push P [0000120d][002120a3][00001212] e820feffff
call 00001032 // call emulated H Infinitely Recursive
Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can
easily examine its stored execution_trace of P (see above) to
determine: (a) P is calling H with the same arguments that H
was called with. (b) No instructions in P could possibly
escape this otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is
emulated.
When you know that H simply implements the above algorithm
there is no need to see its source code. I am reserving the
publication of the 5 pages of the source code of the halt
decider for journal publication.
Your H is not a pure function as it behaves differently
depending on what is invoking it (it returns a decision answer
to main() but not to P()) and it has side effects (aborting a
simulation).
/Flibble
Finally a critique that has a reasonable basis.
When I transformed H into a pure function of its inputs it always
has the same behavior no matter how it is invoked.
The x86 emulation of P is aborted before P invokes H.
Nope. Preventing a call to H is equivalent to H behaving
differently for same inputs. Aborting a simulation is a side
effect: pure functions do not have side effects.
/Flibble
In other words you are saying that a halt decider is simply not
allowed to report when it correctly detects that it is being called
in infinitely recursive simulation.
I keep telling you this: the infinite recursion is NOT present when
using a valid halt decider: your H is NOT a valid halt
decider.
Simulation is an erroneous approach as a simulating halt decider
can not answer in finite time for a non-halting input as there is no
proven general solution for detecting non-halting behaviour.
/Flibble
IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY
YOU DENY THIS VERIFIABLE FACT:
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and
P would remain stuck in infinitely nested emulation.
On Sat, 25 Jun 2022 11:06:12 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:59 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:54:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:21 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:19:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:09 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:03:17 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:28 AM, olcott wrote:
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote: >>>>>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
Sorry no. I've been programming since I was a boy and I have >>>>>>>>>> a PhD in a computational-On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote: >>>>>>>>>>>>It seems that you simply lack the technical competence.
On 6/24/2022 11:01 PM, Malcolm McLean wrote:Someone reports that tigers use more energy than they take >>>>>>>>>>>> in, and concludes that
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse >>>>>>>>>>>>>> wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>>>>>>>>>>>>Exactly.
"Dry run" means that a human programmer looks at the >>>>>>>>>>>>>>>> code, and determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved: >>>>>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't >>>>>>>>>>>>>>> halt. He's invoked H
| on it and H reports that it doesn't halt. He's run >>>>>>>>>>>>>>> P(P) and it halts.
The obvious conclusion is that PO's dry run (if he has >>>>>>>>>>>>>>> indeed done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that >>>>>>>>>>>>>> tigers spend more energy
than they take in. Well potentially this is dynamite. One >>>>>>>>>>>>>> explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need >>>>>>>>>>>>>> to rule out a much
simpler explanation. Which is that our measurements are >>>>>>>>>>>>>> wrong.
Similarly, PO has worked out what he thinks P(P) should >>>>>>>>>>>>>> be doing, by dry-running
it, and then actually run P(P) and obtained a different >>>>>>>>>>>>>> result. He also found that H
agreed with the dry run. It's hard to paraphrase his >>>>>>>>>>>>>> conclusion, but it is extensive
and far-reaching in its implications. The behaviour of >>>>>>>>>>>>>> code when run is different
from the correct behaviour of the code when simulated. If >>>>>>>>>>>>>> that's true, then it has
similar implications for computer science that disproving >>>>>>>>>>>>>> the conservation law
has for physics.
But the obvious explanation is that the dry-run was >>>>>>>>>>>>>> incorrect. Lots of people have
suggested why it is incorrect. But they can't actually >>>>>>>>>>>>>> see the code. PO needs to
understand that no-one will accept the complicated, >>>>>>>>>>>>>> far-reaching explanation,
until the simple explanation has been ruled out.
I already proved that the dry run is correct.
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some >>>>>>>>>>>> mistake. How were your
measurements taken? Show us your calculations, maybe you've >>>>>>>>>>>> got your sums wrong."
Now if they are also uncooperative about sharing the
details of the investigation,
those reservations will be magnified. There can be
legitimate reasons. Tigers are
rare and need to be conserved, you can't let anyone who >>>>>>>>>>>> wants have access to the
tigers to try to repeat the measurements. But there's also >>>>>>>>>>>> a common illegitimate
reason put forwards by people who make extraordinary
claims. If the claims were
unexceptional, such as that tigers have a similar energy >>>>>>>>>>>> budget to lions, then no-one
would be saying "Show me your notebooks. How do you know >>>>>>>>>>>> that calorimeter was
calibrated accurately? What's the name of the person who >>>>>>>>>>>> took that measurement
and can I interview them?" Extraordinary claims are put >>>>>>>>>>>> through the wringer in a way
that ordinary ones are not. I've seen complaints about this >>>>>>>>>>>> from parapsychologists.
But if you're going to claim to have discovered a new
physical principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest
explanations for its behaviour.
Go back and look at my proof again.
related subject. I'm confident of my technical abilities.
What I can't do of course
is tell you exactly what is going on in code I cannot see. >>>>>>>>>> I've got a pretty good idea,
but I can only reconstruct on the basis of what you tell me. >>>>>>>>>> Ben thinks that I've
got it wrong and in fact there are no nested emulations at >>>>>>>>>> all. I've no way of actually
disproving that idea without seeing H.
To fully understand this a software engineer must be an expert >>>>>>>>> in: (a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86
assembly language level.
Anyone having the above credentials can validate my work, if >>>>>>>>> you cannot validate my work then you do not sufficiently have >>>>>>>>> the above credentials.
Exactly how C translates into x86 is mandatory. If you don't >>>>>>>>> know how the C calling conventions are implemented in x86 you >>>>>>>>> cannot validate my work.
From a purely software engineering perspective H(P,P) is >>>>>>>>> required to to correctly determine that its correct and
complete x86 emulation of its input would never reach the
"ret" instruction of this input and H must do this in a
finite number of steps.
The ordinary semantics of standard C and the conventional x86 >>>>>>>>> language are the entire semantics required to conclusively
prove that H(P,P) does correctly determine that its correct
and complete x86 emulation of its input would never reach the >>>>>>>>> "ret" instruction (final state) of this input thus never
halts.
The correct and complete x86 emulation of its input by H(P,P) >>>>>>>>> would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely nested emulation.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01) 55 push ebp
[00001203](02) 8bec mov ebp,esp
[00001205](03) 8b4508 mov eax,[ebp+08]
[00001208](01) 50 push eax
[00001209](03) 8b4d08 mov ecx,[ebp+08]
[0000120c](01) 51 push ecx
[0000120d](05) e820feffff call 00001032
[00001212](03) 83c408 add esp,+08
[00001215](02) 85c0 test eax,eax
[00001217](02) 7402 jz 0000121b
[00001219](02) ebfe jmp 00001219
[0000121b](01) 5d pop ebp
[0000121c](01) c3 ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01) 55 push ebp
[00001223](02) 8bec mov ebp,esp
[00001225](05) 6802120000 push 00001202
[0000122a](05) 6802120000 push 00001202
[0000122f](05) e8fefdffff call 00001032
[00001234](03) 83c408 add esp,+08
[00001237](01) 50 push eax
[00001238](05) 68b3030000 push 000003b3
[0000123d](05) e8c0f1ffff call 00000402
[00001242](03) 83c408 add esp,+08
[00001245](02) 33c0 xor eax,eax
[00001247](01) 5d pop ebp
[00001248](01) c3 ret
Size in bytes:(0039) [00001248]
machine stack stack machine assembly >>>>>>>>> address address data code language
======== ======== ======== ========= ============= >>>>>>>>> [00001222][0010200f][00000000] 55 push ebp
[00001223][0010200f][00000000] 8bec mov ebp,esp
[00001225][0010200b][00001202] 6802120000 push 00001202 //
push P [0000122a][00102007][00001202] 6802120000 push
00001202 // push P [0000122f][00102003][00001234] e8fefdffff >>>>>>>>> call 00001032 // call executed H
Begin Simulation Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55 push ebp
[00001203][002120af][002120b3] 8bec mov ebp,esp
[00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08] >>>>>>>>> [00001208][002120ab][00001202] 50 push eax //
push P [00001209][002120ab][00001202] 8b4d08 mov
ecx,[ebp+08] [0000120c][002120a7][00001202] 51 push >>>>>>>>> ecx // push P [0000120d][002120a3][00001212] e820feffff >>>>>>>>> call 00001032 // call emulated H Infinitely Recursive
Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can
easily examine its stored execution_trace of P (see above) to >>>>>>>>> determine: (a) P is calling H with the same arguments that H >>>>>>>>> was called with. (b) No instructions in P could possibly
escape this otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is
emulated.
When you know that H simply implements the above algorithm
there is no need to see its source code. I am reserving the
publication of the 5 pages of the source code of the halt
decider for journal publication.
Your H is not a pure function as it behaves differently
depending on what is invoking it (it returns a decision answer
to main() but not to P()) and it has side effects (aborting a
simulation).
/Flibble
Finally a critique that has a reasonable basis.
When I transformed H into a pure function of its inputs it always
has the same behavior no matter how it is invoked.
The x86 emulation of P is aborted before P invokes H.
Nope. Preventing a call to H is equivalent to H behaving
differently for same inputs. Aborting a simulation is a side
effect: pure functions do not have side effects.
/Flibble
In other words you are saying that a halt decider is simply not
allowed to report when it correctly detects that it is being called
in infinitely recursive simulation.
I keep telling you this: the infinite recursion is NOT present when
using a valid halt decider: your H is NOT a valid halt
decider.
Simulation is an erroneous approach as a simulating halt decider
can not answer in finite time for a non-halting input as there is no
proven general solution for detecting non-halting behaviour.
/Flibble
IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY
YOU DENY THIS VERIFIABLE FACT:
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and
P would remain stuck in infinitely nested emulation.
For [Strachey 1965] (and the proofs based on it) H is NOT a simulating
halt decider so there is no infinite recursion as there is no emulation.
Valid halt deciders ANALYSE P, they do not EMULATE P.
/Flibble
On Saturday, June 25, 2022 at 3:10:50 PM UTC+1, olcott wrote:emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
On 6/25/2022 6:56 AM, Paul N wrote:
On Friday, June 24, 2022 at 9:27:27 PM UTC+1, olcott wrote:
On 6/24/2022 3:05 PM, Paul N wrote:
On Friday, June 24, 2022 at 7:52:22 PM UTC+1, olcott wrote:
On 6/22/2022 9:23 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote: >>>>>>>> On 6/22/2022 8:44 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote: >>>>>>>>>> On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
On 6/22/2022 4:20 PM, Mr Flibble wrote:H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct
On Wed, 22 Jun 2022 15:27:01 -0500If you are competent then you already know this is true and lie about it:
olcott <No...@NoWhere.com> wrote:
On 6/22/2022 2:31 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
olcott <No...@NoWhere.com> wrote:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P)); >>>>>>>>>>>>>>>>>>>>>> }
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02 >>>>>>>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P)
by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack >>>>>>>>>>>>>>>>>>>>>> u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly >>>>>>>>>>>>>>>>>>>>>> address address data code language >>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= ============= >>>>>>>>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp >>>>>>>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P >>>>>>>>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P >>>>>>>>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*) >>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code)); >>>>>>>>>>>>>>>>>>>>>> Registers* master_state = (Registers*) >>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
Registers* slave_state = (Registers*) >>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k; >>>>>>>>>>>>>>>>>>>>>> u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) >>>>>>>>>>>>>>>>>>>>>> * 1000);
__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18 >>>>>>>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:", >>>>>>>>>>>>>>>>>>>>>> execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, >>>>>>>>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated >>>>>>>>>>>>>>>>>>>>>> }
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine: >>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs. >>>>>>>>>>>>>>>>>>>>>>
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234) >>>>>>>>>>>>>>>>>>>>>>
The "ret" instruction of P is its final state. >>>>>>>>>>>>>>>>>>>>>>
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320) >>>>>>>>>>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>>>>>>>>>>> }
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax >>>>>>>>>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp >>>>>>>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret >>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120) >>>>>>>>>>>>>>>>>>>>>
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software
engineering not meeting these specs:
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly
language level. No knowledge of the halting problem is required.
I cannot speak for Richard but I have 30+ years C++ experience; I also
have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
emulator in 80286 assembly) and I can recognize an infinite recursion;
the problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based
omnishambles:
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>>>
UTM(P,P), would do. And it fails to do that.You just said that H(P,P) cannot correctly predict that the correct and_Infinite_Loop()I never claimed that H(P,P) performs a complete and correct emulation ofYour entire basis and all of assumptions was incorrect so when I >>>>>>>>>>>>>> provided an infallible one to that cannot possibly be correctly refutedSo you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of Px because both H and Px
would remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>
you simply dodged it. That is a smart move for a dishonest person that
is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my >>>>>>>>>>>>>> airtight correct reasoning. Another dodge will be construed as a tacit
admission of defeat.
As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
its input so your rebuttal is the strawman deception.
I claimed that H(P,P) correctly predicts that its complete and correct
x86 emulation of its input would never reach the "ret" instruction of P.
But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f >>>>>>>>>> ...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning because H >>>>>>>>>> *can't* do a correct and complete emulation of its input, H cannot >>>>>>>>>> possibly determine that _Infinite_Loop() never halts.
Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B
complete x86 emulation of its input would never reach the "ret" >>>>>>>> instruction of P without a compete x86 emulation of its input. I just >>>>>>>> proved that is a very stupid thing to say.
You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.e.
includes emulating the call to H, that this call to H would start emulating the call to P, etc, etc, and so the call to P does not terminate.From a purely software engineering perspective H(P,P) is required to to >>>>>> correctly determine that its correct and complete x86 emulation of its >>>>>> input would never reach the "ret" instruction of this input and H must >>>>>> do this in a finite number of steps.
The ordinary semantics of standard C and the conventional x86 language >>>>>> are the entire semantics required to conclusively prove that H(P,P) does >>>>>> correctly determine that its correct and complete x86 emulation of its >>>>>> input would never reach the "ret" instruction.
That you disagree with easily verified software engineering when you >>>>>> already know that this software engineering is correct speaks loads >>>>>> about your character.
The only computer science that need be added to this is that the "ret" >>>>>> instruction is the final state of P and that a sequence of
configurations that cannot possibly reach its final state is a
non-halting sequence.
You say that "H(P,P) is required to to correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction of this input". You seem to be assuming that H does an emulation of P, that this emulation
Yes they both return.Thanks for continuing to review this.
No assumptions two years of software development derived fully
operational software that conclusively proves this.
It might help people's understanding if we had a few more examples. Suppose, in addition to the normal P and H, we have two more functions as follows:
void Q(void)
{
if (H(P, P))
H2: goto H2;
return;
}
void R(void)
{
H(P, P);
return;
}
Will Q return? Will R return?
void Q(void)
{
if (H(P, P))
H2: goto H2;
return;
}
void R(void)
{
H(P, P);
return;
}
_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]
_Q()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) 68f0110000 push 000011f0
[0000121d](05) e8fefdffff call 00001020
[00001222](03) 83c408 add esp,+08
[00001225](02) 85c0 test eax,eax
[00001227](02) 7402 jz 0000122b
[00001229](02) ebfe jmp 00001229
[0000122b](01) 5d pop ebp
[0000122c](01) c3 ret
Size in bytes:(0029) [0000122c]
_main()
[00001250](01) 55 push ebp
[00001251](02) 8bec mov ebp,esp
[00001253](05) e8b8ffffff call 00001210
[00001258](02) 33c0 xor eax,eax
[0000125a](01) 5d pop ebp
[0000125b](01) c3 ret
Size in bytes:(0012) [0000125b]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001250][00102048][00000000] 55 push ebp
...[00001251][00102048][00000000] 8bec mov ebp,esp
...[00001253][00102044][00001258] e8b8ffffff call 00001210
...[00001210][00102040][00102048] 55 push ebp
...[00001211][00102040][00102048] 8bec mov ebp,esp
...[00001213][0010203c][000011f0] 68f0110000 push 000011f0
...[00001218][00102038][000011f0] 68f0110000 push 000011f0
...[0000121d][00102034][00001222] e8fefdffff call 00001020
Begin Simulation Execution Trace Stored at:2120fc
Address_of_H:1020
...[000011f0][002120e8][002120ec] 55 push ebp
...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
...[000011f6][002120e4][000011f0] 50 push eax
...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
...[000011fa][002120e0][000011f0] 51 push ecx
...[000011fb][002120dc][00001200] e820feffff call 00001020
Infinitely Recursive Simulation Detected Simulation Stopped
...[00001222][00102040][00102048] 83c408 add esp,+08
...[00001225][00102040][00102048] 85c0 test eax,eax
...[00001227][00102040][00102048] 7402 jz 0000122b
...[0000122b][00102044][00001258] 5d pop ebp
...[0000122c][00102048][00000000] c3 ret
...[00001258][00102048][00000000] 33c0 xor eax,eax
...[0000125a][0010204c][00100000] 5d pop ebp
...[0000125b][00102050][00000000] c3 ret
Number of Instructions Executed(874)
Above is:
int main()
{
Q();
//R();
}
---
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001250][00102048][00000000] 55 push ebp
...[00001251][00102048][00000000] 8bec mov ebp,esp
...[00001253][00102044][00001258] e8d8ffffff call 00001230
...[00001230][00102040][00102048] 55 push ebp
...[00001231][00102040][00102048] 8bec mov ebp,esp
...[00001233][0010203c][000011f0] 68f0110000 push 000011f0
...[00001238][00102038][000011f0] 68f0110000 push 000011f0
...[0000123d][00102034][00001242] e8defdffff call 00001020
Begin Simulation Execution Trace Stored at:2120fc
Address_of_H:1020
...[000011f0][002120e8][002120ec] 55 push ebp
...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
...[000011f6][002120e4][000011f0] 50 push eax
...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
...[000011fa][002120e0][000011f0] 51 push ecx
...[000011fb][002120dc][00001200] e820feffff call 00001020
Infinitely Recursive Simulation Detected Simulation Stopped
...[00001242][00102040][00102048] 83c408 add esp,+08
...[00001245][00102044][00001258] 5d pop ebp
...[00001246][00102048][00000000] c3 ret
...[00001258][00102048][00000000] 33c0 xor eax,eax
...[0000125a][0010204c][00100000] 5d pop ebp
...[0000125b][00102050][00000000] c3 ret
Number of Instructions Executed(872)
Above is:
int main()
{
//Q();
R();
}
Right, so we're getting somewhere. Can you explain why Q() returns, and P(P) doesn't, when they both do the same thing in the same way?
On 6/25/2022 10:09 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:03:17 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:28 AM, olcott wrote:
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
On 6/25/2022 12:09 AM, Malcolm McLean wrote:Sorry no. I've been programming since I was a boy and I have a PhD
On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:It seems that you simply lack the technical competence.
On 6/24/2022 11:01 PM, Malcolm McLean wrote:Someone reports that tigers use more energy than they take in,
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, >>>>>>>>>>> and determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt.
He's invoked H
| on it and H reports that it doesn't halt. He's run P(P) and >>>>>>>>>> it halts.
The obvious conclusion is that PO's dry run (if he has indeed >>>>>>>>>> done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers >>>>>>>>> spend more energy
than they take in. Well potentially this is dynamite. One
explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to
rule out a much
simpler explanation. Which is that our measurements are wrong. >>>>>>>>>
Similarly, PO has worked out what he thinks P(P) should be
doing, by dry-running
it, and then actually run P(P) and obtained a different
result. He also found that H
agreed with the dry run. It's hard to paraphrase his
conclusion, but it is extensive
and far-reaching in its implications. The behaviour of code
when run is different
from the correct behaviour of the code when simulated. If
that's true, then it has
similar implications for computer science that disproving the >>>>>>>>> conservation law
has for physics.
But the obvious explanation is that the dry-run was incorrect. >>>>>>>>> Lots of people have
suggested why it is incorrect. But they can't actually see the >>>>>>>>> code. PO needs to
understand that no-one will accept the complicated,
far-reaching explanation,
until the simple explanation has been ruled out.
I already proved that the dry run is correct.
and concludes that
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some mistake. >>>>>>> How were your
measurements taken? Show us your calculations, maybe you've got
your sums wrong."
Now if they are also uncooperative about sharing the details of
the investigation,
those reservations will be magnified. There can be legitimate
reasons. Tigers are
rare and need to be conserved, you can't let anyone who wants
have access to the
tigers to try to repeat the measurements. But there's also a
common illegitimate
reason put forwards by people who make extraordinary claims. If
the claims were
unexceptional, such as that tigers have a similar energy budget
to lions, then no-one
would be saying "Show me your notebooks. How do you know that
calorimeter was
calibrated accurately? What's the name of the person who took
that measurement
and can I interview them?" Extraordinary claims are put through
the wringer in a way
that ordinary ones are not. I've seen complaints about this from >>>>>>> parapsychologists.
But if you're going to claim to have discovered a new physical
principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest explanations
for its behaviour.
Go back and look at my proof again.
in a computational-
related subject. I'm confident of my technical abilities. What I
can't do of course
is tell you exactly what is going on in code I cannot see. I've
got a pretty good idea,
but I can only reconstruct on the basis of what you tell me. Ben
thinks that I've
got it wrong and in fact there are no nested emulations at all.
I've no way of actually
disproving that idea without seeing H.
To fully understand this a software engineer must be an expert in:
(a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86 assembly
language level.
Anyone having the above credentials can validate my work, if you
cannot validate my work then you do not sufficiently have the above
credentials.
Exactly how C translates into x86 is mandatory. If you don't know
how the C calling conventions are implemented in x86 you cannot
validate my work.
From a purely software engineering perspective H(P,P) is required
to to correctly determine that its correct and complete x86
emulation of its input would never reach the "ret" instruction of
this input and H must do this in a finite number of steps.
The ordinary semantics of standard C and the conventional x86
language are the entire semantics required to conclusively prove
that H(P,P) does correctly determine that its correct and complete
x86 emulation of its input would never reach the "ret" instruction
(final state) of this input thus never halts.
The correct and complete x86 emulation of its input by H(P,P) would
never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely nested emulation.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01) 55 push ebp
[00001203](02) 8bec mov ebp,esp
[00001205](03) 8b4508 mov eax,[ebp+08]
[00001208](01) 50 push eax
[00001209](03) 8b4d08 mov ecx,[ebp+08]
[0000120c](01) 51 push ecx
[0000120d](05) e820feffff call 00001032
[00001212](03) 83c408 add esp,+08
[00001215](02) 85c0 test eax,eax
[00001217](02) 7402 jz 0000121b
[00001219](02) ebfe jmp 00001219
[0000121b](01) 5d pop ebp
[0000121c](01) c3 ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01) 55 push ebp
[00001223](02) 8bec mov ebp,esp
[00001225](05) 6802120000 push 00001202
[0000122a](05) 6802120000 push 00001202
[0000122f](05) e8fefdffff call 00001032
[00001234](03) 83c408 add esp,+08
[00001237](01) 50 push eax
[00001238](05) 68b3030000 push 000003b3
[0000123d](05) e8c0f1ffff call 00000402
[00001242](03) 83c408 add esp,+08
[00001245](02) 33c0 xor eax,eax
[00001247](01) 5d pop ebp
[00001248](01) c3 ret
Size in bytes:(0039) [00001248]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001222][0010200f][00000000] 55 push ebp
[00001223][0010200f][00000000] 8bec mov ebp,esp
[00001225][0010200b][00001202] 6802120000 push 00001202 // push P
[0000122a][00102007][00001202] 6802120000 push 00001202 // push P
[0000122f][00102003][00001234] e8fefdffff call 00001032 // call
executed H
Begin Simulation Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55 push ebp
[00001203][002120af][002120b3] 8bec mov ebp,esp
[00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
[00001208][002120ab][00001202] 50 push eax // push P
[00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
[0000120c][002120a7][00001202] 51 push ecx // push P
[0000120d][002120a3][00001212] e820feffff call 00001032 // call
emulated H Infinitely Recursive Simulation Detected Simulation
Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.
When you know that H simply implements the above algorithm there is
no need to see its source code. I am reserving the publication of the
5 pages of the source code of the halt decider for journal
publication.
Your H is not a pure function as it behaves differently depending on
what is invoking it (it returns a decision answer to main() but not
to P()) and it has side effects (aborting a simulation).
/Flibble
Finally a critique that has a reasonable basis.
When I transformed H into a pure function of its inputs it always has
the same behavior no matter how it is invoked.
The x86 emulation of P is aborted before P invokes H.
On 6/25/2022 10:59 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:54:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:21 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:19:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:09 AM, Mr Flibble wrote:Nope. Preventing a call to H is equivalent to H behaving differently
On Sat, 25 Jun 2022 10:03:17 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:28 AM, olcott wrote:
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
On 6/25/2022 12:09 AM, Malcolm McLean wrote:Sorry no. I've been programming since I was a boy and I have a >>>>>>>>> PhD in a computational-
On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote: >>>>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:It seems that you simply lack the technical competence.
Someone reports that tigers use more energy than they take >>>>>>>>>>> in, and concludes thatOn Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse >>>>>>>>>>>>> wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the >>>>>>>>>>>>>>> code, and determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved: >>>>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt. >>>>>>>>>>>>>> He's invoked H
| on it and H reports that it doesn't halt. He's run P(P) >>>>>>>>>>>>>> and it halts.
The obvious conclusion is that PO's dry run (if he has >>>>>>>>>>>>>> indeed done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that >>>>>>>>>>>>> tigers spend more energy
than they take in. Well potentially this is dynamite. One >>>>>>>>>>>>> explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to >>>>>>>>>>>>> rule out a much
simpler explanation. Which is that our measurements are >>>>>>>>>>>>> wrong.
Similarly, PO has worked out what he thinks P(P) should be >>>>>>>>>>>>> doing, by dry-running
it, and then actually run P(P) and obtained a different >>>>>>>>>>>>> result. He also found that H
agreed with the dry run. It's hard to paraphrase his >>>>>>>>>>>>> conclusion, but it is extensive
and far-reaching in its implications. The behaviour of code >>>>>>>>>>>>> when run is different
from the correct behaviour of the code when simulated. If >>>>>>>>>>>>> that's true, then it has
similar implications for computer science that disproving >>>>>>>>>>>>> the conservation law
has for physics.
But the obvious explanation is that the dry-run was
incorrect. Lots of people have
suggested why it is incorrect. But they can't actually see >>>>>>>>>>>>> the code. PO needs to
understand that no-one will accept the complicated,
far-reaching explanation,
until the simple explanation has been ruled out.
I already proved that the dry run is correct.
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some
mistake. How were your
measurements taken? Show us your calculations, maybe you've >>>>>>>>>>> got your sums wrong."
Now if they are also uncooperative about sharing the details >>>>>>>>>>> of the investigation,
those reservations will be magnified. There can be legitimate >>>>>>>>>>> reasons. Tigers are
rare and need to be conserved, you can't let anyone who wants >>>>>>>>>>> have access to the
tigers to try to repeat the measurements. But there's also a >>>>>>>>>>> common illegitimate
reason put forwards by people who make extraordinary claims. >>>>>>>>>>> If the claims were
unexceptional, such as that tigers have a similar energy >>>>>>>>>>> budget to lions, then no-one
would be saying "Show me your notebooks. How do you know that >>>>>>>>>>> calorimeter was
calibrated accurately? What's the name of the person who took >>>>>>>>>>> that measurement
and can I interview them?" Extraordinary claims are put
through the wringer in a way
that ordinary ones are not. I've seen complaints about this >>>>>>>>>>> from parapsychologists.
But if you're going to claim to have discovered a new
physical principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest
explanations for its behaviour.
Go back and look at my proof again.
related subject. I'm confident of my technical abilities. What >>>>>>>>> I can't do of course
is tell you exactly what is going on in code I cannot see. I've >>>>>>>>> got a pretty good idea,
but I can only reconstruct on the basis of what you tell me. >>>>>>>>> Ben thinks that I've
got it wrong and in fact there are no nested emulations at all. >>>>>>>>> I've no way of actually
disproving that idea without seeing H.
To fully understand this a software engineer must be an expert >>>>>>>> in: (a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86
assembly language level.
Anyone having the above credentials can validate my work, if you >>>>>>>> cannot validate my work then you do not sufficiently have the
above credentials.
Exactly how C translates into x86 is mandatory. If you don't
know how the C calling conventions are implemented in x86 you
cannot validate my work.
From a purely software engineering perspective H(P,P) is >>>>>>>> required to to correctly determine that its correct and complete >>>>>>>> x86 emulation of its input would never reach the "ret"
instruction of this input and H must do this in a finite number >>>>>>>> of steps.
The ordinary semantics of standard C and the conventional x86
language are the entire semantics required to conclusively prove >>>>>>>> that H(P,P) does correctly determine that its correct and
complete x86 emulation of its input would never reach the "ret" >>>>>>>> instruction (final state) of this input thus never halts.
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and >>>>>>>> P would remain stuck in infinitely nested emulation.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01) 55 push ebp
[00001203](02) 8bec mov ebp,esp
[00001205](03) 8b4508 mov eax,[ebp+08]
[00001208](01) 50 push eax
[00001209](03) 8b4d08 mov ecx,[ebp+08]
[0000120c](01) 51 push ecx
[0000120d](05) e820feffff call 00001032
[00001212](03) 83c408 add esp,+08
[00001215](02) 85c0 test eax,eax
[00001217](02) 7402 jz 0000121b
[00001219](02) ebfe jmp 00001219
[0000121b](01) 5d pop ebp
[0000121c](01) c3 ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01) 55 push ebp
[00001223](02) 8bec mov ebp,esp
[00001225](05) 6802120000 push 00001202
[0000122a](05) 6802120000 push 00001202
[0000122f](05) e8fefdffff call 00001032
[00001234](03) 83c408 add esp,+08
[00001237](01) 50 push eax
[00001238](05) 68b3030000 push 000003b3
[0000123d](05) e8c0f1ffff call 00000402
[00001242](03) 83c408 add esp,+08
[00001245](02) 33c0 xor eax,eax
[00001247](01) 5d pop ebp
[00001248](01) c3 ret
Size in bytes:(0039) [00001248]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>> [00001222][0010200f][00000000] 55 push ebp
[00001223][0010200f][00000000] 8bec mov ebp,esp
[00001225][0010200b][00001202] 6802120000 push 00001202 // push >>>>>>>> P [0000122a][00102007][00001202] 6802120000 push 00001202 //
push P [0000122f][00102003][00001234] e8fefdffff call 00001032 >>>>>>>> // call executed H
Begin Simulation Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55 push ebp
[00001203][002120af][002120b3] 8bec mov ebp,esp
[00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08] >>>>>>>> [00001208][002120ab][00001202] 50 push eax // push
P [00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08] >>>>>>>> [0000120c][002120a7][00001202] 51 push ecx // push
P [0000120d][002120a3][00001212] e820feffff call 00001032 //
call emulated H Infinitely Recursive Simulation Detected
Simulation Stopped
H knows its own machine address and on this basis it can easily >>>>>>>> examine its stored execution_trace of P (see above) to
determine: (a) P is calling H with the same arguments that H
was called with. (b) No instructions in P could possibly escape >>>>>>>> this otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is
emulated.
When you know that H simply implements the above algorithm there >>>>>>> is no need to see its source code. I am reserving the
publication of the 5 pages of the source code of the halt
decider for journal publication.
Your H is not a pure function as it behaves differently depending
on what is invoking it (it returns a decision answer to main()
but not to P()) and it has side effects (aborting a simulation).
/Flibble
Finally a critique that has a reasonable basis.
When I transformed H into a pure function of its inputs it always
has the same behavior no matter how it is invoked.
The x86 emulation of P is aborted before P invokes H.
for same inputs. Aborting a simulation is a side effect: pure
functions do not have side effects.
/Flibble
In other words you are saying that a halt decider is simply not
allowed to report when it correctly detects that it is being called
in infinitely recursive simulation.
I keep telling you this: the infinite recursion is NOT present when
using a valid halt decider: your H is NOT a valid halt
decider.
Simulation is an erroneous approach as a simulating halt decider
can not answer in finite time for a non-halting input as there is no
proven general solution for detecting non-halting behaviour.
/Flibble
IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY YOU
DENY THIS VERIFIABLE FACT:
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and
P would remain stuck in infinitely nested emulation.
On Saturday, June 25, 2022 at 5:29:33 PM UTC+1, olcott wrote:emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
On 6/25/2022 11:19 AM, Paul N wrote:
On Saturday, June 25, 2022 at 3:10:50 PM UTC+1, olcott wrote:
On 6/25/2022 6:56 AM, Paul N wrote:
On Friday, June 24, 2022 at 9:27:27 PM UTC+1, olcott wrote:
On 6/24/2022 3:05 PM, Paul N wrote:
On Friday, June 24, 2022 at 7:52:22 PM UTC+1, olcott wrote:
On 6/22/2022 9:23 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote: >>>>>>>>>> On 6/22/2022 8:44 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
On 6/22/2022 4:53 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
On 6/22/2022 4:20 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct
olcott <No...@NoWhere.com> wrote:If you are competent then you already know this is true and lie about it:
On 6/22/2022 2:31 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500 >>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P)); >>>>>>>>>>>>>>>>>>>>>>>> }
_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02 >>>>>>>>>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08 >>>>>>>>>>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax >>>>>>>>>>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb >>>>>>>>>>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9 >>>>>>>>>>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec] >>>>>>>>>>>>>>>>>>>>>>>>
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P)
by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP >>>>>>>>>>>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack >>>>>>>>>>>>>>>>>>>>>>>> u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly >>>>>>>>>>>>>>>>>>>>>>>> address address data code language >>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= ============= >>>>>>>>>>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp >>>>>>>>>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P >>>>>>>>>>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P >>>>>>>>>>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17 >>>>>>>>>>>>>>>>>>>>>>>> u32 code_end = get_code_end(P); >>>>>>>>>>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code)); >>>>>>>>>>>>>>>>>>>>>>>> Registers* master_state = (Registers*) >>>>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
Registers* slave_state = (Registers*) >>>>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k; >>>>>>>>>>>>>>>>>>>>>>>> u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) >>>>>>>>>>>>>>>>>>>>>>>> * 1000);
__asm lea eax, HERE // 2022-06-18 >>>>>>>>>>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18 >>>>>>>>>>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18 >>>>>>>>>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated >>>>>>>>>>>>>>>>>>>>>>>> }
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine: >>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation. >>>>>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs. >>>>>>>>>>>>>>>>>>>>>>>>
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234) >>>>>>>>>>>>>>>>>>>>>>>>
The "ret" instruction of P is its final state. >>>>>>>>>>>>>>>>>>>>>>>>
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320) >>>>>>>>>>>>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>>>>>>>>>>>>> }
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax >>>>>>>>>>>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp >>>>>>>>>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret >>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120) >>>>>>>>>>>>>>>>>>>>>>>
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software
engineering not meeting these specs: >>>>>>>>>>>>>>>>>>>>>>
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly
language level. No knowledge of the halting problem is required.
I cannot speak for Richard but I have 30+ years C++ experience; I also
have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
emulator in 80286 assembly) and I can recognize an infinite recursion;
the problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based
omnishambles:
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>>>>>
UTM(P,P), would do. And it fails to do that.You just said that H(P,P) cannot correctly predict that the correct and_Infinite_Loop()I never claimed that H(P,P) performs a complete and correct emulation ofYour entire basis and all of assumptions was incorrect so when ISo you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of Px because both H and Px
would remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>>>
provided an infallible one to that cannot possibly be correctly refuted
you simply dodged it. That is a smart move for a dishonest person that
is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my
airtight correct reasoning. Another dodge will be construed as a tacit
admission of defeat.
As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
its input so your rebuttal is the strawman deception. >>>>>>>>>>>>>>
I claimed that H(P,P) correctly predicts that its complete and correct
x86 emulation of its input would never reach the "ret" instruction of P.
But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning because H
*can't* do a correct and complete emulation of its input, H cannot >>>>>>>>>>>> possibly determine that _Infinite_Loop() never halts.
Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B
complete x86 emulation of its input would never reach the "ret" >>>>>>>>>> instruction of P without a compete x86 emulation of its input. I just
proved that is a very stupid thing to say.
You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.e.
includes emulating the call to H, that this call to H would start emulating the call to P, etc, etc, and so the call to P does not terminate.From a purely software engineering perspective H(P,P) is required to to
correctly determine that its correct and complete x86 emulation of its >>>>>>>> input would never reach the "ret" instruction of this input and H must >>>>>>>> do this in a finite number of steps.
The ordinary semantics of standard C and the conventional x86 language >>>>>>>> are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its >>>>>>>> input would never reach the "ret" instruction.
That you disagree with easily verified software engineering when you >>>>>>>> already know that this software engineering is correct speaks loads >>>>>>>> about your character.
The only computer science that need be added to this is that the "ret" >>>>>>>> instruction is the final state of P and that a sequence of
configurations that cannot possibly reach its final state is a >>>>>>>> non-halting sequence.
You say that "H(P,P) is required to to correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction of this input". You seem to be assuming that H does an emulation of P, that this emulation
int main()Yes they both return.Thanks for continuing to review this.
No assumptions two years of software development derived fully
operational software that conclusively proves this.
It might help people's understanding if we had a few more examples. Suppose, in addition to the normal P and H, we have two more functions as follows:
void Q(void)
{
if (H(P, P))
H2: goto H2;
return;
}
void R(void)
{
H(P, P);
return;
}
Will Q return? Will R return?
void Q(void)
{
if (H(P, P))
H2: goto H2;
return;
}
void R(void)
{
H(P, P);
return;
}
_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]
_Q()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) 68f0110000 push 000011f0
[0000121d](05) e8fefdffff call 00001020
[00001222](03) 83c408 add esp,+08
[00001225](02) 85c0 test eax,eax
[00001227](02) 7402 jz 0000122b
[00001229](02) ebfe jmp 00001229
[0000122b](01) 5d pop ebp
[0000122c](01) c3 ret
Size in bytes:(0029) [0000122c]
_main()
[00001250](01) 55 push ebp
[00001251](02) 8bec mov ebp,esp
[00001253](05) e8b8ffffff call 00001210
[00001258](02) 33c0 xor eax,eax
[0000125a](01) 5d pop ebp
[0000125b](01) c3 ret
Size in bytes:(0012) [0000125b]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001250][00102048][00000000] 55 push ebp
...[00001251][00102048][00000000] 8bec mov ebp,esp
...[00001253][00102044][00001258] e8b8ffffff call 00001210
...[00001210][00102040][00102048] 55 push ebp
...[00001211][00102040][00102048] 8bec mov ebp,esp
...[00001213][0010203c][000011f0] 68f0110000 push 000011f0
...[00001218][00102038][000011f0] 68f0110000 push 000011f0
...[0000121d][00102034][00001222] e8fefdffff call 00001020
Begin Simulation Execution Trace Stored at:2120fc
Address_of_H:1020
...[000011f0][002120e8][002120ec] 55 push ebp
...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
...[000011f6][002120e4][000011f0] 50 push eax
...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
...[000011fa][002120e0][000011f0] 51 push ecx
...[000011fb][002120dc][00001200] e820feffff call 00001020
Infinitely Recursive Simulation Detected Simulation Stopped
...[00001222][00102040][00102048] 83c408 add esp,+08
...[00001225][00102040][00102048] 85c0 test eax,eax
...[00001227][00102040][00102048] 7402 jz 0000122b
...[0000122b][00102044][00001258] 5d pop ebp
...[0000122c][00102048][00000000] c3 ret
...[00001258][00102048][00000000] 33c0 xor eax,eax
...[0000125a][0010204c][00100000] 5d pop ebp
...[0000125b][00102050][00000000] c3 ret
Number of Instructions Executed(874)
Above is:
int main()
{
Q();
//R();
}
---
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001250][00102048][00000000] 55 push ebp
...[00001251][00102048][00000000] 8bec mov ebp,esp
...[00001253][00102044][00001258] e8d8ffffff call 00001230
...[00001230][00102040][00102048] 55 push ebp
...[00001231][00102040][00102048] 8bec mov ebp,esp
...[00001233][0010203c][000011f0] 68f0110000 push 000011f0
...[00001238][00102038][000011f0] 68f0110000 push 000011f0
...[0000123d][00102034][00001242] e8defdffff call 00001020
Begin Simulation Execution Trace Stored at:2120fc
Address_of_H:1020
...[000011f0][002120e8][002120ec] 55 push ebp
...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
...[000011f6][002120e4][000011f0] 50 push eax
...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
...[000011fa][002120e0][000011f0] 51 push ecx
...[000011fb][002120dc][00001200] e820feffff call 00001020
Infinitely Recursive Simulation Detected Simulation Stopped
...[00001242][00102040][00102048] 83c408 add esp,+08
...[00001245][00102044][00001258] 5d pop ebp
...[00001246][00102048][00000000] c3 ret
...[00001258][00102048][00000000] 33c0 xor eax,eax
...[0000125a][0010204c][00100000] 5d pop ebp
...[0000125b][00102050][00000000] c3 ret
Number of Instructions Executed(872)
Above is:
int main()
{
//Q();
R();
}
Right, so we're getting somewhere. Can you explain why Q() returns, and P(P) doesn't, when they both do the same thing in the same way?
{
P(P);
}
does return.
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and
P would remain stuck in infinitely nested emulation.
These last two statements of yours are a contradiction.
If P(P) returns, then a CORRECT emulation of it will reach the ret instruction. An emulation that runs forever, when P(P) does not, is not a correct emulation.
I think your difficulty is that you are, perhaps unintentionally, shifting ground as regards H. Suppose we have two attempted halt deciders, H1 and H2. H1 is very simple, it just emulates the input and reports if and when it stops. H1 will work for anyhalting program but will not work for any non-halting program. If we have P call H1, and try to calculate H1(P, P), it will run forever and we'll never get an answer. Suppose that H2 is more sophisticated and can detect infinite loops. It would be
For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
Yes, that's exactly what we have been trying to explain to you.
On 6/25/2022 11:25 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 11:06:12 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:59 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:54:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:21 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:19:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:09 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:03:17 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:28 AM, olcott wrote:
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote: >>>>>>>>>>
On 6/25/2022 12:09 AM, Malcolm McLean wrote:Sorry no. I've been programming since I was a boy and I
On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcottIt seems that you simply lack the technical competence. >>>>>>>>>>> Go back and look at my proof again.
wrote:
On 6/24/2022 11:01 PM, Malcolm McLean wrote:Someone reports that tigers use more energy than they >>>>>>>>>>>> take in, and concludes that
On Friday, 24 June 2022 at 23:16:30 UTC+1, BenI already proved that the dry run is correct.
Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>>>>>>>>>>>>Exactly.
"Dry run" means that a human programmer looks at the >>>>>>>>>>>>>>>> code, and determinesGoing back, now, to what you think needs to be >>>>>>>>>>>>>>> resolved: | He's dry-run P(P) and established that it >>>>>>>>>>>>>>> doesn't halt. He's invoked H
what it does, without actually executing it. >>>>>>>>>>>>>>>
| on it and H reports that it doesn't halt. He's run >>>>>>>>>>>>>>> P(P) and it halts.
The obvious conclusion is that PO's dry run (if he has >>>>>>>>>>>>>>> indeed done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that >>>>>>>>>>>>>> tigers spend more energy
than they take in. Well potentially this is dynamite. >>>>>>>>>>>>>> One explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need >>>>>>>>>>>>>> to rule out a much
simpler explanation. Which is that our measurements are >>>>>>>>>>>>>> wrong.
Similarly, PO has worked out what he thinks P(P) should >>>>>>>>>>>>>> be doing, by dry-running
it, and then actually run P(P) and obtained a different >>>>>>>>>>>>>> result. He also found that H
agreed with the dry run. It's hard to paraphrase his >>>>>>>>>>>>>> conclusion, but it is extensive
and far-reaching in its implications. The behaviour of >>>>>>>>>>>>>> code when run is different
from the correct behaviour of the code when simulated. >>>>>>>>>>>>>> If that's true, then it has
similar implications for computer science that
disproving the conservation law
has for physics.
But the obvious explanation is that the dry-run was >>>>>>>>>>>>>> incorrect. Lots of people have
suggested why it is incorrect. But they can't actually >>>>>>>>>>>>>> see the code. PO needs to
understand that no-one will accept the complicated, >>>>>>>>>>>>>> far-reaching explanation,
until the simple explanation has been ruled out. >>>>>>>>>>>>>
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some >>>>>>>>>>>> mistake. How were your
measurements taken? Show us your calculations, maybe >>>>>>>>>>>> you've got your sums wrong."
Now if they are also uncooperative about sharing the >>>>>>>>>>>> details of the investigation,
those reservations will be magnified. There can be
legitimate reasons. Tigers are
rare and need to be conserved, you can't let anyone who >>>>>>>>>>>> wants have access to the
tigers to try to repeat the measurements. But there's >>>>>>>>>>>> also a common illegitimate
reason put forwards by people who make extraordinary >>>>>>>>>>>> claims. If the claims were
unexceptional, such as that tigers have a similar energy >>>>>>>>>>>> budget to lions, then no-one
would be saying "Show me your notebooks. How do you know >>>>>>>>>>>> that calorimeter was
calibrated accurately? What's the name of the person who >>>>>>>>>>>> took that measurement
and can I interview them?" Extraordinary claims are put >>>>>>>>>>>> through the wringer in a way
that ordinary ones are not. I've seen complaints about >>>>>>>>>>>> this from parapsychologists.
But if you're going to claim to have discovered a new >>>>>>>>>>>> physical principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest
explanations for its behaviour.
have a PhD in a computational-
related subject. I'm confident of my technical abilities. >>>>>>>>>> What I can't do of course
is tell you exactly what is going on in code I cannot see. >>>>>>>>>> I've got a pretty good idea,
but I can only reconstruct on the basis of what you tell >>>>>>>>>> me. Ben thinks that I've
got it wrong and in fact there are no nested emulations at >>>>>>>>>> all. I've no way of actually
disproving that idea without seeing H.
To fully understand this a software engineer must be an
expert in: (a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86 >>>>>>>>> assembly language level.
Anyone having the above credentials can validate my work, if >>>>>>>>> you cannot validate my work then you do not sufficiently
have the above credentials.
Exactly how C translates into x86 is mandatory. If you don't >>>>>>>>> know how the C calling conventions are implemented in x86
you cannot validate my work.
From a purely software engineering perspective H(P,P) >>>>>>>>> is required to to correctly determine that its correct and >>>>>>>>> complete x86 emulation of its input would never reach the
"ret" instruction of this input and H must do this in a
finite number of steps.
The ordinary semantics of standard C and the conventional
x86 language are the entire semantics required to
conclusively prove that H(P,P) does correctly determine
that its correct and complete x86 emulation of its input
would never reach the "ret" instruction (final state) of
this input thus never halts.
The correct and complete x86 emulation of its input by
H(P,P) would never reach the "ret" instruction of P because >>>>>>>>> both H and P would remain stuck in infinitely nested
emulation.
void P(u32 x)
{
� if (H(x, x))
��� HERE: goto HERE;
� return;
}
int main()
{
� Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01)� 55������������� push ebp
[00001203](02)� 8bec����������� mov ebp,esp
[00001205](03)� 8b4508��������� mov eax,[ebp+08]
[00001208](01)� 50������������� push eax
[00001209](03)� 8b4d08��������� mov ecx,[ebp+08]
[0000120c](01)� 51������������� push ecx
[0000120d](05)� e820feffff����� call 00001032
[00001212](03)� 83c408��������� add esp,+08
[00001215](02)� 85c0����������� test eax,eax
[00001217](02)� 7402����������� jz 0000121b
[00001219](02)� ebfe����������� jmp 00001219
[0000121b](01)� 5d������������� pop ebp
[0000121c](01)� c3������������� ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01)� 55������������� push ebp
[00001223](02)� 8bec����������� mov ebp,esp
[00001225](05)� 6802120000����� push 00001202
[0000122a](05)� 6802120000����� push 00001202
[0000122f](05)� e8fefdffff����� call 00001032
[00001234](03)� 83c408��������� add esp,+08
[00001237](01)� 50������������� push eax
[00001238](05)� 68b3030000����� push 000003b3
[0000123d](05)� e8c0f1ffff����� call 00000402
[00001242](03)� 83c408��������� add esp,+08
[00001245](02)� 33c0����������� xor eax,eax
[00001247](01)� 5d������������� pop ebp
[00001248](01)� c3������������� ret
Size in bytes:(0039) [00001248]
�machine�� stack���� stack���� machine��� assembly
�address�� address�� data����� code������ language
�========� ========� ========� =========� ============= >>>>>>>>> [00001222][0010200f][00000000] 55�������� push ebp
[00001223][0010200f][00000000] 8bec������ mov ebp,esp
[00001225][0010200b][00001202] 6802120000 push 00001202 // >>>>>>>>> push P [0000122a][00102007][00001202] 6802120000 push
00001202 // push P [0000122f][00102003][00001234] e8fefdffff >>>>>>>>> call 00001032 // call executed H
Begin Simulation�� Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55�������� push ebp
[00001203][002120af][002120b3] 8bec������ mov ebp,esp
[00001205][002120af][002120b3] 8b4508���� mov eax,[ebp+08] >>>>>>>>> [00001208][002120ab][00001202] 50�������� push eax����� // >>>>>>>>> push P [00001209][002120ab][00001202] 8b4d08���� mov
ecx,[ebp+08] [0000120c][002120a7][00001202] 51�������� push >>>>>>>>> ecx����� // push P [0000120d][002120a3][00001212] e820feffff >>>>>>>>> call 00001032 // call emulated H Infinitely Recursive
Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can
easily examine its stored execution_trace of P (see above) >>>>>>>>> to determine: (a) P is calling H with the same arguments
that H was called with. (b) No instructions in P could
possibly escape this otherwise infinitely recursive
emulation. (c) H aborts its emulation of P before its call >>>>>>>>> to H is emulated.
When you know that H simply implements the above algorithm
there is no need to see its source code. I am reserving the
publication of the 5 pages of the source code of the halt
decider for journal publication.
Your H is not a pure function as it behaves differently
depending on what is invoking it (it returns a decision answer >>>>>>> to main() but not to P()) and it has side effects (aborting a
simulation).
/Flibble
Finally a critique that has a reasonable basis.
When I transformed H into a pure function of its inputs it
always has the same behavior no matter how it is invoked.
The x86 emulation of P is aborted before P invokes H.
Nope. Preventing a call to H is equivalent to H behaving
differently for same inputs. Aborting a simulation is a side
effect: pure functions do not have side effects.
/Flibble
In other words you are saying that a halt decider is simply not
allowed to report when it correctly detects that it is being
called in infinitely recursive simulation.
I keep telling you this: the infinite recursion is NOT present
when using a valid halt decider: your H is NOT a valid halt
decider.
Simulation is an erroneous approach as a simulating halt decider
can not answer in finite time for a non-halting input as there is
no proven general solution for detecting non-halting behaviour.
/Flibble
IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY
YOU DENY THIS VERIFIABLE FACT:
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and
P would remain stuck in infinitely nested emulation.
For [Strachey 1965] (and the proofs based on it) H is NOT a
simulating halt decider so there is no infinite recursion as there
is no emulation.
Valid halt deciders ANALYSE P, they do not EMULATE P.
/Flibble
I provide a halt decider H that gets the right answer and your
rebuttal is that H does not get the right answer because there is
another different halt decider named H1 that gets the wrong answer.
On Saturday, June 25, 2022 at 6:52:33 PM UTC+1, olcott wrote:emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
On 6/25/2022 12:21 PM, Paul N wrote:
On Saturday, June 25, 2022 at 5:29:33 PM UTC+1, olcott wrote:
On 6/25/2022 11:19 AM, Paul N wrote:
On Saturday, June 25, 2022 at 3:10:50 PM UTC+1, olcott wrote:
On 6/25/2022 6:56 AM, Paul N wrote:
On Friday, June 24, 2022 at 9:27:27 PM UTC+1, olcott wrote:
On 6/24/2022 3:05 PM, Paul N wrote:
On Friday, June 24, 2022 at 7:52:22 PM UTC+1, olcott wrote: >>>>>>>>>> On 6/22/2022 9:23 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 6/22/2022 8:44 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
On 6/22/2022 5:48 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
On 6/22/2022 4:53 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
On 6/22/2022 4:20 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500 >>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct
If you are competent then you already know this is true and lie about it:On 6/22/2022 2:31 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500 >>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P)); >>>>>>>>>>>>>>>>>>>>>>>>>> }
_P()
[000010d2](01) 55 push ebp >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx >>>>>>>>>>>>>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02 >>>>>>>>>>>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08 >>>>>>>>>>>>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax >>>>>>>>>>>>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb >>>>>>>>>>>>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9 >>>>>>>>>>>>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec] >>>>>>>>>>>>>>>>>>>>>>>>>>
Every sufficiently competent software engineer can easily verify
that the complete and correct x86 emulation of the input to H(P,P)
by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely recursive emulation.
If H does correctly determine that this is the case in a finite
number of steps then H could reject its input on this basis. Here
are the details of exactly how H does this in a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP >>>>>>>>>>>>>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack >>>>>>>>>>>>>>>>>>>>>>>>>> u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly >>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language >>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= ============= >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P >>>>>>>>>>>>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped
// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17 >>>>>>>>>>>>>>>>>>>>>>>>>> u32 code_end = get_code_end(P); >>>>>>>>>>>>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code)); >>>>>>>>>>>>>>>>>>>>>>>>>> Registers* master_state = (Registers*) >>>>>>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers)); >>>>>>>>>>>>>>>>>>>>>>>>>> Registers* slave_state = (Registers*) >>>>>>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers)); >>>>>>>>>>>>>>>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k; >>>>>>>>>>>>>>>>>>>>>>>>>> u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) >>>>>>>>>>>>>>>>>>>>>>>>>> * 1000);
__asm lea eax, HERE // 2022-06-18 >>>>>>>>>>>>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18 >>>>>>>>>>>>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18 >>>>>>>>>>>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE >>>>>>>>>>>>>>>>>>>>>>>>>> __asm mov End_Of_Code, eax >>>>>>>>>>>>>>>>>>>>>>>>>>
Output("Address_of_H:", Address_of_H); // 2022-06-11 >>>>>>>>>>>>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end,
&master_state, &slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt >>>>>>>>>>>>>>>>>>>>>>>>>> END_OF_CODE:
return 1; // Input has normally terminated >>>>>>>>>>>>>>>>>>>>>>>>>> }
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise
infinitely recursive emulation. >>>>>>>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
Technically competent software engineers may not know this computer
science:
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs. >>>>>>>>>>>>>>>>>>>>>>>>>>
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234) >>>>>>>>>>>>>>>>>>>>>>>>>>
The "ret" instruction of P is its final state. >>>>>>>>>>>>>>>>>>>>>>>>>>
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>>>>>>>>>>>>>>> }
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax >>>>>>>>>>>>>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp >>>>>>>>>>>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret >>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120) >>>>>>>>>>>>>>>>>>>>>>>>>
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically competent at software
engineering not meeting these specs: >>>>>>>>>>>>>>>>>>>>>>>>
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and
the ability to recognize infinite recursion at the x86 assembly
language level. No knowledge of the halting problem is required.
I cannot speak for Richard but I have 30+ years C++ experience; I also
have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
emulator in 80286 assembly) and I can recognize an infinite recursion;
the problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based
omnishambles:
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>>>>>>>
e. UTM(P,P), would do. And it fails to do that.You just said that H(P,P) cannot correctly predict that the correct andNow who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B_Infinite_Loop()I never claimed that H(P,P) performs a complete and correct emulation ofYour entire basis and all of assumptions was incorrect so when ISo you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of Px because both H and Px
would remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>>>>>
provided an infallible one to that cannot possibly be correctly refuted
you simply dodged it. That is a smart move for a dishonest person that
is only interested in rebuttal.
I dare you to go back to the prior post and find any error in my
airtight correct reasoning. Another dodge will be construed as a tacit
admission of defeat.
As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
its input so your rebuttal is the strawman deception. >>>>>>>>>>>>>>>>
I claimed that H(P,P) correctly predicts that its complete and correct
x86 emulation of its input would never reach the "ret" instruction of P.
But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp >>>>>>>>>>>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085 >>>>>>>>>>>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085 >>>>>>>>>>>>>> Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning because H
*can't* do a correct and complete emulation of its input, H cannot
possibly determine that _Infinite_Loop() never halts. >>>>>>>>>>>>>
complete x86 emulation of its input would never reach the "ret" >>>>>>>>>>>> instruction of P without a compete x86 emulation of its input. I just
proved that is a very stupid thing to say.
You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.
emulation includes emulating the call to H, that this call to H would start emulating the call to P, etc, etc, and so the call to P does not terminate.From a purely software engineering perspective H(P,P) is required to to
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of this input and H must
do this in a finite number of steps.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction.
That you disagree with easily verified software engineering when you >>>>>>>>>> already know that this software engineering is correct speaks loads >>>>>>>>>> about your character.
The only computer science that need be added to this is that the "ret"
instruction is the final state of P and that a sequence of >>>>>>>>>> configurations that cannot possibly reach its final state is a >>>>>>>>>> non-halting sequence.
You say that "H(P,P) is required to to correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction of this input". You seem to be assuming that H does an emulation of P, that this
int main()Yes they both return.Thanks for continuing to review this.
No assumptions two years of software development derived fully >>>>>>>> operational software that conclusively proves this.
It might help people's understanding if we had a few more examples. Suppose, in addition to the normal P and H, we have two more functions as follows:
void Q(void)
{
if (H(P, P))
H2: goto H2;
return;
}
void R(void)
{
H(P, P);
return;
}
Will Q return? Will R return?
void Q(void)
{
if (H(P, P))
H2: goto H2;
return;
}
void R(void)
{
H(P, P);
return;
}
_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]
_Q()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) 68f0110000 push 000011f0
[0000121d](05) e8fefdffff call 00001020
[00001222](03) 83c408 add esp,+08
[00001225](02) 85c0 test eax,eax
[00001227](02) 7402 jz 0000122b
[00001229](02) ebfe jmp 00001229
[0000122b](01) 5d pop ebp
[0000122c](01) c3 ret
Size in bytes:(0029) [0000122c]
_main()
[00001250](01) 55 push ebp
[00001251](02) 8bec mov ebp,esp
[00001253](05) e8b8ffffff call 00001210
[00001258](02) 33c0 xor eax,eax
[0000125a](01) 5d pop ebp
[0000125b](01) c3 ret
Size in bytes:(0012) [0000125b]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001250][00102048][00000000] 55 push ebp
...[00001251][00102048][00000000] 8bec mov ebp,esp
...[00001253][00102044][00001258] e8b8ffffff call 00001210
...[00001210][00102040][00102048] 55 push ebp
...[00001211][00102040][00102048] 8bec mov ebp,esp
...[00001213][0010203c][000011f0] 68f0110000 push 000011f0
...[00001218][00102038][000011f0] 68f0110000 push 000011f0
...[0000121d][00102034][00001222] e8fefdffff call 00001020
Begin Simulation Execution Trace Stored at:2120fc
Address_of_H:1020
...[000011f0][002120e8][002120ec] 55 push ebp
...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
...[000011f6][002120e4][000011f0] 50 push eax
...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
...[000011fa][002120e0][000011f0] 51 push ecx
...[000011fb][002120dc][00001200] e820feffff call 00001020
Infinitely Recursive Simulation Detected Simulation Stopped
...[00001222][00102040][00102048] 83c408 add esp,+08
...[00001225][00102040][00102048] 85c0 test eax,eax
...[00001227][00102040][00102048] 7402 jz 0000122b
...[0000122b][00102044][00001258] 5d pop ebp
...[0000122c][00102048][00000000] c3 ret
...[00001258][00102048][00000000] 33c0 xor eax,eax
...[0000125a][0010204c][00100000] 5d pop ebp
...[0000125b][00102050][00000000] c3 ret
Number of Instructions Executed(874)
Above is:
int main()
{
Q();
//R();
}
---
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001250][00102048][00000000] 55 push ebp
...[00001251][00102048][00000000] 8bec mov ebp,esp
...[00001253][00102044][00001258] e8d8ffffff call 00001230
...[00001230][00102040][00102048] 55 push ebp
...[00001231][00102040][00102048] 8bec mov ebp,esp
...[00001233][0010203c][000011f0] 68f0110000 push 000011f0
...[00001238][00102038][000011f0] 68f0110000 push 000011f0
...[0000123d][00102034][00001242] e8defdffff call 00001020
Begin Simulation Execution Trace Stored at:2120fc
Address_of_H:1020
...[000011f0][002120e8][002120ec] 55 push ebp
...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
...[000011f6][002120e4][000011f0] 50 push eax
...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
...[000011fa][002120e0][000011f0] 51 push ecx
...[000011fb][002120dc][00001200] e820feffff call 00001020
Infinitely Recursive Simulation Detected Simulation Stopped
...[00001242][00102040][00102048] 83c408 add esp,+08
...[00001245][00102044][00001258] 5d pop ebp
...[00001246][00102048][00000000] c3 ret
...[00001258][00102048][00000000] 33c0 xor eax,eax
...[0000125a][0010204c][00100000] 5d pop ebp
...[0000125b][00102050][00000000] c3 ret
Number of Instructions Executed(872)
Above is:
int main()
{
//Q();
R();
}
Right, so we're getting somewhere. Can you explain why Q() returns, and P(P) doesn't, when they both do the same thing in the same way?
{
P(P);
}
does return.
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and
P would remain stuck in infinitely nested emulation.
These last two statements of yours are a contradiction.
If P(P) returns, then a CORRECT emulation of it will reach the ret instruction. An emulation that runs forever, when P(P) does not, is not a correct emulation.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P)
*does correctly predict*
that its correct and complete x86 emulation of its input would never
reach the "ret" instruction (final state) of this input thus never halts.
The correct and complete x86 emulation of its input by H would never
reach the "ret" instruction of P because both H and P would remain stuck
in infinitely nested emulation.
I need reviewers like you so that I can *fine tune* my words.
If you are saying that P(P) returns, but that a correct and complete x86 emulation of P(P) does not, then I think you are going to have to change either "correct" or "emulation" to some very different word.
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior of these actual inputs.
Exactly. The actual behaviour. Not the behaviour it would have if things were different. In particular, you need to take into account H's ability to detect infinite loops.
When a simulating halt decider rejects all inputs as non-halting
whenever it correctly detects [in a finite number of steps] that its
correct and complete simulation of its input would never reach [a] final
state of this input then all [these] inputs (including pathological
inputs) are correctly decided as non-halting.
If you are fine-tuning your wording, could you do something about this passage? Having both "When" and "whenever" makes it difficult to parse.
On 6/25/2022 1:58 PM, Paul N wrote:
On Saturday, June 25, 2022 at 6:52:33 PM UTC+1, olcott wrote:
On 6/25/2022 12:21 PM, Paul N wrote:
On Saturday, June 25, 2022 at 5:29:33 PM UTC+1, olcott wrote:
On 6/25/2022 11:19 AM, Paul N wrote:
On Saturday, June 25, 2022 at 3:10:50 PM UTC+1, olcott wrote:int main()
On 6/25/2022 6:56 AM, Paul N wrote:
On Friday, June 24, 2022 at 9:27:27 PM UTC+1, olcott wrote: >>>>>>>> On 6/24/2022 3:05 PM, Paul N wrote:Yes they both return.
On Friday, June 24, 2022 at 7:52:22 PM UTC+1, olcott wrote: >>>>>>>>>Thanks for continuing to review this.
On 6/22/2022 9:23 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott >>>>>>>>>>> wrote:From a purely software engineering perspective H(P,P) is >>>>>>>>>> required to to correctly determine that its correct and
On 6/22/2022 8:44 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott >>>>>>>>>>>>> wrote:You just said that H(P,P) cannot correctly predict that >>>>>>>>>>>> the correct and complete x86 emulation of its input
On 6/22/2022 8:21 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, >>>>>>>>>>>>>>> olcott wrote:_Infinite_Loop()
On 6/22/2022 8:02 PM, Dennis Bush wrote:But since H, or more accurately Ha, *can't* do a >>>>>>>>>>>>>>> correct and complete emulation of its input, your >>>>>>>>>>>>>>> point is moot.
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, >>>>>>>>>>>>>>>>> olcott wrote:
On 6/22/2022 5:48 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, >>>>>>>>>>>>>>>>>>> olcott wrote:
Your entire basis and all of assumptions was >>>>>>>>>>>>>>>>>> incorrect so when I provided an infallible one to >>>>>>>>>>>>>>>>>> that cannot possibly be correctly refuted you >>>>>>>>>>>>>>>>>> simply dodged it. That is a smart move for a >>>>>>>>>>>>>>>>>> dishonest person that is only interested in >>>>>>>>>>>>>>>>>> rebuttal.On 6/22/2022 4:53 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM >>>>>>>>>>>>>>>>>>>>> UTC-4, olcott wrote:
On 6/22/2022 4:20 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500 >>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>H (if it was constructed correctly) is a >>>>>>>>>>>>>>>>>>>>> computation, and a computation *always* gives >>>>>>>>>>>>>>>>>>>>> the same output for a given input. So it >>>>>>>>>>>>>>>>>>>>> doesn't make sense to say what it "would" do. >>>>>>>>>>>>>>>>>>>>> It either does or does not perform a complete >>>>>>>>>>>>>>>>>>>>> and correct emulation. And because H contains >>>>>>>>>>>>>>>>>>>>> code to abort, and does abort, it does not do a >>>>>>>>>>>>>>>>>>>>> complete emulation.
If you are competent then you already know >>>>>>>>>>>>>>>>>>>>>> this is true and lie about it: Every >>>>>>>>>>>>>>>>>>>>>> sufficiently competent software engineer can >>>>>>>>>>>>>>>>>>>>>> easily verify that the complete and correct >>>>>>>>>>>>>>>>>>>>>> x86 emulation of the input to H(Px,Px) by H >>>>>>>>>>>>>>>>>>>>>> would never reach the "ret" instruction of P >>>>>>>>>>>>>>>>>>>>>> because both H and P would remain stuck in >>>>>>>>>>>>>>>>>>>>>> infinitely recursive emulation. >>>>>>>>>>>>>>>>>>>>>On 6/22/2022 2:31 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500 >>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>I cannot speak for Richard but I have 30+ >>>>>>>>>>>>>>>>>>>>>>> years C++ experience; I also have C and x86 >>>>>>>>>>>>>>>>>>>>>>> assembly experience (I once wrote a Zilog >>>>>>>>>>>>>>>>>>>>>>> Z80A CPU emulator in 80286 assembly) and I >>>>>>>>>>>>>>>>>>>>>>> can recognize an infinite recursion; the >>>>>>>>>>>>>>>>>>>>>>> problem is that you cannot recognize the fact >>>>>>>>>>>>>>>>>>>>>>> that the infinite recursion only manifests as >>>>>>>>>>>>>>>>>>>>>>> part of your invalid simulation-based >>>>>>>>>>>>>>>>>>>>>>> omnishambles:
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P)); >>>>>>>>>>>>>>>>>>>>>>>>>> }
_P()
[000010d2](01) 55 push ebp >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx >>>>>>>>>>>>>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02 >>>>>>>>>>>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08 >>>>>>>>>>>>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax >>>>>>>>>>>>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb >>>>>>>>>>>>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9 >>>>>>>>>>>>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp >>>>>>>>>>>>>>>>>>>>>>>>>> [000010ec](01) c3 ret
Size in bytes:(0027) [000010ec] >>>>>>>>>>>>>>>>>>>>>>>>>>
Every sufficiently competent software >>>>>>>>>>>>>>>>>>>>>>>>>> engineer can easily verify that the >>>>>>>>>>>>>>>>>>>>>>>>>> complete and correct x86 emulation of the >>>>>>>>>>>>>>>>>>>>>>>>>> input to H(P,P) by H would never reach the >>>>>>>>>>>>>>>>>>>>>>>>>> "ret" instruction of P because both H and >>>>>>>>>>>>>>>>>>>>>>>>>> P would remain stuck in infinitely >>>>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
If H does correctly determine that this is >>>>>>>>>>>>>>>>>>>>>>>>>> the case in a finite number of steps then >>>>>>>>>>>>>>>>>>>>>>>>>> H could reject its input on this basis. >>>>>>>>>>>>>>>>>>>>>>>>>> Here are the details of exactly how H does >>>>>>>>>>>>>>>>>>>>>>>>>> this in a finite number of steps. >>>>>>>>>>>>>>>>>>>>>>>>>>
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP >>>>>>>>>>>>>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack >>>>>>>>>>>>>>>>>>>>>>>>>> u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly >>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language >>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= >>>>>>>>>>>>>>>>>>>>>>>>>> =============
[000010d2][00211e8a][00211e8e] 55 push ebp >>>>>>>>>>>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov >>>>>>>>>>>>>>>>>>>>>>>>>> ebp,esp [000010d5][00211e8a][00211e8e] >>>>>>>>>>>>>>>>>>>>>>>>>> 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax >>>>>>>>>>>>>>>>>>>>>>>>>> // push P [000010d9][00211e86][000010d2] >>>>>>>>>>>>>>>>>>>>>>>>>> 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx >>>>>>>>>>>>>>>>>>>>>>>>>> // push P [000010dd][00211e7e][000010e2] >>>>>>>>>>>>>>>>>>>>>>>>>> e820feffff call 00000f02 // call H >>>>>>>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected >>>>>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
// actual fully operational code in the >>>>>>>>>>>>>>>>>>>>>>>>>> x86utm operating system u32 H(u32 P, u32 I) >>>>>>>>>>>>>>>>>>>>>>>>>> {
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17 >>>>>>>>>>>>>>>>>>>>>>>>>> u32 code_end = get_code_end(P); >>>>>>>>>>>>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = >>>>>>>>>>>>>>>>>>>>>>>>>> (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code)); >>>>>>>>>>>>>>>>>>>>>>>>>> Registers* master_state = (Registers*) >>>>>>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers)); Registers* >>>>>>>>>>>>>>>>>>>>>>>>>> slave_state = (Registers*) >>>>>>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers)); u32* >>>>>>>>>>>>>>>>>>>>>>>>>> slave_stack = Allocate(0x10000); // 64k; >>>>>>>>>>>>>>>>>>>>>>>>>> u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) >>>>>>>>>>>>>>>>>>>>>>>>>> * 1000);
__asm lea eax, HERE // 2022-06-18 >>>>>>>>>>>>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18 >>>>>>>>>>>>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18 >>>>>>>>>>>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE >>>>>>>>>>>>>>>>>>>>>>>>>> __asm mov End_Of_Code, eax >>>>>>>>>>>>>>>>>>>>>>>>>>
Output("Address_of_H:", Address_of_H); // >>>>>>>>>>>>>>>>>>>>>>>>>> 2022-06-11 Init_slave_state(P, I, >>>>>>>>>>>>>>>>>>>>>>>>>> End_Of_Code, slave_state, slave_stack); >>>>>>>>>>>>>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace >>>>>>>>>>>>>>>>>>>>>>>>>> Stored at:", execution_trace); if >>>>>>>>>>>>>>>>>>>>>>>>>> (Decide_Halting(&execution_trace, >>>>>>>>>>>>>>>>>>>>>>>>>> &decoded, code_end, &master_state, >>>>>>>>>>>>>>>>>>>>>>>>>> &slave_state, &slave_stack, Address_of_H, >>>>>>>>>>>>>>>>>>>>>>>>>> P, I)) goto END_OF_CODE; return 0; // Does >>>>>>>>>>>>>>>>>>>>>>>>>> not halt END_OF_CODE: return 1; // Input >>>>>>>>>>>>>>>>>>>>>>>>>> has normally terminated } >>>>>>>>>>>>>>>>>>>>>>>>>>
H knows its own machine address and on >>>>>>>>>>>>>>>>>>>>>>>>>> this basis it can easily examine its >>>>>>>>>>>>>>>>>>>>>>>>>> stored execution_trace of P and determine: >>>>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments >>>>>>>>>>>>>>>>>>>>>>>>>> that H was called with. (b) No >>>>>>>>>>>>>>>>>>>>>>>>>> instructions in P could possibly escape >>>>>>>>>>>>>>>>>>>>>>>>>> this otherwise infinitely recursive >>>>>>>>>>>>>>>>>>>>>>>>>> emulation. (c) H aborts its emulation of P >>>>>>>>>>>>>>>>>>>>>>>>>> before its call to H is invoked. >>>>>>>>>>>>>>>>>>>>>>>>>>
Technically competent software engineers >>>>>>>>>>>>>>>>>>>>>>>>>> may not know this computer science: >>>>>>>>>>>>>>>>>>>>>>>>>>
A halt decider must compute the mapping >>>>>>>>>>>>>>>>>>>>>>>>>> from its inputs to an accept or reject >>>>>>>>>>>>>>>>>>>>>>>>>> state on the basis of the actual behavior >>>>>>>>>>>>>>>>>>>>>>>>>> that is actually specified by these inputs. >>>>>>>>>>>>>>>>>>>>>>>>>>
computation that halts … the Turing >>>>>>>>>>>>>>>>>>>>>>>>>> machine will halt whenever it enters a >>>>>>>>>>>>>>>>>>>>>>>>>> final state. (Linz:1990:234) >>>>>>>>>>>>>>>>>>>>>>>>>>
The "ret" instruction of P is its final >>>>>>>>>>>>>>>>>>>>>>>>>> state.
Linz, Peter 1990. An Introduction to >>>>>>>>>>>>>>>>>>>>>>>>>> Formal Languages and Automata. >>>>>>>>>>>>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and >>>>>>>>>>>>>>>>>>>>>>>>>> Company. (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, >>>>>>>>>>>>>>>>>>>>>>>>> (u32)Px)); }
...[000013e8][00102357][00000000] 83c408 >>>>>>>>>>>>>>>>>>>>>>>>> add esp,+08
...[000013eb][00102353][00000000] 50 push >>>>>>>>>>>>>>>>>>>>>>>>> eax ...[000013ec][0010234f][00000427] >>>>>>>>>>>>>>>>>>>>>>>>> 6827040000 push 00000427
---[000013f1][0010234f][00000427] >>>>>>>>>>>>>>>>>>>>>>>>> e880f0ffff call 00000476 Input_Halts = 0 >>>>>>>>>>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 >>>>>>>>>>>>>>>>>>>>>>>>> add esp,+08
...[000013f9][00102357][00000000] 33c0 xor >>>>>>>>>>>>>>>>>>>>>>>>> eax,eax ...[000013fb][0010235b][00100000] >>>>>>>>>>>>>>>>>>>>>>>>> 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret >>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120) >>>>>>>>>>>>>>>>>>>>>>>>>
It gets the answer wrong, i.e. input has >>>>>>>>>>>>>>>>>>>>>>>>> not been decided correctly. QED. >>>>>>>>>>>>>>>>>>>>>>>>>
/Flibble
You and Richard are insufficiently >>>>>>>>>>>>>>>>>>>>>>>> technically competent at software >>>>>>>>>>>>>>>>>>>>>>>> engineering not meeting these specs: >>>>>>>>>>>>>>>>>>>>>>>>
A software engineer must be an expert in: >>>>>>>>>>>>>>>>>>>>>>>> the C programming language, the x86 >>>>>>>>>>>>>>>>>>>>>>>> programming language, exactly how C >>>>>>>>>>>>>>>>>>>>>>>> translates into x86 and the ability to >>>>>>>>>>>>>>>>>>>>>>>> recognize infinite recursion at the x86 >>>>>>>>>>>>>>>>>>>>>>>> assembly language level. No knowledge of the >>>>>>>>>>>>>>>>>>>>>>>> halting problem is required. >>>>>>>>>>>>>>>>>>>>>>>
So the input must be given to a UTM, which by >>>>>>>>>>>>>>>>>>>>> definition does a correct and complete >>>>>>>>>>>>>>>>>>>>> simulation, to see what the actual behavior is. >>>>>>>>>>>>>>>>>>>>> UTM(Px,Px) halts, therefore H(Px,Px)==0 is >>>>>>>>>>>>>>>>>>>>> wrong.
Every sufficiently competent software engineer >>>>>>>>>>>>>>>>>>>> can easily verify that the complete and correct >>>>>>>>>>>>>>>>>>>> x86 emulation of the input to H(Px,Px) by H >>>>>>>>>>>>>>>>>>>> would never reach the "ret" instruction of Px >>>>>>>>>>>>>>>>>>>> because both H and Px would remain stuck in >>>>>>>>>>>>>>>>>>>> infinitely recursive emulation.
So you just repeated what you said instead of >>>>>>>>>>>>>>>>>>> explaining why I'm wrong. In other words you >>>>>>>>>>>>>>>>>>> provided no rebuttal, which can only be taken to >>>>>>>>>>>>>>>>>>> mean that you have none.
I dare you to go back to the prior post and find >>>>>>>>>>>>>>>>>> any error in my airtight correct reasoning. >>>>>>>>>>>>>>>>>> Another dodge will be construed as a tacit >>>>>>>>>>>>>>>>>> admission of defeat.
As stated before H (or more accurately Ha) does not >>>>>>>>>>>>>>>>> perform a complete and correct emulation because it >>>>>>>>>>>>>>>>> aborts. So by definition it cannot be complete. >>>>>>>>>>>>>>>> I never claimed that H(P,P) performs a complete and >>>>>>>>>>>>>>>> correct emulation of its input so your rebuttal is >>>>>>>>>>>>>>>> the strawman deception.
I claimed that H(P,P) correctly predicts that its >>>>>>>>>>>>>>>> complete and correct x86 emulation of its input >>>>>>>>>>>>>>>> would never reach the "ret" instruction of P. >>>>>>>>>>>>>>>
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace >>>>>>>>>>>>>> Stored at:211e8f ...[00001082][00211e7f][00211e83] 55 >>>>>>>>>>>>>> push ebp ...[00001083][00211e7f][00211e83] 8bec mov >>>>>>>>>>>>>> ebp,esp ...[00001085][00211e7f][00211e83] ebfe jmp >>>>>>>>>>>>>> 00001085 ...[00001085][00211e7f][00211e83] ebfe jmp >>>>>>>>>>>>>> 00001085 Infinite Loop Detected Simulation Stopped >>>>>>>>>>>>>>
On the basis of this exact same utterly moronic
reasoning because H *can't* do a correct and complete >>>>>>>>>>>>>> emulation of its input, H cannot possibly determine >>>>>>>>>>>>>> that _Infinite_Loop() never halts.
Now who's using the strawman error? Just because H can >>>>>>>>>>>>> determine that _Infinite_Loop does not halt doesn't >>>>>>>>>>>>> mean that it gets other cases right. B
would never reach the "ret" instruction of P without a >>>>>>>>>>>> compete x86 emulation of its input. I just proved that >>>>>>>>>>>> is a very stupid thing to say.
You said that H can predict what *its* correct and
complete emulation would do, and I said that doesn't make >>>>>>>>>>> sense because H does not do correct and complete
emulation. What H *must* do is predict what *the* correct >>>>>>>>>>> and complete emulation, i.e. UTM(P,P), would do. And it >>>>>>>>>>> fails to do that.
complete x86 emulation of its input would never reach the >>>>>>>>>> "ret" instruction of this input and H must do this in a
finite number of steps.
The ordinary semantics of standard C and the conventional >>>>>>>>>> x86 language are the entire semantics required to
conclusively prove that H(P,P) does correctly determine
that its correct and complete x86 emulation of its input >>>>>>>>>> would never reach the "ret" instruction.
That you disagree with easily verified software
engineering when you already know that this software
engineering is correct speaks loads about your character. >>>>>>>>>>
The only computer science that need be added to this is
that the "ret" instruction is the final state of P and
that a sequence of configurations that cannot possibly
reach its final state is a non-halting sequence.
You say that "H(P,P) is required to to correctly determine >>>>>>>>> that its correct and complete x86 emulation of its input
would never reach the "ret" instruction of this input". You >>>>>>>>> seem to be assuming that H does an emulation of P, that
this emulation includes emulating the call to H, that this >>>>>>>>> call to H would start emulating the call to P, etc, etc,
and so the call to P does not terminate.
No assumptions two years of software development derived
fully operational software that conclusively proves this.
It might help people's understanding if we had a few more
examples. Suppose, in addition to the normal P and H, we have
two more functions as follows:
void Q(void)
{
if (H(P, P))
H2: goto H2;
return;
}
void R(void)
{
H(P, P);
return;
}
Will Q return? Will R return?
void Q(void)
{
if (H(P, P))
H2: goto H2;
return;
}
void R(void)
{
H(P, P);
return;
}
_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]
_Q()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) 68f0110000 push 000011f0
[0000121d](05) e8fefdffff call 00001020
[00001222](03) 83c408 add esp,+08
[00001225](02) 85c0 test eax,eax
[00001227](02) 7402 jz 0000122b
[00001229](02) ebfe jmp 00001229
[0000122b](01) 5d pop ebp
[0000122c](01) c3 ret
Size in bytes:(0029) [0000122c]
_main()
[00001250](01) 55 push ebp
[00001251](02) 8bec mov ebp,esp
[00001253](05) e8b8ffffff call 00001210
[00001258](02) 33c0 xor eax,eax
[0000125a](01) 5d pop ebp
[0000125b](01) c3 ret
Size in bytes:(0012) [0000125b]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001250][00102048][00000000] 55 push ebp
...[00001251][00102048][00000000] 8bec mov ebp,esp
...[00001253][00102044][00001258] e8b8ffffff call 00001210
...[00001210][00102040][00102048] 55 push ebp
...[00001211][00102040][00102048] 8bec mov ebp,esp
...[00001213][0010203c][000011f0] 68f0110000 push 000011f0
...[00001218][00102038][000011f0] 68f0110000 push 000011f0
...[0000121d][00102034][00001222] e8fefdffff call 00001020
Begin Simulation Execution Trace Stored at:2120fc
Address_of_H:1020
...[000011f0][002120e8][002120ec] 55 push ebp
...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
...[000011f6][002120e4][000011f0] 50 push eax
...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
...[000011fa][002120e0][000011f0] 51 push ecx
...[000011fb][002120dc][00001200] e820feffff call 00001020
Infinitely Recursive Simulation Detected Simulation Stopped
...[00001222][00102040][00102048] 83c408 add esp,+08
...[00001225][00102040][00102048] 85c0 test eax,eax
...[00001227][00102040][00102048] 7402 jz 0000122b
...[0000122b][00102044][00001258] 5d pop ebp
...[0000122c][00102048][00000000] c3 ret
...[00001258][00102048][00000000] 33c0 xor eax,eax
...[0000125a][0010204c][00100000] 5d pop ebp
...[0000125b][00102050][00000000] c3 ret
Number of Instructions Executed(874)
Above is:
int main()
{
Q();
//R();
}
---
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001250][00102048][00000000] 55 push ebp
...[00001251][00102048][00000000] 8bec mov ebp,esp
...[00001253][00102044][00001258] e8d8ffffff call 00001230
...[00001230][00102040][00102048] 55 push ebp
...[00001231][00102040][00102048] 8bec mov ebp,esp
...[00001233][0010203c][000011f0] 68f0110000 push 000011f0
...[00001238][00102038][000011f0] 68f0110000 push 000011f0
...[0000123d][00102034][00001242] e8defdffff call 00001020
Begin Simulation Execution Trace Stored at:2120fc
Address_of_H:1020
...[000011f0][002120e8][002120ec] 55 push ebp
...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
...[000011f6][002120e4][000011f0] 50 push eax
...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
...[000011fa][002120e0][000011f0] 51 push ecx
...[000011fb][002120dc][00001200] e820feffff call 00001020
Infinitely Recursive Simulation Detected Simulation Stopped
...[00001242][00102040][00102048] 83c408 add esp,+08
...[00001245][00102044][00001258] 5d pop ebp
...[00001246][00102048][00000000] c3 ret
...[00001258][00102048][00000000] 33c0 xor eax,eax
...[0000125a][0010204c][00100000] 5d pop ebp
...[0000125b][00102050][00000000] c3 ret
Number of Instructions Executed(872)
Above is:
int main()
{
//Q();
R();
}
Right, so we're getting somewhere. Can you explain why Q()
returns, and P(P) doesn't, when they both do the same thing in
the same way?
{
P(P);
}
does return.
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and
P would remain stuck in infinitely nested emulation.
These last two statements of yours are a contradiction.
If P(P) returns, then a CORRECT emulation of it will reach the
ret instruction. An emulation that runs forever, when P(P) does
not, is not a correct emulation.
The ordinary semantics of standard C and the conventional x86
language are the entire semantics required to conclusively prove
that H(P,P) *does correctly predict*
that its correct and complete x86 emulation of its input would
never reach the "ret" instruction (final state) of this input thus
never halts. The correct and complete x86 emulation of its input
by H would never reach the "ret" instruction of P because both H
and P would remain stuck in infinitely nested emulation.
I need reviewers like you so that I can *fine tune* my words.
If you are saying that P(P) returns, but that a correct and
complete x86 emulation of P(P) does not, then I think you are going
to have to change either "correct" or "emulation" to some very
different word.
The correct and complete emulation of the input to H(P,P) has halting behavior that is provably different than the the direct execution of
P(P).
"Common sense" tells you that they must be the same empirical proof
proves that they are not the same.
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior of
these actual inputs.
Exactly. The actual behaviour. Not the behaviour it would have if
things were different. In particular, you need to take into account
H's ability to detect infinite loops.
I initially made H robust enough that it does correctly reject
infinite loops and infinite recursion and have code samples to prove
it.
When a simulating halt decider rejects all inputs as non-halting
whenever it correctly detects [in a finite number of steps] that
its correct and complete simulation of its input would never reach
[a] final state of this input then all [these] inputs (including
pathological inputs) are correctly decided as non-halting.
If you are fine-tuning your wording, could you do something about
this passage? Having both "When" and "whenever" makes it difficult
to parse.
When a simulating halt decider correctly detects [in a finite number
of steps] that its correct and complete simulation of its input would
never reach [a] final state of this input then all [these] inputs
(including pathological inputs) are correctly rejected as non-halting.
On Sat, 25 Jun 2022 11:32:12 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 11:25 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 11:06:12 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:59 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:54:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:21 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:19:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:09 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:03:17 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:28 AM, olcott wrote:
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote: >>>>>>>>>>>>
On 6/25/2022 12:09 AM, Malcolm McLean wrote:Sorry no. I've been programming since I was a boy and I >>>>>>>>>>>> have a PhD in a computational-
On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott >>>>>>>>>>>>>> wrote:It seems that you simply lack the technical competence. >>>>>>>>>>>>> Go back and look at my proof again.
On 6/24/2022 11:01 PM, Malcolm McLean wrote:Someone reports that tigers use more energy than they >>>>>>>>>>>>>> take in, and concludes that
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben >>>>>>>>>>>>>>>> Bacarisse wrote:I already proved that the dry run is correct.
Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>>>>>>>>>>>>>>Exactly.
"Dry run" means that a human programmer looks at the >>>>>>>>>>>>>>>>>> code, and determinesGoing back, now, to what you think needs to be >>>>>>>>>>>>>>>>> resolved: | He's dry-run P(P) and established that it >>>>>>>>>>>>>>>>> doesn't halt. He's invoked H
what it does, without actually executing it. >>>>>>>>>>>>>>>>>
| on it and H reports that it doesn't halt. He's run >>>>>>>>>>>>>>>>> P(P) and it halts.
The obvious conclusion is that PO's dry run (if he has >>>>>>>>>>>>>>>>> indeed done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that >>>>>>>>>>>>>>>> tigers spend more energy
than they take in. Well potentially this is dynamite. >>>>>>>>>>>>>>>> One explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we need >>>>>>>>>>>>>>>> to rule out a much
simpler explanation. Which is that our measurements are >>>>>>>>>>>>>>>> wrong.
Similarly, PO has worked out what he thinks P(P) should >>>>>>>>>>>>>>>> be doing, by dry-running
it, and then actually run P(P) and obtained a different >>>>>>>>>>>>>>>> result. He also found that H
agreed with the dry run. It's hard to paraphrase his >>>>>>>>>>>>>>>> conclusion, but it is extensive
and far-reaching in its implications. The behaviour of >>>>>>>>>>>>>>>> code when run is different
from the correct behaviour of the code when simulated. >>>>>>>>>>>>>>>> If that's true, then it has
similar implications for computer science that >>>>>>>>>>>>>>>> disproving the conservation law
has for physics.
But the obvious explanation is that the dry-run was >>>>>>>>>>>>>>>> incorrect. Lots of people have
suggested why it is incorrect. But they can't actually >>>>>>>>>>>>>>>> see the code. PO needs to
understand that no-one will accept the complicated, >>>>>>>>>>>>>>>> far-reaching explanation,
until the simple explanation has been ruled out. >>>>>>>>>>>>>>>
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some >>>>>>>>>>>>>> mistake. How were your
measurements taken? Show us your calculations, maybe >>>>>>>>>>>>>> you've got your sums wrong."
Now if they are also uncooperative about sharing the >>>>>>>>>>>>>> details of the investigation,
those reservations will be magnified. There can be >>>>>>>>>>>>>> legitimate reasons. Tigers are
rare and need to be conserved, you can't let anyone who >>>>>>>>>>>>>> wants have access to the
tigers to try to repeat the measurements. But there's >>>>>>>>>>>>>> also a common illegitimate
reason put forwards by people who make extraordinary >>>>>>>>>>>>>> claims. If the claims were
unexceptional, such as that tigers have a similar energy >>>>>>>>>>>>>> budget to lions, then no-one
would be saying "Show me your notebooks. How do you know >>>>>>>>>>>>>> that calorimeter was
calibrated accurately? What's the name of the person who >>>>>>>>>>>>>> took that measurement
and can I interview them?" Extraordinary claims are put >>>>>>>>>>>>>> through the wringer in a way
that ordinary ones are not. I've seen complaints about >>>>>>>>>>>>>> this from parapsychologists.
But if you're going to claim to have discovered a new >>>>>>>>>>>>>> physical principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest
explanations for its behaviour.
related subject. I'm confident of my technical abilities. >>>>>>>>>>>> What I can't do of course
is tell you exactly what is going on in code I cannot see. >>>>>>>>>>>> I've got a pretty good idea,
but I can only reconstruct on the basis of what you tell >>>>>>>>>>>> me. Ben thinks that I've
got it wrong and in fact there are no nested emulations at >>>>>>>>>>>> all. I've no way of actually
disproving that idea without seeing H.
To fully understand this a software engineer must be an
expert in: (a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86 >>>>>>>>>>> assembly language level.
Anyone having the above credentials can validate my work, if >>>>>>>>>>> you cannot validate my work then you do not sufficiently >>>>>>>>>>> have the above credentials.
Exactly how C translates into x86 is mandatory. If you don't >>>>>>>>>>> know how the C calling conventions are implemented in x86 >>>>>>>>>>> you cannot validate my work.
From a purely software engineering perspective H(P,P) >>>>>>>>>>> is required to to correctly determine that its correct and >>>>>>>>>>> complete x86 emulation of its input would never reach the >>>>>>>>>>> "ret" instruction of this input and H must do this in a
finite number of steps.
The ordinary semantics of standard C and the conventional >>>>>>>>>>> x86 language are the entire semantics required to
conclusively prove that H(P,P) does correctly determine
that its correct and complete x86 emulation of its input >>>>>>>>>>> would never reach the "ret" instruction (final state) of >>>>>>>>>>> this input thus never halts.
The correct and complete x86 emulation of its input by
H(P,P) would never reach the "ret" instruction of P because >>>>>>>>>>> both H and P would remain stuck in infinitely nested
emulation.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01) 55 push ebp
[00001203](02) 8bec mov ebp,esp
[00001205](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>> [00001208](01) 50 push eax
[00001209](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>> [0000120c](01) 51 push ecx
[0000120d](05) e820feffff call 00001032
[00001212](03) 83c408 add esp,+08
[00001215](02) 85c0 test eax,eax >>>>>>>>>>> [00001217](02) 7402 jz 0000121b
[00001219](02) ebfe jmp 00001219 >>>>>>>>>>> [0000121b](01) 5d pop ebp
[0000121c](01) c3 ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01) 55 push ebp
[00001223](02) 8bec mov ebp,esp
[00001225](05) 6802120000 push 00001202
[0000122a](05) 6802120000 push 00001202
[0000122f](05) e8fefdffff call 00001032
[00001234](03) 83c408 add esp,+08
[00001237](01) 50 push eax
[00001238](05) 68b3030000 push 000003b3
[0000123d](05) e8c0f1ffff call 00000402
[00001242](03) 83c408 add esp,+08
[00001245](02) 33c0 xor eax,eax
[00001247](01) 5d pop ebp
[00001248](01) c3 ret
Size in bytes:(0039) [00001248]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>> [00001222][0010200f][00000000] 55 push ebp >>>>>>>>>>> [00001223][0010200f][00000000] 8bec mov ebp,esp >>>>>>>>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 // >>>>>>>>>>> push P [0000122a][00102007][00001202] 6802120000 push
00001202 // push P [0000122f][00102003][00001234] e8fefdffff >>>>>>>>>>> call 00001032 // call executed H
Begin Simulation Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55 push ebp >>>>>>>>>>> [00001203][002120af][002120b3] 8bec mov ebp,esp >>>>>>>>>>> [00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08] >>>>>>>>>>> [00001208][002120ab][00001202] 50 push eax //
push P [00001209][002120ab][00001202] 8b4d08 mov >>>>>>>>>>> ecx,[ebp+08] [0000120c][002120a7][00001202] 51 push >>>>>>>>>>> ecx // push P [0000120d][002120a3][00001212] e820feffff >>>>>>>>>>> call 00001032 // call emulated H Infinitely Recursive
Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can >>>>>>>>>>> easily examine its stored execution_trace of P (see above) >>>>>>>>>>> to determine: (a) P is calling H with the same arguments >>>>>>>>>>> that H was called with. (b) No instructions in P could
possibly escape this otherwise infinitely recursive
emulation. (c) H aborts its emulation of P before its call >>>>>>>>>>> to H is emulated.
When you know that H simply implements the above algorithm >>>>>>>>>> there is no need to see its source code. I am reserving the >>>>>>>>>> publication of the 5 pages of the source code of the halt
decider for journal publication.
Your H is not a pure function as it behaves differently
depending on what is invoking it (it returns a decision answer >>>>>>>>> to main() but not to P()) and it has side effects (aborting a >>>>>>>>> simulation).
/Flibble
Finally a critique that has a reasonable basis.
When I transformed H into a pure function of its inputs it
always has the same behavior no matter how it is invoked.
The x86 emulation of P is aborted before P invokes H.
Nope. Preventing a call to H is equivalent to H behaving
differently for same inputs. Aborting a simulation is a side
effect: pure functions do not have side effects.
/Flibble
In other words you are saying that a halt decider is simply not
allowed to report when it correctly detects that it is being
called in infinitely recursive simulation.
I keep telling you this: the infinite recursion is NOT present
when using a valid halt decider: your H is NOT a valid halt
decider.
Simulation is an erroneous approach as a simulating halt decider
can not answer in finite time for a non-halting input as there is
no proven general solution for detecting non-halting behaviour.
/Flibble
IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY
YOU DENY THIS VERIFIABLE FACT:
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and
P would remain stuck in infinitely nested emulation.
For [Strachey 1965] (and the proofs based on it) H is NOT a
simulating halt decider so there is no infinite recursion as there
is no emulation.
Valid halt deciders ANALYSE P, they do not EMULATE P.
/Flibble
I provide a halt decider H that gets the right answer and your
rebuttal is that H does not get the right answer because there is
another different halt decider named H1 that gets the wrong answer.
Your H also gets the wrong answer:
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 ...[000013eb][00102353][00000000] 50 push eax ...[000013ec][0010234f][00000427] 6827040000 push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 ...[000013f9][00102357][00000000] 33c0 xor eax,eax ...[000013fb][0010235b][00100000] 5d pop ebp ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
On 6/25/2022 2:12 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 11:32:12 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 11:25 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 11:06:12 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:59 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:54:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:21 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:19:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 10:09 AM, Mr Flibble wrote:
On Sat, 25 Jun 2022 10:03:17 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:28 AM, olcott wrote:
On 6/25/2022 2:32 AM, Malcolm McLean wrote:
On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott
wrote:
On 6/25/2022 12:09 AM, Malcolm McLean wrote:Sorry no. I've been programming since I was a boy and I >>>>>>>>>>>> have a PhD in a computational-
On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott >>>>>>>>>>>>>> wrote:It seems that you simply lack the technical competence. >>>>>>>>>>>>> Go back and look at my proof again.
On 6/24/2022 11:01 PM, Malcolm McLean wrote: >>>>>>>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben >>>>>>>>>>>>>>>> Bacarisse wrote:Someone reports that tigers use more energy than they >>>>>>>>>>>>>> take in, and concludes that
I already proved that the dry run is correct.Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>>>>>>>>>>>>>>Exactly.
"Dry run" means that a human programmer looks at >>>>>>>>>>>>>>>>>> the code, and determinesGoing back, now, to what you think needs to be >>>>>>>>>>>>>>>>> resolved: | He's dry-run P(P) and established that >>>>>>>>>>>>>>>>> it doesn't halt. He's invoked H
what it does, without actually executing it. >>>>>>>>>>>>>>>>>
| on it and H reports that it doesn't halt. He's run >>>>>>>>>>>>>>>>> P(P) and it halts.
The obvious conclusion is that PO's dry run (if he >>>>>>>>>>>>>>>>> has indeed done such
a thing) is incorrect.
We do our little energy budget on tigers, and find >>>>>>>>>>>>>>>> that tigers spend more energy
than they take in. Well potentially this is dynamite. >>>>>>>>>>>>>>>> One explanation is that the
law of conservation of energy is wrong.
Except, before we countenance that explanation, we >>>>>>>>>>>>>>>> need to rule out a much
simpler explanation. Which is that our measurements >>>>>>>>>>>>>>>> are wrong.
Similarly, PO has worked out what he thinks P(P) >>>>>>>>>>>>>>>> should be doing, by dry-running
it, and then actually run P(P) and obtained a >>>>>>>>>>>>>>>> different result. He also found that H
agreed with the dry run. It's hard to paraphrase his >>>>>>>>>>>>>>>> conclusion, but it is extensive
and far-reaching in its implications. The behaviour >>>>>>>>>>>>>>>> of code when run is different
from the correct behaviour of the code when
simulated. If that's true, then it has
similar implications for computer science that >>>>>>>>>>>>>>>> disproving the conservation law
has for physics.
But the obvious explanation is that the dry-run was >>>>>>>>>>>>>>>> incorrect. Lots of people have
suggested why it is incorrect. But they can't >>>>>>>>>>>>>>>> actually see the code. PO needs to
understand that no-one will accept the complicated, >>>>>>>>>>>>>>>> far-reaching explanation,
until the simple explanation has been ruled out. >>>>>>>>>>>>>>>
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some >>>>>>>>>>>>>> mistake. How were your
measurements taken? Show us your calculations, maybe >>>>>>>>>>>>>> you've got your sums wrong."
Now if they are also uncooperative about sharing the >>>>>>>>>>>>>> details of the investigation,
those reservations will be magnified. There can be >>>>>>>>>>>>>> legitimate reasons. Tigers are
rare and need to be conserved, you can't let anyone who >>>>>>>>>>>>>> wants have access to the
tigers to try to repeat the measurements. But there's >>>>>>>>>>>>>> also a common illegitimate
reason put forwards by people who make extraordinary >>>>>>>>>>>>>> claims. If the claims were
unexceptional, such as that tigers have a similar >>>>>>>>>>>>>> energy budget to lions, then no-one
would be saying "Show me your notebooks. How do you >>>>>>>>>>>>>> know that calorimeter was
calibrated accurately? What's the name of the person >>>>>>>>>>>>>> who took that measurement
and can I interview them?" Extraordinary claims are put >>>>>>>>>>>>>> through the wringer in a way
that ordinary ones are not. I've seen complaints about >>>>>>>>>>>>>> this from parapsychologists.
But if you're going to claim to have discovered a new >>>>>>>>>>>>>> physical principle, you need
to present rock solid evidence.
In this case, we can't see H. We can only suggest >>>>>>>>>>>>>> explanations for its behaviour.
related subject. I'm confident of my technical abilities. >>>>>>>>>>>> What I can't do of course
is tell you exactly what is going on in code I cannot >>>>>>>>>>>> see. I've got a pretty good idea,
but I can only reconstruct on the basis of what you tell >>>>>>>>>>>> me. Ben thinks that I've
got it wrong and in fact there are no nested emulations >>>>>>>>>>>> at all. I've no way of actually
disproving that idea without seeing H.
To fully understand this a software engineer must be an >>>>>>>>>>> expert in: (a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86 >>>>>>>>>>> assembly language level.
Anyone having the above credentials can validate my work, >>>>>>>>>>> if you cannot validate my work then you do not
sufficiently have the above credentials.
Exactly how C translates into x86 is mandatory. If you >>>>>>>>>>> don't know how the C calling conventions are implemented >>>>>>>>>>> in x86 you cannot validate my work.
From a purely software engineering perspective
H(P,P) is required to to correctly determine that its
correct and complete x86 emulation of its input would
never reach the "ret" instruction of this input and H
must do this in a finite number of steps.
The ordinary semantics of standard C and the conventional >>>>>>>>>>> x86 language are the entire semantics required to
conclusively prove that H(P,P) does correctly determine >>>>>>>>>>> that its correct and complete x86 emulation of its input >>>>>>>>>>> would never reach the "ret" instruction (final state) of >>>>>>>>>>> this input thus never halts.
The correct and complete x86 emulation of its input by >>>>>>>>>>> H(P,P) would never reach the "ret" instruction of P
because both H and P would remain stuck in infinitely
nested emulation.
void P(u32 x)
{
� if (H(x, x))
��� HERE: goto HERE;
� return;
}
int main()
{
� Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001202](01)� 55������������� push ebp
[00001203](02)� 8bec����������� mov ebp,esp
[00001205](03)� 8b4508��������� mov eax,[ebp+08]
[00001208](01)� 50������������� push eax
[00001209](03)� 8b4d08��������� mov ecx,[ebp+08]
[0000120c](01)� 51������������� push ecx
[0000120d](05)� e820feffff����� call 00001032
[00001212](03)� 83c408��������� add esp,+08
[00001215](02)� 85c0����������� test eax,eax
[00001217](02)� 7402����������� jz 0000121b
[00001219](02)� ebfe����������� jmp 00001219
[0000121b](01)� 5d������������� pop ebp
[0000121c](01)� c3������������� ret
Size in bytes:(0027) [0000121c]
_main()
[00001222](01)� 55������������� push ebp
[00001223](02)� 8bec����������� mov ebp,esp
[00001225](05)� 6802120000����� push 00001202
[0000122a](05)� 6802120000����� push 00001202
[0000122f](05)� e8fefdffff����� call 00001032
[00001234](03)� 83c408��������� add esp,+08
[00001237](01)� 50������������� push eax
[00001238](05)� 68b3030000����� push 000003b3
[0000123d](05)� e8c0f1ffff����� call 00000402
[00001242](03)� 83c408��������� add esp,+08
[00001245](02)� 33c0����������� xor eax,eax
[00001247](01)� 5d������������� pop ebp
[00001248](01)� c3������������� ret
Size in bytes:(0039) [00001248]
�machine�� stack���� stack���� machine��� assembly >>>>>>>>>>> �address�� address�� data����� code������ language >>>>>>>>>>> �========� ========� ========� =========
============= [00001222][0010200f][00000000] 55
push ebp [00001223][0010200f][00000000] 8bec������ mov >>>>>>>>>>> ebp,esp [00001225][0010200b][00001202] 6802120000 push >>>>>>>>>>> 00001202 // push P [0000122a][00102007][00001202]
6802120000 push 00001202 // push P
[0000122f][00102003][00001234] e8fefdffff call 00001032 >>>>>>>>>>> // call executed H
Begin Simulation�� Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55�������� push ebp
[00001203][002120af][002120b3] 8bec������ mov ebp,esp
[00001205][002120af][002120b3] 8b4508���� mov eax,[ebp+08] >>>>>>>>>>> [00001208][002120ab][00001202] 50�������� push eax����� // >>>>>>>>>>> push P [00001209][002120ab][00001202] 8b4d08���� mov
ecx,[ebp+08] [0000120c][002120a7][00001202] 51
push ecx����� // push P [0000120d][002120a3][00001212] >>>>>>>>>>> e820feffff call 00001032 // call emulated H Infinitely >>>>>>>>>>> Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can >>>>>>>>>>> easily examine its stored execution_trace of P (see above) >>>>>>>>>>> to determine: (a) P is calling H with the same arguments >>>>>>>>>>> that H was called with. (b) No instructions in P could >>>>>>>>>>> possibly escape this otherwise infinitely recursive
emulation. (c) H aborts its emulation of P before its call >>>>>>>>>>> to H is emulated.
When you know that H simply implements the above algorithm >>>>>>>>>> there is no need to see its source code. I am reserving the >>>>>>>>>> publication of the 5 pages of the source code of the halt >>>>>>>>>> decider for journal publication.
Your H is not a pure function as it behaves differently
depending on what is invoking it (it returns a decision
answer to main() but not to P()) and it has side effects
(aborting a simulation).
/Flibble
Finally a critique that has a reasonable basis.
When I transformed H into a pure function of its inputs it
always has the same behavior no matter how it is invoked.
The x86 emulation of P is aborted before P invokes H.
Nope. Preventing a call to H is equivalent to H behaving
differently for same inputs. Aborting a simulation is a side
effect: pure functions do not have side effects.
/Flibble
In other words you are saying that a halt decider is simply not
allowed to report when it correctly detects that it is being
called in infinitely recursive simulation.
I keep telling you this: the infinite recursion is NOT present
when using a valid halt decider: your H is NOT a valid halt
decider.
Simulation is an erroneous approach as a simulating halt decider
can not answer in finite time for a non-halting input as there
is no proven general solution for detecting non-halting
behaviour.
/Flibble
IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR
DISHONESTLY YOU DENY THIS VERIFIABLE FACT:
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and
P would remain stuck in infinitely nested emulation.
For [Strachey 1965] (and the proofs based on it) H is NOT a
simulating halt decider so there is no infinite recursion as there
is no emulation.
Valid halt deciders ANALYSE P, they do not EMULATE P.
/Flibble
I provide a halt decider H that gets the right answer and your
rebuttal is that H does not get the right answer because there is
another different halt decider named H1 that gets the wrong
answer.
Your H also gets the wrong answer:
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 ...[000013eb][00102353][00000000] 50 push eax ...[000013ec][0010234f][00000427] 6827040000 push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 ...[000013f9][00102357][00000000] 33c0 xor eax,eax ...[000013fb][0010235b][00100000] 5d pop ebp ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
Yet you only have dogma and no supporting reasoning.
The reason that you only have dogma and no supporting reasoning is
that tautologies such as this one have no correct rebuttal in the
universe:
The ordinary semantics of standard C and the conventional x86
language are the entire semantics required to conclusively prove that
H(P,P) does correctly predict that its correct and complete x86
emulation of its input would never reach the "ret" instruction (final
state) of this input thus never halts.
Paul N <gw7rib@aol.com> writes:
If P(P) returns, then a CORRECT emulation of it will reach the ret
instruction. An emulation that runs forever, when P(P) does not, is
not a correct emulation.
You have missed the magic words. We know a few things for certain about
PO's ever-so-secret code. One is that whatever it is the latest mantra
means "the correct simulation of the input to H(P,P)" is not the same as
the correct simulation of P(P). Why? Well PO is explicitly not talking about an H that answers the halting problem, as translated into the
language of C functions returning.
He hasn't been talking about that for years, but in the past he was too clear. He used to say things like "P(P) only halts because..." as if
the reason excused the wrong answer. He used to say that P(P) halts but
it would not halt is H didn't stop it (famously "if line 15 were
commented out"). All was too obvious.
The latest wording is proving more effective at sucking people down the rabbit hole.
On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
Paul N <gw7...@aol.com> writes:
If P(P) returns, then a CORRECT emulation of it will reach the retYou have missed the magic words. We know a few things for certain about
instruction. An emulation that runs forever, when P(P) does not, is
not a correct emulation.
PO's ever-so-secret code. One is that whatever it is the latest mantra
means "the correct simulation of the input to H(P,P)" is not the same as
the correct simulation of P(P). Why? Well PO is explicitly not talking
about an H that answers the halting problem, as translated into the
language of C functions returning.
He hasn't been talking about that for years, but in the past he was too
clear. He used to say things like "P(P) only halts because..." as if
the reason excused the wrong answer. He used to say that P(P) halts but
it would not halt is H didn't stop it (famously "if line 15 were
commented out"). All was too obvious.
The latest wording is proving more effective at sucking people down the
rabbit hole.
Yes, perhaps I'm wasting my time here. I have got out of him now that:
The correct and complete emulation of the input to H(P,P) has halting
behavior that is provably different than the the direct execution of P(P).
"Common sense" tells you that they must be the same empirical proof
proves that they are not the same.
On 6/25/2022 1:58 PM, Paul N wrote:
On Saturday, June 25, 2022 at 6:52:33 PM UTC+1, olcott wrote:
On 6/25/2022 12:21 PM, Paul N wrote:
On Saturday, June 25, 2022 at 5:29:33 PM UTC+1, olcott wrote:
On 6/25/2022 11:19 AM, Paul N wrote:
On Saturday, June 25, 2022 at 3:10:50 PM UTC+1, olcott wrote:int main()
On 6/25/2022 6:56 AM, Paul N wrote:
On Friday, June 24, 2022 at 9:27:27 PM UTC+1, olcott wrote:Yes they both return.
On 6/24/2022 3:05 PM, Paul N wrote:
On Friday, June 24, 2022 at 7:52:22 PM UTC+1, olcott wrote: >>>>>>>>>>> On 6/22/2022 9:23 PM, Dennis Bush wrote:Thanks for continuing to review this.
On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote: >>>>>>>>>>>>> On 6/22/2022 8:44 PM, Dennis Bush wrote:correctly determine that its correct and complete x86
On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott >>>>>>>>>>>>>> wrote:You just said that H(P,P) cannot correctly predict that the >>>>>>>>>>>>> correct and
On 6/22/2022 8:21 PM, Dennis Bush wrote:Now who's using the strawman error? Just because H can >>>>>>>>>>>>>> determine that _Infinite_Loop does not halt doesn't mean >>>>>>>>>>>>>> that it gets other cases right. B
On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott >>>>>>>>>>>>>>>> wrote:[00001082](01) 55 push ebp
On 6/22/2022 8:02 PM, Dennis Bush wrote:
On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, >>>>>>>>>>>>>>>>>> olcott wrote:its input so your rebuttal is the strawman deception. >>>>>>>>>>>>>>>>>
On 6/22/2022 5:48 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, >>>>>>>>>>>>>>>>>>>> olcott wrote:
Your entire basis and all of assumptions was >>>>>>>>>>>>>>>>>>> incorrect so when IOn 6/22/2022 4:53 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, >>>>>>>>>>>>>>>>>>>>>> olcott wrote:So you just repeated what you said instead of >>>>>>>>>>>>>>>>>>>> explaining why I'm wrong. In other words you >>>>>>>>>>>>>>>>>>>> provided no rebuttal, which can only be taken to >>>>>>>>>>>>>>>>>>>> mean that you have none.
Every sufficiently competent software engineer can >>>>>>>>>>>>>>>>>>>>> easily verify thatOn 6/22/2022 4:20 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500 >>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>H (if it was constructed correctly) is a >>>>>>>>>>>>>>>>>>>>>> computation, and a computation *always* gives the >>>>>>>>>>>>>>>>>>>>>> same output for a given input. So it doesn't make >>>>>>>>>>>>>>>>>>>>>> sense to say what it "would" do. It either does or >>>>>>>>>>>>>>>>>>>>>> does not perform a complete and correct emulation. >>>>>>>>>>>>>>>>>>>>>> And because H contains code to abort, and does >>>>>>>>>>>>>>>>>>>>>> abort, it does not do a complete emulation. >>>>>>>>>>>>>>>>>>>>>>
If you are competent then you already know this >>>>>>>>>>>>>>>>>>>>>>> is true and lie about it:On 6/22/2022 2:31 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500 >>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>
#include <stdint.h>
#define u32 uint32_t
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P)); >>>>>>>>>>>>>>>>>>>>>>>>>>> }
_P()
[000010d2](01) 55 push ebp >>>>>>>>>>>>>>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax >>>>>>>>>>>>>>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx >>>>>>>>>>>>>>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02 >>>>>>>>>>>>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08 >>>>>>>>>>>>>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax >>>>>>>>>>>>>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb >>>>>>>>>>>>>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9 >>>>>>>>>>>>>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp >>>>>>>>>>>>>>>>>>>>>>>>>>> [000010ec](01) c3 ret
Size in bytes:(0027) [000010ec] >>>>>>>>>>>>>>>>>>>>>>>>>>>
Every sufficiently competent software >>>>>>>>>>>>>>>>>>>>>>>>>>> engineer can easily verify >>>>>>>>>>>>>>>>>>>>>>>>>>> that the complete and correct x86 emulation >>>>>>>>>>>>>>>>>>>>>>>>>>> of the input to H(P,P)
by H would never reach the "ret" instruction >>>>>>>>>>>>>>>>>>>>>>>>>>> of P because both H
and P would remain stuck in infinitely >>>>>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
If H does correctly determine that this is >>>>>>>>>>>>>>>>>>>>>>>>>>> the case in a finite
number of steps then H could reject its input >>>>>>>>>>>>>>>>>>>>>>>>>>> on this basis. Here
are the details of exactly how H does this in >>>>>>>>>>>>>>>>>>>>>>>>>>> a finite number of
steps.
typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP >>>>>>>>>>>>>>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack >>>>>>>>>>>>>>>>>>>>>>>>>>> u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;
machine stack stack machine assembly >>>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language >>>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= >>>>>>>>>>>>>>>>>>>>>>>>>>> =============
[000010d2][00211e8a][00211e8e] 55 push ebp >>>>>>>>>>>>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov >>>>>>>>>>>>>>>>>>>>>>>>>>> eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // >>>>>>>>>>>>>>>>>>>>>>>>>>> push P
[000010d9][00211e86][000010d2] 8b4d08 mov >>>>>>>>>>>>>>>>>>>>>>>>>>> ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // >>>>>>>>>>>>>>>>>>>>>>>>>>> push P
[000010dd][00211e7e][000010e2] e820feffff >>>>>>>>>>>>>>>>>>>>>>>>>>> call 00000f02 // call H
Infinitely Recursive Simulation Detected >>>>>>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
// actual fully operational code in the >>>>>>>>>>>>>>>>>>>>>>>>>>> x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17 >>>>>>>>>>>>>>>>>>>>>>>>>>> u32 code_end = get_code_end(P); >>>>>>>>>>>>>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = >>>>>>>>>>>>>>>>>>>>>>>>>>> (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code)); >>>>>>>>>>>>>>>>>>>>>>>>>>> Registers* master_state = (Registers*) >>>>>>>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers)); >>>>>>>>>>>>>>>>>>>>>>>>>>> Registers* slave_state = (Registers*) >>>>>>>>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers)); >>>>>>>>>>>>>>>>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k; >>>>>>>>>>>>>>>>>>>>>>>>>>> u32 execution_trace =
(u32)Allocate(sizeof(Decoded_Line_Of_Code) >>>>>>>>>>>>>>>>>>>>>>>>>>> * 1000);
__asm lea eax, HERE // 2022-06-18 >>>>>>>>>>>>>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18 >>>>>>>>>>>>>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18 >>>>>>>>>>>>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE >>>>>>>>>>>>>>>>>>>>>>>>>>> __asm mov End_Of_Code, eax >>>>>>>>>>>>>>>>>>>>>>>>>>>
Output("Address_of_H:", Address_of_H); // >>>>>>>>>>>>>>>>>>>>>>>>>>> 2022-06-11
Init_slave_state(P, I, End_Of_Code, >>>>>>>>>>>>>>>>>>>>>>>>>>> slave_state, slave_stack); >>>>>>>>>>>>>>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace >>>>>>>>>>>>>>>>>>>>>>>>>>> Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, >>>>>>>>>>>>>>>>>>>>>>>>>>> &decoded, code_end,
&master_state, &slave_state, &slave_stack, >>>>>>>>>>>>>>>>>>>>>>>>>>> Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt >>>>>>>>>>>>>>>>>>>>>>>>>>> END_OF_CODE:
return 1; // Input has normally terminated >>>>>>>>>>>>>>>>>>>>>>>>>>> }
H knows its own machine address and on this >>>>>>>>>>>>>>>>>>>>>>>>>>> basis it can easily
examine its stored execution_trace of P and >>>>>>>>>>>>>>>>>>>>>>>>>>> determine:
(a) P is calling H with the same arguments >>>>>>>>>>>>>>>>>>>>>>>>>>> that H was called with.
(b) No instructions in P could possibly >>>>>>>>>>>>>>>>>>>>>>>>>>> escape this otherwise
infinitely recursive emulation. >>>>>>>>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its >>>>>>>>>>>>>>>>>>>>>>>>>>> call to H is invoked.
Technically competent software engineers may >>>>>>>>>>>>>>>>>>>>>>>>>>> not know this computer
science:
A halt decider must compute the mapping from >>>>>>>>>>>>>>>>>>>>>>>>>>> its inputs to an
accept or reject state on the basis of the >>>>>>>>>>>>>>>>>>>>>>>>>>> actual behavior that is
actually specified by these inputs. >>>>>>>>>>>>>>>>>>>>>>>>>>>
computation that halts … the Turing machine >>>>>>>>>>>>>>>>>>>>>>>>>>> will halt whenever it
enters a final state. (Linz:1990:234) >>>>>>>>>>>>>>>>>>>>>>>>>>>
The "ret" instruction of P is its final state. >>>>>>>>>>>>>>>>>>>>>>>>>>>
Linz, Peter 1990. An Introduction to Formal >>>>>>>>>>>>>>>>>>>>>>>>>>> Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. >>>>>>>>>>>>>>>>>>>>>>>>>>> (317-320)
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>>>>>>>>>>>>>>>> }
...[000013e8][00102357][00000000] 83c408 add >>>>>>>>>>>>>>>>>>>>>>>>>> esp,+08
...[000013eb][00102353][00000000] 50 push eax >>>>>>>>>>>>>>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 >>>>>>>>>>>>>>>>>>>>>>>>>> push 00000427
---[000013f1][0010234f][00000427] e880f0ffff >>>>>>>>>>>>>>>>>>>>>>>>>> call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add >>>>>>>>>>>>>>>>>>>>>>>>>> esp,+08
...[000013f9][00102357][00000000] 33c0 xor >>>>>>>>>>>>>>>>>>>>>>>>>> eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp >>>>>>>>>>>>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret >>>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120) >>>>>>>>>>>>>>>>>>>>>>>>>>
It gets the answer wrong, i.e. input has not >>>>>>>>>>>>>>>>>>>>>>>>>> been decided correctly.
QED.
/Flibble
You and Richard are insufficiently technically >>>>>>>>>>>>>>>>>>>>>>>>> competent at software
engineering not meeting these specs: >>>>>>>>>>>>>>>>>>>>>>>>>
A software engineer must be an expert in: the C >>>>>>>>>>>>>>>>>>>>>>>>> programming language,
the x86 programming language, exactly how C >>>>>>>>>>>>>>>>>>>>>>>>> translates into x86 and
the ability to recognize infinite recursion at >>>>>>>>>>>>>>>>>>>>>>>>> the x86 assembly
language level. No knowledge of the halting >>>>>>>>>>>>>>>>>>>>>>>>> problem is required.
I cannot speak for Richard but I have 30+ years >>>>>>>>>>>>>>>>>>>>>>>> C++ experience; I also
have C and x86 assembly experience (I once wrote >>>>>>>>>>>>>>>>>>>>>>>> a Zilog Z80A CPU
emulator in 80286 assembly) and I can recognize >>>>>>>>>>>>>>>>>>>>>>>> an infinite recursion;
the problem is that you cannot recognize the >>>>>>>>>>>>>>>>>>>>>>>> fact that the infinite
recursion only manifests as part of your invalid >>>>>>>>>>>>>>>>>>>>>>>> simulation-based
omnishambles:
Every sufficiently competent software engineer >>>>>>>>>>>>>>>>>>>>>>> can easily verify that
the complete and correct x86 emulation of the >>>>>>>>>>>>>>>>>>>>>>> input to H(Px,Px) by H
would never reach the "ret" instruction of P >>>>>>>>>>>>>>>>>>>>>>> because both H and P would
remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>>>>>>>>
So the input must be given to a UTM, which by >>>>>>>>>>>>>>>>>>>>>> definition does a correct and complete simulation, >>>>>>>>>>>>>>>>>>>>>> to see what the actual behavior is. UTM(Px,Px) >>>>>>>>>>>>>>>>>>>>>> halts, therefore H(Px,Px)==0 is wrong. >>>>>>>>>>>>>>>>>>>>>
the complete and correct x86 emulation of the input >>>>>>>>>>>>>>>>>>>>> to H(Px,Px) by H
would never reach the "ret" instruction of Px >>>>>>>>>>>>>>>>>>>>> because both H and Px
would remain stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>>>>>>
provided an infallible one to that cannot possibly be >>>>>>>>>>>>>>>>>>> correctly refuted
you simply dodged it. That is a smart move for a >>>>>>>>>>>>>>>>>>> dishonest person that
is only interested in rebuttal.
I dare you to go back to the prior post and find any >>>>>>>>>>>>>>>>>>> error in my
airtight correct reasoning. Another dodge will be >>>>>>>>>>>>>>>>>>> construed as a tacit
admission of defeat.
As stated before H (or more accurately Ha) does not >>>>>>>>>>>>>>>>>> perform a complete and correct emulation because it >>>>>>>>>>>>>>>>>> aborts. So by definition it cannot be complete. >>>>>>>>>>>>>>>>> I never claimed that H(P,P) performs a complete and >>>>>>>>>>>>>>>>> correct emulation of
I claimed that H(P,P) correctly predicts that its >>>>>>>>>>>>>>>>> complete and correct
x86 emulation of its input would never reach the "ret" >>>>>>>>>>>>>>>>> instruction of P.
But since H, or more accurately Ha, *can't* do a correct >>>>>>>>>>>>>>>> and complete emulation of its input, your point is moot. >>>>>>>>>>>>>>> _Infinite_Loop()
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]
Begin Local Halt Decider Simulation Execution Trace >>>>>>>>>>>>>>> Stored at:211e8f
...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp >>>>>>>>>>>>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085 >>>>>>>>>>>>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085 >>>>>>>>>>>>>>> Infinite Loop Detected Simulation Stopped
On the basis of this exact same utterly moronic reasoning >>>>>>>>>>>>>>> because H
*can't* do a correct and complete emulation of its input, >>>>>>>>>>>>>>> H cannot
possibly determine that _Infinite_Loop() never halts. >>>>>>>>>>>>>>
complete x86 emulation of its input would never reach the >>>>>>>>>>>>> "ret"
instruction of P without a compete x86 emulation of its >>>>>>>>>>>>> input. I just
proved that is a very stupid thing to say.
You said that H can predict what *its* correct and complete >>>>>>>>>>>> emulation would do, and I said that doesn't make sense >>>>>>>>>>>> because H does not do correct and complete emulation. What H >>>>>>>>>>>> *must* do is predict what *the* correct and complete
emulation, i.e. UTM(P,P), would do. And it fails to do that. >>>>>>>>>>> From a purely software engineering perspective H(P,P) is >>>>>>>>>>> required to to
emulation of its
input would never reach the "ret" instruction of this input >>>>>>>>>>> and H must
do this in a finite number of steps.
The ordinary semantics of standard C and the conventional x86 >>>>>>>>>>> language
are the entire semantics required to conclusively prove that >>>>>>>>>>> H(P,P) does
correctly determine that its correct and complete x86
emulation of its
input would never reach the "ret" instruction.
That you disagree with easily verified software engineering >>>>>>>>>>> when you
already know that this software engineering is correct speaks >>>>>>>>>>> loads
about your character.
The only computer science that need be added to this is that >>>>>>>>>>> the "ret"
instruction is the final state of P and that a sequence of >>>>>>>>>>> configurations that cannot possibly reach its final state is a >>>>>>>>>>> non-halting sequence.
You say that "H(P,P) is required to to correctly determine >>>>>>>>>> that its correct and complete x86 emulation of its input would >>>>>>>>>> never reach the "ret" instruction of this input". You seem to >>>>>>>>>> be assuming that H does an emulation of P, that this emulation >>>>>>>>>> includes emulating the call to H, that this call to H would >>>>>>>>>> start emulating the call to P, etc, etc, and so the call to P >>>>>>>>>> does not terminate.
No assumptions two years of software development derived fully >>>>>>>>> operational software that conclusively proves this.
It might help people's understanding if we had a few more
examples. Suppose, in addition to the normal P and H, we have
two more functions as follows:
void Q(void)
{
if (H(P, P))
H2: goto H2;
return;
}
void R(void)
{
H(P, P);
return;
}
Will Q return? Will R return?
void Q(void)
{
if (H(P, P))
H2: goto H2;
return;
}
void R(void)
{
H(P, P);
return;
}
_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]
_Q()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) 68f0110000 push 000011f0
[0000121d](05) e8fefdffff call 00001020
[00001222](03) 83c408 add esp,+08
[00001225](02) 85c0 test eax,eax
[00001227](02) 7402 jz 0000122b
[00001229](02) ebfe jmp 00001229
[0000122b](01) 5d pop ebp
[0000122c](01) c3 ret
Size in bytes:(0029) [0000122c]
_main()
[00001250](01) 55 push ebp
[00001251](02) 8bec mov ebp,esp
[00001253](05) e8b8ffffff call 00001210
[00001258](02) 33c0 xor eax,eax
[0000125a](01) 5d pop ebp
[0000125b](01) c3 ret
Size in bytes:(0012) [0000125b]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001250][00102048][00000000] 55 push ebp
...[00001251][00102048][00000000] 8bec mov ebp,esp
...[00001253][00102044][00001258] e8b8ffffff call 00001210
...[00001210][00102040][00102048] 55 push ebp
...[00001211][00102040][00102048] 8bec mov ebp,esp
...[00001213][0010203c][000011f0] 68f0110000 push 000011f0
...[00001218][00102038][000011f0] 68f0110000 push 000011f0
...[0000121d][00102034][00001222] e8fefdffff call 00001020
Begin Simulation Execution Trace Stored at:2120fc
Address_of_H:1020
...[000011f0][002120e8][002120ec] 55 push ebp
...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
...[000011f6][002120e4][000011f0] 50 push eax
...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
...[000011fa][002120e0][000011f0] 51 push ecx
...[000011fb][002120dc][00001200] e820feffff call 00001020
Infinitely Recursive Simulation Detected Simulation Stopped
...[00001222][00102040][00102048] 83c408 add esp,+08
...[00001225][00102040][00102048] 85c0 test eax,eax
...[00001227][00102040][00102048] 7402 jz 0000122b
...[0000122b][00102044][00001258] 5d pop ebp
...[0000122c][00102048][00000000] c3 ret
...[00001258][00102048][00000000] 33c0 xor eax,eax
...[0000125a][0010204c][00100000] 5d pop ebp
...[0000125b][00102050][00000000] c3 ret
Number of Instructions Executed(874)
Above is:
int main()
{
Q();
//R();
}
---
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001250][00102048][00000000] 55 push ebp
...[00001251][00102048][00000000] 8bec mov ebp,esp
...[00001253][00102044][00001258] e8d8ffffff call 00001230
...[00001230][00102040][00102048] 55 push ebp
...[00001231][00102040][00102048] 8bec mov ebp,esp
...[00001233][0010203c][000011f0] 68f0110000 push 000011f0
...[00001238][00102038][000011f0] 68f0110000 push 000011f0
...[0000123d][00102034][00001242] e8defdffff call 00001020
Begin Simulation Execution Trace Stored at:2120fc
Address_of_H:1020
...[000011f0][002120e8][002120ec] 55 push ebp
...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
...[000011f6][002120e4][000011f0] 50 push eax
...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
...[000011fa][002120e0][000011f0] 51 push ecx
...[000011fb][002120dc][00001200] e820feffff call 00001020
Infinitely Recursive Simulation Detected Simulation Stopped
...[00001242][00102040][00102048] 83c408 add esp,+08
...[00001245][00102044][00001258] 5d pop ebp
...[00001246][00102048][00000000] c3 ret
...[00001258][00102048][00000000] 33c0 xor eax,eax
...[0000125a][0010204c][00100000] 5d pop ebp
...[0000125b][00102050][00000000] c3 ret
Number of Instructions Executed(872)
Above is:
int main()
{
//Q();
R();
}
Right, so we're getting somewhere. Can you explain why Q()
returns, and P(P) doesn't, when they both do the same thing in the >>>>>> same way?
{
P(P);
}
does return.
The correct and complete x86 emulation of its input by H(P,P)
would never reach the "ret" instruction of P because both H and
P would remain stuck in infinitely nested emulation.
These last two statements of yours are a contradiction.
If P(P) returns, then a CORRECT emulation of it will reach the ret
instruction. An emulation that runs forever, when P(P) does not, is
not a correct emulation.
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P)
*does correctly predict*
that its correct and complete x86 emulation of its input would never
reach the "ret" instruction (final state) of this input thus never
halts.
The correct and complete x86 emulation of its input by H would never
reach the "ret" instruction of P because both H and P would remain stuck >>> in infinitely nested emulation.
I need reviewers like you so that I can *fine tune* my words.
If you are saying that P(P) returns, but that a correct and complete
x86 emulation of P(P) does not, then I think you are going to have to
change either "correct" or "emulation" to some very different word.
The correct and complete emulation of the input to H(P,P) has halting behavior that is provably different than the the direct execution of P(P).
"Common sense" tells you that they must be the same empirical proof
proves that they are not the same.
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior of these actual inputs.
Exactly. The actual behaviour. Not the behaviour it would have if
things were different. In particular, you need to take into account
H's ability to detect infinite loops.
I initially made H robust enough that it does correctly reject infinite
loops and infinite recursion and have code samples to prove it.
When a simulating halt decider rejects all inputs as non-halting
whenever it correctly detects [in a finite number of steps] that its
correct and complete simulation of its input would never reach [a] final >>> state of this input then all [these] inputs (including pathological
inputs) are correctly decided as non-halting.
If you are fine-tuning your wording, could you do something about this
passage? Having both "When" and "whenever" makes it difficult to parse.
When a simulating halt decider correctly detects [in a finite number of steps] that its correct and complete simulation of its input would never reach [a] final state of this input then all [these] inputs (including pathological inputs) are correctly rejected as non-halting.
On 6/25/2022 2:33 PM, Paul N wrote:
On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
Paul N <gw7...@aol.com> writes:
If P(P) returns, then a CORRECT emulation of it will reach the retYou have missed the magic words. We know a few things for certain about
instruction. An emulation that runs forever, when P(P) does not, is
not a correct emulation.
PO's ever-so-secret code. One is that whatever it is the latest mantra
means "the correct simulation of the input to H(P,P)" is not the same as >>> the correct simulation of P(P). Why? Well PO is explicitly not talking
about an H that answers the halting problem, as translated into the
language of C functions returning.
He hasn't been talking about that for years, but in the past he was too
clear. He used to say things like "P(P) only halts because..." as if
the reason excused the wrong answer. He used to say that P(P) halts but
it would not halt is H didn't stop it (famously "if line 15 were
commented out"). All was too obvious.
The latest wording is proving more effective at sucking people down the
rabbit hole.
Yes, perhaps I'm wasting my time here. I have got out of him now that:
The correct and complete emulation of the input to H(P,P) has halting
behavior that is provably different than the the direct execution of
P(P).
"Common sense" tells you that they must be the same empirical proof
proves that they are not the same.
Empirical proof is a term that is weaker than the actual proof:
Someone that very recently coached me on how to write formal
mathematical proofs of my claim indicated that I must specify the
precise semantics that I am referencing:
The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does correctly predict that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.
This same proof shows that P(P) halts.
When we specify the precise semantics the proof gains much more than
mere "empirical" mathematical rigor.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
P(P);
}
_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]
_main()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) e8d3ffffff call 000011f0
[0000121d](03) 83c404 add esp,+04
[00001220](02) 33c0 xor eax,eax
[00001222](01) 5d pop ebp
[00001223](01) c3 ret
Size in bytes:(0020) [00001223]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [00001210][00101fba][00000000] 55 push ebp [00001211][00101fba][00000000] 8bec mov ebp,esp [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
[000011f1][00101fae][00101fba] 8bec mov ebp,esp [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08] [000011f6][00101faa][000011f0] 50 push eax // push P
[000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08] [000011fa][00101fa6][000011f0] 51 push ecx // push P
[000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
Begin Simulation Execution Trace Stored at:21206e
Address_of_H:1020
[000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
[000011f1][0021205a][0021205e] 8bec mov ebp,esp [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08] [000011f6][00212056][000011f0] 50 push eax // push P
[000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08] [000011fa][00212052][000011f0] 51 push ecx // push P
[000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H Infinitely Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.
[00001200][00101fae][00101fba] 83c408 add esp,+08 // return to executed P
[00001203][00101fae][00101fba] 85c0 test eax,eax [00001205][00101fae][00101fba] 7402 jz 00001209 [00001209][00101fb2][0000121d] 5d pop ebp [0000120a][00101fb6][000011f0] c3 ret // return from
executed P
[0000121d][00101fba][00000000] 83c404 add esp,+04 [00001220][00101fba][00000000] 33c0 xor eax,eax [00001222][00101fbe][00100000] 5d pop ebp [00001223][00101fc2][00000000] c3 ret // ret from main
Number of Instructions Executed(878) / 67 = 13 pages
On 6/25/2022 2:24 PM, Ben Bacarisse wrote:
Paul N <gw7rib@aol.com> writes:
If P(P) returns, then a CORRECT emulation of it will reach the ret
instruction. An emulation that runs forever, when P(P) does not, is
not a correct emulation.
You have missed the magic words. We know a few things for certain about
PO's ever-so-secret code. One is that whatever it is the latest mantra
means "the correct simulation of the input to H(P,P)" is not the same as
the correct simulation of P(P). Why? Well PO is explicitly not talking >> about an H that answers the halting problem, as translated into the
language of C functions returning.
He hasn't been talking about that for years, but in the past he was too
clear. He used to say things like "P(P) only halts because..." as if
the reason excused the wrong answer. He used to say that P(P) halts but
it would not halt is H didn't stop it (famously "if line 15 were
commented out"). All was too obvious.
The latest wording is proving more effective at sucking people down the
rabbit hole.
A halt decider must compute the mapping from its inputs to an accept or reject state on the basis of the actual behavior that is actually
specified by these inputs.
It is provable that the behavior of the correct and complete x86
emulation of the input to H(P,P) never halts and the direct execution of
P(P) halts. H is required to decide on the basis of the former and not allowed to decide on the basis of the latter unless it is the same as
the former.
These behaviors only diverge when H and P are defined to have this pathological relationship to each other:
For any program H that might determine if programs halt, a "pathological"
program P, called with some input, can pass its own source and its input to
H and then specifically do the opposite of what H predicts P will do. No H
can exist that handles this case. https://en.wikipedia.org/wiki/Halting_problem
None of the textbook authors were aware that these behaviors could
possibly diverge because they never fully considered the effect of a simulating halt decider applied to the halting problem counter-examples.
On 6/25/2022 2:24 PM, Ben Bacarisse wrote:
Paul N <gw7rib@aol.com> writes:
If P(P) returns, then a CORRECT emulation of it will reach the ret
instruction. An emulation that runs forever, when P(P) does not, is
not a correct emulation.
You have missed the magic words. We know a few things for certain
about PO's ever-so-secret code. One is that whatever it is the
latest mantra means "the correct simulation of the input to H(P,P)"
is not the same as the correct simulation of P(P). Why? Well PO
is explicitly not talking about an H that answers the halting
problem, as translated into the language of C functions returning.
He hasn't been talking about that for years, but in the past he was
too clear. He used to say things like "P(P) only halts because..."
as if the reason excused the wrong answer. He used to say that
P(P) halts but it would not halt is H didn't stop it (famously "if
line 15 were commented out"). All was too obvious.
The latest wording is proving more effective at sucking people down
the rabbit hole.
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually specified by these inputs.
It is provable that the behavior of the correct and complete x86
emulation of the input to H(P,P) never halts and the direct execution
of P(P) halts. H is required to decide on the basis of the former and
not allowed to decide on the basis of the latter unless it is the
same as the former.
Paul N <gw7rib@aol.com> writes:
On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
The latest wording is proving more effective at sucking people down the
rabbit hole.
Yes, perhaps I'm wasting my time here. I have got out of him now that:
The correct and complete emulation of the input to H(P,P) has halting
behavior that is provably different than the the direct execution of
P(P).
Not to diminish the achievement of getting any clear statements from PO,
but that's not new. I made a note on June 13th that he'd come clean
about this:
"Before my research no one was aware of the possibility that the
correctly simulated input to H(P,P) could possibly have behavior that
is different than the directly executed P(P)."
Paul N <gw7rib@aol.com> writes:
On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
The latest wording is proving more effective at sucking people down the
rabbit hole.
Yes, perhaps I'm wasting my time here. I have got out of him now that:
The correct and complete emulation of the input to H(P,P) has halting
behavior that is provably different than the the direct execution of
P(P).
Not to diminish the achievement of getting any clear statements from PO,
but that's not new. I made a note on June 13th that he'd come clean
about this:
"Before my research no one was aware of the possibility that the
correctly simulated input to H(P,P) could possibly have behavior that
is different than the directly executed P(P)."
Paul N <gw7rib@aol.com> writes:
On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
The latest wording is proving more effective at sucking people down the
rabbit hole.
Yes, perhaps I'm wasting my time here. I have got out of him now that:
The correct and complete emulation of the input to H(P,P) has halting
behavior that is provably different than the the direct execution of
P(P).
Not to diminish the achievement of getting any clear statements from PO,
but that's not new. I made a note on June 13th that he'd come clean
about this:
"Before my research no one was aware of the possibility that the
correctly simulated input to H(P,P) could possibly have behavior that
is different than the directly executed P(P)."
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and determines >>>> what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's invoked H >>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
The obvious conclusion is that PO's dry run (if he has indeed done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers spend
more energy than they take in. Well potentially this is dynamite. One
explanation is that the law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to rule out a
much simpler explanation. Which is that our measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be doing, by
dry-running it, and then actually run P(P) and obtained a different
result. He also found that H agreed with the dry run. It's hard to
paraphrase his conclusion, but it is extensive and far-reaching in its
implications.
He is just waffling. There is no conclusion, just a constant twisting
and turning to find some why to persuade people that the wrong answer is
the right one. He's being doing this for years with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is putting up
anything he can think of to keep the discussion going. It should simply
have stopped once he'd been clear that H(P,P) == 0 is correct "even
though P(P) halts" but the traces and the verbiage is keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true, then it
has similar implications for computer science that disproving the
conservation law has for physics.
When a student comes to me and says that her program to add 5 and 6
gives 12, I don't, even for a moment, imagine that the laws of logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect. Lots of
people have suggested why it is incorrect. But they can't actually see
the code. PO needs to understand that no-one will accept the
complicated, far-reaching explanation, until the simple explanation
has been ruled out.
For what it's worth, I don't think there is any "dry run" going on here
at all. PO decide years ago that H(H_Hat, H_Hat) would be 0 because he
knew (correctly) that H could spot what would happen if H did not "intervene". Everything since then -- the "it only halt because...",
the "it wouldn't halt if line 15 were commented out" and the rather less explicitly stated "H_Hat does not get to its ret instruction because a
non top-level H aborts" are just the various attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually fractally
wrong, so he's not correct about almost everything he says at almost
every level. For example, at one level he now admits that a halt
decider is impossible because H(X,Y) must report "on its input" and the
call X(Y) is not an input! He did this to explain why H(P,P) is
permitted to return 0 "even though P(P) halts", but it also makes it
clear that what he one thought was that halting problem is not solvable.
On Sat, 25 Jun 2022 20:07:04 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and
determines what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's
invoked H | on it and H reports that it doesn't halt. He's run
P(P) and it halts. The obvious conclusion is that PO's dry run
(if he has indeed done such a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers
spend more energy than they take in. Well potentially this is
dynamite. One explanation is that the law of conservation of
energy is wrong. Except, before we countenance that explanation,
we need to rule out a much simpler explanation. Which is that our
measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be doing,
by dry-running it, and then actually run P(P) and obtained a
different result. He also found that H agreed with the dry run.
It's hard to paraphrase his conclusion, but it is extensive and
far-reaching in its implications.
He is just waffling. There is no conclusion, just a constant
twisting and turning to find some why to persuade people that the
wrong answer is the right one. He's being doing this for years
with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is putting up
anything he can think of to keep the discussion going. It should
simply have stopped once he'd been clear that H(P,P) == 0 is
correct "even though P(P) halts" but the traces and the verbiage is
keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true, then
it has similar implications for computer science that disproving
the conservation law has for physics.
When a student comes to me and says that her program to add 5 and 6
gives 12, I don't, even for a moment, imagine that the laws of
logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect.
Lots of people have suggested why it is incorrect. But they can't
actually see the code. PO needs to understand that no-one will
accept the complicated, far-reaching explanation, until the simple
explanation has been ruled out.
For what it's worth, I don't think there is any "dry run" going on
here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
because he knew (correctly) that H could spot what would happen if
H did not "intervene". Everything since then -- the "it only halt
because...", the "it wouldn't halt if line 15 were commented out"
and the rather less explicitly stated "H_Hat does not get to its
ret instruction because a non top-level H aborts" are just the
various attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually fractally
wrong, so he's not correct about almost everything he says at almost
every level. For example, at one level he now admits that a halt
decider is impossible because H(X,Y) must report "on its input" and
the call X(Y) is not an input! He did this to explain why H(P,P) is
permitted to return 0 "even though P(P) halts", but it also makes it
clear that what he one thought was that halting problem is not
solvable.
(a) and (b) are proven to be verified facts entirely on the basis of
the semantics of the x86 language. (Most people here do not seem to
"believe in" the semantics of the x86 language otherwise they would
have no basis to disagree).
(a) The complete and correct x86 emulation of the input to H(P,P) by
H never reaches the "ret" instruction of P.
(b) The direct execution of P(P) does reach its "ret" instruction.
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.
P(P) is provably not the actual behavior of the actual input.
(a) is false as the reason the ret instruction is not reached is
incorrect: the ret instruction should not be reached due to the
infinite loop in P and not because you abort the simulation before the infinite loop is reached. Your H is incorrect in its assumption that P
is pathological because it calls H.
/Flibble
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and
determines what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's
invoked H | on it and H reports that it doesn't halt. He's run
P(P) and it halts. The obvious conclusion is that PO's dry run
(if he has indeed done such a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers
spend more energy than they take in. Well potentially this is
dynamite. One explanation is that the law of conservation of
energy is wrong. Except, before we countenance that explanation,
we need to rule out a much simpler explanation. Which is that our
measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be doing,
by dry-running it, and then actually run P(P) and obtained a
different result. He also found that H agreed with the dry run.
It's hard to paraphrase his conclusion, but it is extensive and
far-reaching in its implications.
He is just waffling. There is no conclusion, just a constant
twisting and turning to find some why to persuade people that the
wrong answer is the right one. He's being doing this for years
with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is putting up
anything he can think of to keep the discussion going. It should
simply have stopped once he'd been clear that H(P,P) == 0 is
correct "even though P(P) halts" but the traces and the verbiage is
keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true, then
it has similar implications for computer science that disproving
the conservation law has for physics.
When a student comes to me and says that her program to add 5 and 6
gives 12, I don't, even for a moment, imagine that the laws of
logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect.
Lots of people have suggested why it is incorrect. But they can't
actually see the code. PO needs to understand that no-one will
accept the complicated, far-reaching explanation, until the simple
explanation has been ruled out.
For what it's worth, I don't think there is any "dry run" going on
here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
because he knew (correctly) that H could spot what would happen if
H did not "intervene". Everything since then -- the "it only halt because...", the "it wouldn't halt if line 15 were commented out"
and the rather less explicitly stated "H_Hat does not get to its
ret instruction because a non top-level H aborts" are just the
various attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually fractally
wrong, so he's not correct about almost everything he says at almost
every level. For example, at one level he now admits that a halt
decider is impossible because H(X,Y) must report "on its input" and
the call X(Y) is not an input! He did this to explain why H(P,P) is permitted to return 0 "even though P(P) halts", but it also makes it
clear that what he one thought was that halting problem is not
solvable.
(a) and (b) are proven to be verified facts entirely on the basis of
the semantics of the x86 language. (Most people here do not seem to
"believe in" the semantics of the x86 language otherwise they would
have no basis to disagree).
(a) The complete and correct x86 emulation of the input to H(P,P) by
H never reaches the "ret" instruction of P.
(b) The direct execution of P(P) does reach its "ret" instruction.
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually specified by these inputs.
P(P) is provably not the actual behavior of the actual input.
On 6/25/2022 6:28 PM, Ben Bacarisse wrote:
Paul N <gw7rib@aol.com> writes:
On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
The latest wording is proving more effective at sucking people down the >>>> rabbit hole.
Yes, perhaps I'm wasting my time here. I have got out of him now that:
The correct and complete emulation of the input to H(P,P) has halting >>>>> behavior that is provably different than the the direct execution of >>>>> P(P).
Not to diminish the achievement of getting any clear statements from PO,
but that's not new. I made a note on June 13th that he'd come clean
about this:
"Before my research no one was aware of the possibility that the
correctly simulated input to H(P,P) could possibly have behavior that >> is different than the directly executed P(P)."
I still stand by that as most probably true.
(a) What I stand by as absolutely true is that the complete and correct
x86 emulation of the input to H(P,P) by H never reaches the "ret"
instruction of P.
(b) The direct execution of P(P) does reach its "ret" instruction.
The above two are proven to be verified facts entirely on the basis of
the semantics of the x86 language.
(c) A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually specified by these inputs.
When we know that (a)(b) and (c) are true then it necessarily follows
that anyone saying that H must decide on the basis of the behavior of
P(P) is necessarily incorrect.
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and determines >>>> what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's invoked H >>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
The obvious conclusion is that PO's dry run (if he has indeed done such
a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers spend
more energy than they take in. Well potentially this is dynamite. One
explanation is that the law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to rule out a
much simpler explanation. Which is that our measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be doing, by
dry-running it, and then actually run P(P) and obtained a different
result. He also found that H agreed with the dry run. It's hard to
paraphrase his conclusion, but it is extensive and far-reaching in its
implications.
He is just waffling. There is no conclusion, just a constant twisting
and turning to find some why to persuade people that the wrong answer is
the right one. He's being doing this for years with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is putting up
anything he can think of to keep the discussion going. It should simply
have stopped once he'd been clear that H(P,P) == 0 is correct "even
though P(P) halts" but the traces and the verbiage is keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true, then it
has similar implications for computer science that disproving the
conservation law has for physics.
When a student comes to me and says that her program to add 5 and 6
gives 12, I don't, even for a moment, imagine that the laws of logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect. Lots of
people have suggested why it is incorrect. But they can't actually see
the code. PO needs to understand that no-one will accept the
complicated, far-reaching explanation, until the simple explanation
has been ruled out.
For what it's worth, I don't think there is any "dry run" going on here
at all. PO decide years ago that H(H_Hat, H_Hat) would be 0 because he
knew (correctly) that H could spot what would happen if H did not "intervene". Everything since then -- the "it only halt because...",
the "it wouldn't halt if line 15 were commented out" and the rather less explicitly stated "H_Hat does not get to its ret instruction because a
non top-level H aborts" are just the various attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually fractally
wrong, so he's not correct about almost everything he says at almost
every level. For example, at one level he now admits that a halt
decider is impossible because H(X,Y) must report "on its input" and the
call X(Y) is not an input! He did this to explain why H(P,P) is
permitted to return 0 "even though P(P) halts", but it also makes it
clear that what he one thought was that halting problem is not solvable.
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and
determines what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's
invoked H | on it and H reports that it doesn't halt. He's run
P(P) and it halts. The obvious conclusion is that PO's dry run
(if he has indeed done such a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers
spend more energy than they take in. Well potentially this is
dynamite. One explanation is that the law of conservation of
energy is wrong. Except, before we countenance that explanation,
we need to rule out a much simpler explanation. Which is that our
measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be doing,
by dry-running it, and then actually run P(P) and obtained a
different result. He also found that H agreed with the dry run.
It's hard to paraphrase his conclusion, but it is extensive and
far-reaching in its implications.
He is just waffling. There is no conclusion, just a constant
twisting and turning to find some why to persuade people that the
wrong answer is the right one. He's being doing this for years
with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is putting up
anything he can think of to keep the discussion going. It should
simply have stopped once he'd been clear that H(P,P) == 0 is
correct "even though P(P) halts" but the traces and the verbiage is
keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true, then
it has similar implications for computer science that disproving
the conservation law has for physics.
When a student comes to me and says that her program to add 5 and 6
gives 12, I don't, even for a moment, imagine that the laws of
logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect.
Lots of people have suggested why it is incorrect. But they can't
actually see the code. PO needs to understand that no-one will
accept the complicated, far-reaching explanation, until the simple
explanation has been ruled out.
For what it's worth, I don't think there is any "dry run" going on
here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
because he knew (correctly) that H could spot what would happen if
H did not "intervene". Everything since then -- the "it only halt because...", the "it wouldn't halt if line 15 were commented out"
and the rather less explicitly stated "H_Hat does not get to its
ret instruction because a non top-level H aborts" are just the
various attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually fractally
wrong, so he's not correct about almost everything he says at almost
every level. For example, at one level he now admits that a halt
decider is impossible because H(X,Y) must report "on its input" and
the call X(Y) is not an input! He did this to explain why H(P,P) is permitted to return 0 "even though P(P) halts", but it also makes it
clear that what he one thought was that halting problem is not
solvable.
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
On Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and
determines what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's
invoked H | on it and H reports that it doesn't halt. He's run
P(P) and it halts. The obvious conclusion is that PO's dry run
(if he has indeed done such a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers
spend more energy than they take in. Well potentially this is
dynamite. One explanation is that the law of conservation of
energy is wrong. Except, before we countenance that explanation,
we need to rule out a much simpler explanation. Which is that our
measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be doing,
by dry-running it, and then actually run P(P) and obtained a
different result. He also found that H agreed with the dry run.
It's hard to paraphrase his conclusion, but it is extensive and
far-reaching in its implications.
He is just waffling. There is no conclusion, just a constant
twisting and turning to find some why to persuade people that the
wrong answer is the right one. He's being doing this for years
with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is putting up
anything he can think of to keep the discussion going. It should
simply have stopped once he'd been clear that H(P,P) == 0 is
correct "even though P(P) halts" but the traces and the verbiage is
keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true, then
it has similar implications for computer science that disproving
the conservation law has for physics.
When a student comes to me and says that her program to add 5 and 6
gives 12, I don't, even for a moment, imagine that the laws of
logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect.
Lots of people have suggested why it is incorrect. But they can't
actually see the code. PO needs to understand that no-one will
accept the complicated, far-reaching explanation, until the simple
explanation has been ruled out.
For what it's worth, I don't think there is any "dry run" going on
here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
because he knew (correctly) that H could spot what would happen if
H did not "intervene". Everything since then -- the "it only halt
because...", the "it wouldn't halt if line 15 were commented out"
and the rather less explicitly stated "H_Hat does not get to its
ret instruction because a non top-level H aborts" are just the
various attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually fractally
wrong, so he's not correct about almost everything he says at almost
every level. For example, at one level he now admits that a halt
decider is impossible because H(X,Y) must report "on its input" and
the call X(Y) is not an input! He did this to explain why H(P,P) is
permitted to return 0 "even though P(P) halts", but it also makes it
clear that what he one thought was that halting problem is not
solvable.
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the pathological
input at issue here are YOUR PATHOLOGICAL LIES, Olcott.
/Flibble
On Sunday, 26 June 2022 at 00:56:03 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:If the tiger experimenters kick up a fuss about showing you their
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:Obviously.
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and determines >>>>> what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's invoked H >>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts. >>>> The obvious conclusion is that PO's dry run (if he has indeed done such >>>> a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers spend
more energy than they take in. Well potentially this is dynamite. One
explanation is that the law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to rule out a
much simpler explanation. Which is that our measurements are wrong.
notebooks, when the notebooks are available and there's no logistical
reason for the refusal, then you can dismiss the idea that they've disproved the law of conservation of energy out of hand. The two things, together,
an impossible claim and a shifty, evasive attitude make up an overwhelming case against.
If they are genuinely co-operative and try to help you, then of course it's different. It's still likely that the explanation is an error, but you keep an open
mind and, if it turns out to be something simple, you try to be as diplomatic as possible.
I think he's tied himself in knots trying to avoid the obvious. Which will happen
I agree it's never quite so simple because PO is usually fractally
wrong, so he's not correct about almost everything he says at almost
every level. For example, at one level he now admits that a halt
decider is impossible because H(X,Y) must report "on its input" and the
call X(Y) is not an input! He did this to explain why H(P,P) is
permitted to return 0 "even though P(P) halts", but it also makes it
clear that what he one thought was that halting problem is not solvable.
if you try to insist that something is true, against all the evidence.
On 6/25/2022 9:03 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and
determines what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's
invoked H | on it and H reports that it doesn't halt. He's run
P(P) and it halts. The obvious conclusion is that PO's dry run
(if he has indeed done such a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers
spend more energy than they take in. Well potentially this is
dynamite. One explanation is that the law of conservation of
energy is wrong. Except, before we countenance that explanation,
we need to rule out a much simpler explanation. Which is that our
measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be doing,
by dry-running it, and then actually run P(P) and obtained a
different result. He also found that H agreed with the dry run.
It's hard to paraphrase his conclusion, but it is extensive and
far-reaching in its implications.
He is just waffling. There is no conclusion, just a constant
twisting and turning to find some why to persuade people that the
wrong answer is the right one. He's being doing this for years
with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is putting up
anything he can think of to keep the discussion going. It should
simply have stopped once he'd been clear that H(P,P) == 0 is
correct "even though P(P) halts" but the traces and the verbiage
is keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true,
then it has similar implications for computer science that
disproving the conservation law has for physics.
When a student comes to me and says that her program to add 5 and
6 gives 12, I don't, even for a moment, imagine that the laws of
logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect.
Lots of people have suggested why it is incorrect. But they can't
actually see the code. PO needs to understand that no-one will
accept the complicated, far-reaching explanation, until the
simple explanation has been ruled out.
For what it's worth, I don't think there is any "dry run" going on
here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
because he knew (correctly) that H could spot what would happen if
H did not "intervene". Everything since then -- the "it only halt
because...", the "it wouldn't halt if line 15 were commented out"
and the rather less explicitly stated "H_Hat does not get to its
ret instruction because a non top-level H aborts" are just the
various attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually fractally
wrong, so he's not correct about almost everything he says at
almost every level. For example, at one level he now admits that
a halt decider is impossible because H(X,Y) must report "on its
input" and the call X(Y) is not an input! He did this to explain
why H(P,P) is permitted to return 0 "even though P(P) halts", but
it also makes it clear that what he one thought was that halting
problem is not solvable.
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the pathological
input at issue here are YOUR PATHOLOGICAL LIES, Olcott.
/Flibble
Computable functions are the basic objects of study in
computability theory.
Computable functions are the formalized analogue of the
intuitive notion of
algorithms, in the sense that a function is computable if there
exists an algorithm
that can do the job of the function, i.e. given an input of the function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you reject that the above proves that H and P have a
pathological relationship to each other seem to be your lack of
technical competence rather than dishonesty.
On Sun, 26 Jun 2022 05:31:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:03 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and >>>>>>>> determines what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's
invoked H | on it and H reports that it doesn't halt. He's run
P(P) and it halts. The obvious conclusion is that PO's dry run
(if he has indeed done such a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers
spend more energy than they take in. Well potentially this is
dynamite. One explanation is that the law of conservation of
energy is wrong. Except, before we countenance that explanation,
we need to rule out a much simpler explanation. Which is that our
measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be doing,
by dry-running it, and then actually run P(P) and obtained a
different result. He also found that H agreed with the dry run.
It's hard to paraphrase his conclusion, but it is extensive and
far-reaching in its implications.
He is just waffling. There is no conclusion, just a constant
twisting and turning to find some why to persuade people that the
wrong answer is the right one. He's being doing this for years
with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is putting up
anything he can think of to keep the discussion going. It should
simply have stopped once he'd been clear that H(P,P) == 0 is
correct "even though P(P) halts" but the traces and the verbiage
is keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true,
then it has similar implications for computer science that
disproving the conservation law has for physics.
When a student comes to me and says that her program to add 5 and
6 gives 12, I don't, even for a moment, imagine that the laws of
logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect.
Lots of people have suggested why it is incorrect. But they can't
actually see the code. PO needs to understand that no-one will
accept the complicated, far-reaching explanation, until the
simple explanation has been ruled out.
For what it's worth, I don't think there is any "dry run" going on
here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
because he knew (correctly) that H could spot what would happen if
H did not "intervene". Everything since then -- the "it only halt
because...", the "it wouldn't halt if line 15 were commented out"
and the rather less explicitly stated "H_Hat does not get to its
ret instruction because a non top-level H aborts" are just the
various attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually fractally
wrong, so he's not correct about almost everything he says at
almost every level. For example, at one level he now admits that
a halt decider is impossible because H(X,Y) must report "on its
input" and the call X(Y) is not an input! He did this to explain
why H(P,P) is permitted to return 0 "even though P(P) halts", but
it also makes it clear that what he one thought was that halting
problem is not solvable.
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the pathological
input at issue here are YOUR PATHOLOGICAL LIES, Olcott.
/Flibble
Computable functions are the basic objects of study in
computability theory.
Computable functions are the formalized analogue of the
intuitive notion of
algorithms, in the sense that a function is computable if there
exists an algorithm
that can do the job of the function, i.e. given an input of the
function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you reject that the above proves that H and P have a
pathological relationship to each other seem to be your lack of
technical competence rather than dishonesty.
There is nothing wrong with my technical competence however yours *is* suspect.
Nobody is denying that P is pathological input as its comes
from [Strachey, 1965]'s "Impossible Program";
the problem is you
are redefining what H means such that P no longer calls H as you prevent
that call which is equivalent to H behaving differently depending on
what is calling it: valid halt deciders don't do that. Your H is
erroneous and certainly *not* a pure function as you claim.
Your basic error (which you keep repeating) is your assumption that a
program that calls H is always pathological.
/Flibble
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and
determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's
invoked H
| on it and H reports that it doesn't halt. He's run P(P) and it halts. >>>> The obvious conclusion is that PO's dry run (if he has indeed done such >>>> a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers spend
more energy than they take in. Well potentially this is dynamite. One
explanation is that the law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to rule out a
much simpler explanation. Which is that our measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be doing, by
dry-running it, and then actually run P(P) and obtained a different
result. He also found that H agreed with the dry run. It's hard to
paraphrase his conclusion, but it is extensive and far-reaching in its
implications.
He is just waffling. There is no conclusion, just a constant twisting
and turning to find some why to persuade people that the wrong answer is
the right one. He's being doing this for years with various degrees of
obfuscation.
H does not report the correct result for P(P) and PO is putting up
anything he can think of to keep the discussion going. It should simply
have stopped once he'd been clear that H(P,P) == 0 is correct "even
though P(P) halts" but the traces and the verbiage is keeping people
keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true, then it
has similar implications for computer science that disproving the
conservation law has for physics.
When a student comes to me and says that her program to add 5 and 6
gives 12, I don't, even for a moment, imagine that the laws of logic and
mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect. Lots of
people have suggested why it is incorrect. But they can't actually see
the code. PO needs to understand that no-one will accept the
complicated, far-reaching explanation, until the simple explanation
has been ruled out.
For what it's worth, I don't think there is any "dry run" going on here
at all. PO decide years ago that H(H_Hat, H_Hat) would be 0 because he
knew (correctly) that H could spot what would happen if H did not
"intervene". Everything since then -- the "it only halt because...",
the "it wouldn't halt if line 15 were commented out" and the rather less
explicitly stated "H_Hat does not get to its ret instruction because a
non top-level H aborts" are just the various attempt at after-the-fact
justification.
I agree it's never quite so simple because PO is usually fractally
wrong, so he's not correct about almost everything he says at almost
every level. For example, at one level he now admits that a halt
decider is impossible because H(X,Y) must report "on its input" and the
call X(Y) is not an input! He did this to explain why H(P,P) is
permitted to return 0 "even though P(P) halts", but it also makes it
clear that what he one thought was that halting problem is not solvable.
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to an accept or reject state on the basis of the actual behavior that is actually
specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
On 6/25/2022 8:16 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:07:04 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:(a) is false as the reason the ret instruction is not reached is
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and
determines what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's
invoked H | on it and H reports that it doesn't halt. He's run
P(P) and it halts. The obvious conclusion is that PO's dry run
(if he has indeed done such a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers
spend more energy than they take in. Well potentially this is
dynamite. One explanation is that the law of conservation of
energy is wrong. Except, before we countenance that explanation,
we need to rule out a much simpler explanation. Which is that our
measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be doing,
by dry-running it, and then actually run P(P) and obtained a
different result. He also found that H agreed with the dry run.
It's hard to paraphrase his conclusion, but it is extensive and
far-reaching in its implications.
He is just waffling. There is no conclusion, just a constant
twisting and turning to find some why to persuade people that the
wrong answer is the right one. He's being doing this for years
with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is putting up
anything he can think of to keep the discussion going. It should
simply have stopped once he'd been clear that H(P,P) == 0 is
correct "even though P(P) halts" but the traces and the verbiage is
keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true, then
it has similar implications for computer science that disproving
the conservation law has for physics.
When a student comes to me and says that her program to add 5 and 6
gives 12, I don't, even for a moment, imagine that the laws of
logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect.
Lots of people have suggested why it is incorrect. But they can't
actually see the code. PO needs to understand that no-one will
accept the complicated, far-reaching explanation, until the simple
explanation has been ruled out.
For what it's worth, I don't think there is any "dry run" going on
here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
because he knew (correctly) that H could spot what would happen if
H did not "intervene". Everything since then -- the "it only halt
because...", the "it wouldn't halt if line 15 were commented out"
and the rather less explicitly stated "H_Hat does not get to its
ret instruction because a non top-level H aborts" are just the
various attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually fractally
wrong, so he's not correct about almost everything he says at almost
every level. For example, at one level he now admits that a halt
decider is impossible because H(X,Y) must report "on its input" and
the call X(Y) is not an input! He did this to explain why H(P,P) is
permitted to return 0 "even though P(P) halts", but it also makes it
clear that what he one thought was that halting problem is not
solvable.
(a) and (b) are proven to be verified facts entirely on the basis of
the semantics of the x86 language. (Most people here do not seem to
"believe in" the semantics of the x86 language otherwise they would
have no basis to disagree).
(a) The complete and correct x86 emulation of the input to H(P,P) by
H never reaches the "ret" instruction of P.
(b) The direct execution of P(P) does reach its "ret" instruction.
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.
P(P) is provably not the actual behavior of the actual input.
incorrect: the ret instruction should not be reached due to the
infinite loop in P and not because you abort the simulation before the
infinite loop is reached. Your H is incorrect in its assumption that P
is pathological because it calls H.
/Flibble
For any program H that might determine if programs halt, a "pathological"
program P, called with some input, can pass its own source and its input to
H and then specifically do the opposite of what H predicts P will do. No H
can exist that handles this case. https://en.wikipedia.org/wiki/Halting_problem
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
On 6/25/22 9:36 PM, olcott wrote:
On 6/25/2022 8:16 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:07:04 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:(a) is false as the reason the ret instruction is not reached is
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and >>>>>>> determines what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's
invoked H | on it and H reports that it doesn't halt. He's run
P(P) and it halts. The obvious conclusion is that PO's dry run
(if he has indeed done such a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers
spend more energy than they take in. Well potentially this is
dynamite. One explanation is that the law of conservation of
energy is wrong. Except, before we countenance that explanation,
we need to rule out a much simpler explanation. Which is that
our measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be
doing, by dry-running it, and then actually run P(P) and
obtained a different result. He also found that H agreed with
the dry run. It's hard to paraphrase his conclusion, but it is
extensive and far-reaching in its implications.
He is just waffling.� There is no conclusion, just a constant
twisting and turning to find some why to persuade people that the
wrong answer is the right one.� He's being doing this for years
with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is putting
up anything he can think of to keep the discussion going.� It
should simply have stopped once he'd been clear that H(P,P) == 0
is correct "even though P(P) halts" but the traces and the
verbiage is keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true,
then it has similar implications for computer science that
disproving the conservation law has for physics.
When a student comes to me and says that her program to add 5
and 6 gives 12, I don't, even for a moment, imagine that the
laws of logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect.
Lots of people have suggested why it is incorrect. But they
can't actually see the code. PO needs to understand that no-one
will accept the complicated, far-reaching explanation, until
the simple explanation has been ruled out.
For what it's worth, I don't think there is any "dry run" going
on here at all.� PO decide years ago that H(H_Hat, H_Hat) would
be 0 because he knew (correctly) that H could spot what would
happen if H did not "intervene".� Everything since then -- the
"it only halt because...", the "it wouldn't halt if line 15 were
commented out" and the rather less explicitly stated "H_Hat does
not get to its ret instruction because a non top-level H aborts"
are just the various attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually
fractally wrong, so he's not correct about almost everything he
says at almost every level.� For example, at one level he now
admits that a halt decider is impossible because H(X,Y) must
report "on its input" and the call X(Y) is not an input!� He did
this to explain why H(P,P) is permitted to return 0 "even though
P(P) halts", but it also makes it clear that what he one thought
was that halting problem is not solvable.
(a) and (b) are proven to be verified facts entirely on the basis
of the semantics of the x86 language. (Most people here do not
seem to "believe in" the semantics of the x86 language otherwise
they would have no basis to disagree).
(a) The complete and correct x86 emulation of the input to H(P,P)
by H never reaches the "ret" instruction of P.
(b) The direct execution of P(P) does reach its "ret" instruction.
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that
is actually specified by these inputs.
P(P) is provably not the actual behavior of the actual input.
incorrect: the ret instruction should not be reached due to the
infinite loop in P and not because you abort the simulation before
the infinite loop is reached.� Your H is incorrect in its
assumption that P is pathological because it calls H.
/Flibble
���� For any program H that might determine if programs halt, a "pathological"
���� program P, called with some input, can pass its own source
and its input to
���� H and then specifically do the opposite of what H predicts P
will do. No H
���� can exist that handles this case. https://en.wikipedia.org/wiki/Halting_problem
void P(u32 x)
{
� if (H(x, x))
��� HERE: goto HERE;
� return;
}
int main()
{
� Output("Input_Halts = ", H((u32)P, (u32)P));
}
The problem is that your "proof" of (a) is based on an "H" that ONLY
does a complete and correct emulation of its input, before making a
halting decision.
Yes, for such an H, the P built on it will be non-halting, that that
H can't report that fact, and in fact, NEVER reports that ANY
non-halting input is non-halting. That makes it not a decider.
When you fix that problem, by having your new H abort its processing,
it is a DIFFERENT H than the one above. That difference matter, and
you new H is incorrect to consider that its input P, built on it is
the same as the P that was built on the other input H. You seem to be confused becaue they are both called H.
You claim to be working under the intrepretaton of the C languge. The
C language PROHIBITS the presence of two functions by the same name
in one translation unit, or with global scope in the same program,
sine there is no "H with static scope listed in the file for P, it
MUST be a global scope H, and thus the only H that P can call is the
one deciding on it, which if you claim your H (P,P) is returning 0,
must be the one that aborts, and thus NOT the one that does the
complete and correct emulation and gets stuck in the infinite
recursion.
It is also clear that you are lying about H doing a correct x86
emulation of its input, because at the x86 level, the call to H
should create an emulation of the x86 CODE of H, not reverting to
some "functional equivalent" converting it to a notation that it is
emulating P again. Maybe that just shows that YOU don't understand
what x86 assembly code actually does. "Call H" does NOT do a
emulataion at the x86 level, it runs an emulator that it should be
tracing.
THe fact that (b) shows the x86 assembly code actually does reach its
"ret" instruction means you need to point out where the emulation of
the input and the direct execution diverge, which is at the call H instruction, which the emulation DOES'T correctly process as pointed
above, and thus your claim of a is shown to be a LIE.
On 6/26/2022 6:15 AM, Mr Flibble wrote:
On Sun, 26 Jun 2022 05:31:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:03 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code,Going back, now, to what you think needs to be resolved:
and determines what it does, without actually executing it. >>>>>>>
| He's dry-run P(P) and established that it doesn't halt. He's >>>>>>> invoked H | on it and H reports that it doesn't halt. He's run >>>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run >>>>>>> (if he has indeed done such a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers
spend more energy than they take in. Well potentially this is
dynamite. One explanation is that the law of conservation of
energy is wrong. Except, before we countenance that
explanation, we need to rule out a much simpler explanation.
Which is that our measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be
doing, by dry-running it, and then actually run P(P) and
obtained a different result. He also found that H agreed with
the dry run. It's hard to paraphrase his conclusion, but it is
extensive and far-reaching in its implications.
He is just waffling. There is no conclusion, just a constant
twisting and turning to find some why to persuade people that
the wrong answer is the right one. He's being doing this for
years with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is putting
up anything he can think of to keep the discussion going. It
should simply have stopped once he'd been clear that H(P,P) ==
0 is correct "even though P(P) halts" but the traces and the
verbiage is keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true,
then it has similar implications for computer science that
disproving the conservation law has for physics.
When a student comes to me and says that her program to add 5
and 6 gives 12, I don't, even for a moment, imagine that the
laws of logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect.
Lots of people have suggested why it is incorrect. But they
can't actually see the code. PO needs to understand that
no-one will accept the complicated, far-reaching explanation,
until the simple explanation has been ruled out.
For what it's worth, I don't think there is any "dry run" going
on here at all. PO decide years ago that H(H_Hat, H_Hat) would
be 0 because he knew (correctly) that H could spot what would
happen if H did not "intervene". Everything since then -- the
"it only halt because...", the "it wouldn't halt if line 15
were commented out" and the rather less explicitly stated
"H_Hat does not get to its ret instruction because a non
top-level H aborts" are just the various attempt at
after-the-fact justification.
I agree it's never quite so simple because PO is usually
fractally wrong, so he's not correct about almost everything he
says at almost every level. For example, at one level he now
admits that a halt decider is impossible because H(X,Y) must
report "on its input" and the call X(Y) is not an input! He
did this to explain why H(P,P) is permitted to return 0 "even
though P(P) halts", but it also makes it clear that what he one
thought was that halting problem is not solvable.
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that
is actually specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the
pathological input at issue here are YOUR PATHOLOGICAL LIES,
Olcott.
/Flibble
Computable functions are the basic objects of study in
computability theory.
Computable functions are the formalized analogue of the
intuitive notion of
algorithms, in the sense that a function is computable if
there exists an algorithm
that can do the job of the function, i.e. given an input of
the function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you reject that the above proves that H and P have a
pathological relationship to each other seem to be your lack of
technical competence rather than dishonesty.
There is nothing wrong with my technical competence however yours
*is* suspect.
Nobody is denying that P is pathological input as its comes
from [Strachey, 1965]'s "Impossible Program";
// rec routine P
// �L :if T[P] go to L
// Return �
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{
L:if (T(Strachey_P))
goto L;
return;
}
int main()
{
Output("Input_Halts = ", T(Strachey_P));
}
_Strachey_P()
[000015b2](01) 55 push ebp
[000015b3](02) 8bec mov ebp,esp
[000015b5](05) 68b2150000 push 000015b2 // push Strachey_P [000015ba](05) e813fdffff call 000012d2 // call T
[000015bf](03) 83c404 add esp,+04
[000015c2](02) 85c0 test eax,eax
[000015c4](02) 7402 jz 000015c8
[000015c6](02) ebed jmp 000015b5
[000015c8](01) 5d pop ebp
[000015c9](01) c3 ret
Size in bytes:(0024) [000015c9]
_main()
[000015d2](01) 55 push ebp
[000015d3](02) 8bec mov ebp,esp
[000015d5](05) 68b2150000 push 000015b2 // push Strachey_P [000015da](05) e8f3fcffff call 000012d2 // call T
[000015df](03) 83c404 add esp,+04
[000015e2](01) 50 push eax
[000015e3](05) 6833040000 push 00000433
[000015e8](05) e895eeffff call 00000482
[000015ed](03) 83c408 add esp,+08
[000015f0](02) 33c0 xor eax,eax
[000015f2](01) 5d pop ebp
[000015f3](01) c3 ret
Size in bytes:(0034) [000015f3]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [000015d2][001025c6][00000000] 55 push ebp [000015d3][001025c6][00000000] 8bec mov ebp,esp [000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push
Strachey_P [000015da][001025be][000015df] e8f3fcffff call 000012d2 //
call T
Begin Simulation Execution Trace Stored at:21267a
Address_of_T:12d2
[000015b2][0021266a][0021266e] 55 push ebp [000015b3][0021266a][0021266e] 8bec mov ebp,esp [000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push
Strachey_P [000015ba][00212662][000015bf] e813fdffff call 000012d2 //
call T Infinitely Recursive Simulation Detected Simulation Stopped
T knows its own machine address and on this basis it can easily
examine its stored execution_trace of Strachey_P (see above) to
determine: (a) Strachey_P is calling T with the same arguments that T
was called with. (b) No instructions in Strachey_P could possibly
escape this otherwise infinitely recursive emulation.
On 6/25/22 9:58 PM, olcott wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and
determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's
invoked H
| on it and H reports that it doesn't halt. He's run P(P) and it
halts. The obvious conclusion is that PO's dry run (if he has
indeed done such a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers
spend more energy than they take in. Well potentially this is
dynamite. One explanation is that the law of conservation of
energy is wrong. Except, before we countenance that explanation,
we need to rule out a much simpler explanation. Which is that our
measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be doing,
by dry-running it, and then actually run P(P) and obtained a
different result. He also found that H agreed with the dry run.
It's hard to paraphrase his conclusion, but it is extensive and
far-reaching in its implications.
He is just waffling.� There is no conclusion, just a constant
twisting and turning to find some why to persuade people that the
wrong answer is the right one.� He's being doing this for years
with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is putting up
anything he can think of to keep the discussion going.� It should
simply have stopped once he'd been clear that H(P,P) == 0 is
correct "even though P(P) halts" but the traces and the verbiage
is keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true,
then it has similar implications for computer science that
disproving the conservation law has for physics.
When a student comes to me and says that her program to add 5 and 6
gives 12, I don't, even for a moment, imagine that the laws of
logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect.
Lots of people have suggested why it is incorrect. But they can't
actually see the code. PO needs to understand that no-one will
accept the complicated, far-reaching explanation, until the
simple explanation has been ruled out.
For what it's worth, I don't think there is any "dry run" going on
here at all.� PO decide years ago that H(H_Hat, H_Hat) would be 0
because he knew (correctly) that H could spot what would happen if
H did not "intervene".� Everything since then -- the "it only halt
because...", the "it wouldn't halt if line 15 were commented out"
and the rather less explicitly stated "H_Hat does not get to its
ret instruction because a non top-level H aborts" are just the
various attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually fractally
wrong, so he's not correct about almost everything he says at
almost every level.� For example, at one level he now admits that
a halt decider is impossible because H(X,Y) must report "on its
input" and the call X(Y) is not an input!� He did this to explain
why H(P,P) is permitted to return 0 "even though P(P) halts", but
it also makes it clear that what he one thought was that halting
problem is not solvable.
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
Then you are lying that P and H are defined as required.
P is defined, that when given a description of itself, to ask H about
itself applied to its input. Since you say P calls H(P,P), it that
doesn't mean H is to decide on P(P), then P wasn't defined correctly,
and YOU made the error.
If H can't be asked about P(P), then H is proven to be defined
incorrectly as H must be able to be asked about ANY compuputation,
that being a program with any input, and P is a program, at least as
long as H meets the requriements for being a program.
Thus, if the input to H(P,P) is proved to have different behaviot
than P(P, you have just proved that your "counter example" fails to
meet the requirements, and thus isn't a counter example.
Thus YOU are the one shown to be not being Truthful, since your own
proof just proves that you lied about other things.
FAIL.
LIAR.
On 6/25/2022 9:03 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:The issue is what constitutes a pathological input: the pathological
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and
determines what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's
invoked H | on it and H reports that it doesn't halt. He's run
P(P) and it halts. The obvious conclusion is that PO's dry run
(if he has indeed done such a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers
spend more energy than they take in. Well potentially this is
dynamite. One explanation is that the law of conservation of
energy is wrong. Except, before we countenance that explanation,
we need to rule out a much simpler explanation. Which is that our
measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be doing,
by dry-running it, and then actually run P(P) and obtained a
different result. He also found that H agreed with the dry run.
It's hard to paraphrase his conclusion, but it is extensive and
far-reaching in its implications.
He is just waffling. There is no conclusion, just a constant
twisting and turning to find some why to persuade people that the
wrong answer is the right one. He's being doing this for years
with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is putting up
anything he can think of to keep the discussion going. It should
simply have stopped once he'd been clear that H(P,P) == 0 is
correct "even though P(P) halts" but the traces and the verbiage is
keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true, then
it has similar implications for computer science that disproving
the conservation law has for physics.
When a student comes to me and says that her program to add 5 and 6
gives 12, I don't, even for a moment, imagine that the laws of
logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect.
Lots of people have suggested why it is incorrect. But they can't
actually see the code. PO needs to understand that no-one will
accept the complicated, far-reaching explanation, until the simple
explanation has been ruled out.
For what it's worth, I don't think there is any "dry run" going on
here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
because he knew (correctly) that H could spot what would happen if
H did not "intervene". Everything since then -- the "it only halt
because...", the "it wouldn't halt if line 15 were commented out"
and the rather less explicitly stated "H_Hat does not get to its
ret instruction because a non top-level H aborts" are just the
various attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually fractally
wrong, so he's not correct about almost everything he says at almost
every level. For example, at one level he now admits that a halt
decider is impossible because H(X,Y) must report "on its input" and
the call X(Y) is not an input! He did this to explain why H(P,P) is
permitted to return 0 "even though P(P) halts", but it also makes it
clear that what he one thought was that halting problem is not
solvable.
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
input at issue here are YOUR PATHOLOGICAL LIES, Olcott.
/Flibble
Computable functions are the basic objects of study in computability theory.
Computable functions are the formalized analogue of the intuitive notion of
algorithms, in the sense that a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input of the function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you reject that the above proves that H and P have a pathological relationship to each other seem to be your lack of technical competence rather than dishonesty.
On Sun, 26 Jun 2022 11:27:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 6:15 AM, Mr Flibble wrote:
On Sun, 26 Jun 2022 05:31:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:03 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, >>>>>>>>>> and determines what it does, without actually executing it. >>>>>>>>>Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's >>>>>>>>> invoked H | on it and H reports that it doesn't halt. He's run >>>>>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run >>>>>>>>> (if he has indeed done such a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers >>>>>>>> spend more energy than they take in. Well potentially this is
dynamite. One explanation is that the law of conservation of
energy is wrong. Except, before we countenance that
explanation, we need to rule out a much simpler explanation.
Which is that our measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be
doing, by dry-running it, and then actually run P(P) and
obtained a different result. He also found that H agreed with
the dry run. It's hard to paraphrase his conclusion, but it is >>>>>>>> extensive and far-reaching in its implications.
He is just waffling. There is no conclusion, just a constant
twisting and turning to find some why to persuade people that
the wrong answer is the right one. He's being doing this for
years with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is putting
up anything he can think of to keep the discussion going. It
should simply have stopped once he'd been clear that H(P,P) ==
0 is correct "even though P(P) halts" but the traces and the
verbiage is keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true,
then it has similar implications for computer science that
disproving the conservation law has for physics.
When a student comes to me and says that her program to add 5
and 6 gives 12, I don't, even for a moment, imagine that the
laws of logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was incorrect. >>>>>>>> Lots of people have suggested why it is incorrect. But they
can't actually see the code. PO needs to understand that
no-one will accept the complicated, far-reaching explanation,
until the simple explanation has been ruled out.
For what it's worth, I don't think there is any "dry run" going
on here at all. PO decide years ago that H(H_Hat, H_Hat) would
be 0 because he knew (correctly) that H could spot what would
happen if H did not "intervene". Everything since then -- the
"it only halt because...", the "it wouldn't halt if line 15
were commented out" and the rather less explicitly stated
"H_Hat does not get to its ret instruction because a non
top-level H aborts" are just the various attempt at
after-the-fact justification.
I agree it's never quite so simple because PO is usually
fractally wrong, so he's not correct about almost everything he
says at almost every level. For example, at one level he now
admits that a halt decider is impossible because H(X,Y) must
report "on its input" and the call X(Y) is not an input! He
did this to explain why H(P,P) is permitted to return 0 "even
though P(P) halts", but it also makes it clear that what he one
thought was that halting problem is not solvable.
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that
is actually specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the
pathological input at issue here are YOUR PATHOLOGICAL LIES,
Olcott.
/Flibble
Computable functions are the basic objects of study in
computability theory.
Computable functions are the formalized analogue of the
intuitive notion of
algorithms, in the sense that a function is computable if
there exists an algorithm
that can do the job of the function, i.e. given an input of
the function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you reject that the above proves that H and P have a
pathological relationship to each other seem to be your lack of
technical competence rather than dishonesty.
There is nothing wrong with my technical competence however yours
*is* suspect.
Nobody is denying that P is pathological input as its comes
from [Strachey, 1965]'s "Impossible Program";
// rec routine P
// §L :if T[P] go to L
// Return §
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{
L:if (T(Strachey_P))
goto L;
return;
}
int main()
{
Output("Input_Halts = ", T(Strachey_P));
}
_Strachey_P()
[000015b2](01) 55 push ebp
[000015b3](02) 8bec mov ebp,esp
[000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015ba](05) e813fdffff call 000012d2 // call T
[000015bf](03) 83c404 add esp,+04
[000015c2](02) 85c0 test eax,eax
[000015c4](02) 7402 jz 000015c8
[000015c6](02) ebed jmp 000015b5
[000015c8](01) 5d pop ebp
[000015c9](01) c3 ret
Size in bytes:(0024) [000015c9]
_main()
[000015d2](01) 55 push ebp
[000015d3](02) 8bec mov ebp,esp
[000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015da](05) e8f3fcffff call 000012d2 // call T
[000015df](03) 83c404 add esp,+04
[000015e2](01) 50 push eax
[000015e3](05) 6833040000 push 00000433
[000015e8](05) e895eeffff call 00000482
[000015ed](03) 83c408 add esp,+08
[000015f0](02) 33c0 xor eax,eax
[000015f2](01) 5d pop ebp
[000015f3](01) c3 ret
Size in bytes:(0034) [000015f3]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000015d2][001025c6][00000000] 55 push ebp
[000015d3][001025c6][00000000] 8bec mov ebp,esp
[000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push
Strachey_P [000015da][001025be][000015df] e8f3fcffff call 000012d2 //
call T
Begin Simulation Execution Trace Stored at:21267a
Address_of_T:12d2
[000015b2][0021266a][0021266e] 55 push ebp
[000015b3][0021266a][0021266e] 8bec mov ebp,esp
[000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push
Strachey_P [000015ba][00212662][000015bf] e813fdffff call 000012d2 //
call T Infinitely Recursive Simulation Detected Simulation Stopped
T knows its own machine address and on this basis it can easily
examine its stored execution_trace of Strachey_P (see above) to
determine: (a) Strachey_P is calling T with the same arguments that T
was called with. (b) No instructions in Strachey_P could possibly
escape this otherwise infinitely recursive emulation.
There is no recursion in [Strachey, 1965] or the proofs based on it
that you are attempting to refute. Fail.
/Flibble
On 6/26/2022 2:26 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 14:11:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:00 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 11:27:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 6:15 AM, Mr Flibble wrote:
On Sun, 26 Jun 2022 05:31:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:03 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse >>>>>>>>>> wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the >>>>>>>>>>>> code, and determines what it does, without actually
executing it.
Going back, now, to what you think needs to be resolved: >>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt. >>>>>>>>>>> He's invoked H | on it and H reports that it doesn't halt. >>>>>>>>>>> He's run P(P) and it halts. The obvious conclusion is that >>>>>>>>>>> PO's dry run (if he has indeed done such a thing) is
incorrect.
We do our little energy budget on tigers, and find that
tigers spend more energy than they take in. Well
potentially this is dynamite. One explanation is that the >>>>>>>>>> law of conservation of energy is wrong. Except, before we >>>>>>>>>> countenance that explanation, we need to rule out a much >>>>>>>>>> simpler explanation. Which is that our measurements are
wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be >>>>>>>>>> doing, by dry-running it, and then actually run P(P) and >>>>>>>>>> obtained a different result. He also found that H agreed >>>>>>>>>> with the dry run. It's hard to paraphrase his conclusion, >>>>>>>>>> but it is extensive and far-reaching in its implications. >>>>>>>>>He is just waffling. There is no conclusion, just a
constant twisting and turning to find some why to persuade >>>>>>>>> people that the wrong answer is the right one. He's being >>>>>>>>> doing this for years with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is
putting up anything he can think of to keep the discussion >>>>>>>>> going. It should simply have stopped once he'd been clear >>>>>>>>> that H(P,P) == 0 is correct "even though P(P) halts" but the >>>>>>>>> traces and the verbiage is keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's
true, then it has similar implications for computer
science that disproving the conservation law has for
physics.
When a student comes to me and says that her program to add >>>>>>>>> 5 and 6 gives 12, I don't, even for a moment, imagine that >>>>>>>>> the laws of logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was
incorrect. Lots of people have suggested why it is
incorrect. But they can't actually see the code. PO needs >>>>>>>>>> to understand that no-one will accept the complicated,
far-reaching explanation, until the simple explanation has >>>>>>>>>> been ruled out.
For what it's worth, I don't think there is any "dry run"
going on here at all. PO decide years ago that H(H_Hat,
H_Hat) would be 0 because he knew (correctly) that H could >>>>>>>>> spot what would happen if H did not "intervene". Everything >>>>>>>>> since then -- the "it only halt because...", the "it
wouldn't halt if line 15 were commented out" and the rather >>>>>>>>> less explicitly stated "H_Hat does not get to its ret
instruction because a non top-level H aborts" are just the >>>>>>>>> various attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually
fractally wrong, so he's not correct about almost everything >>>>>>>>> he says at almost every level. For example, at one level he >>>>>>>>> now admits that a halt decider is impossible because H(X,Y) >>>>>>>>> must report "on its input" and the call X(Y) is not an
input! He did this to explain why H(P,P) is permitted to
return 0 "even though P(P) halts", but it also makes it
clear that what he one thought was that halting problem is >>>>>>>>> not solvable.
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to an >>>>>>>> accept or reject state on the basis of the actual behavior
that is actually specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input. >>>>>>>>
YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the
pathological input at issue here are YOUR PATHOLOGICAL LIES,
Olcott.
/Flibble
Computable functions are the basic objects of study in
computability theory.
Computable functions are the formalized analogue of
the intuitive notion of
algorithms, in the sense that a function is
computable if there exists an algorithm
that can do the job of the function, i.e. given an
input of the function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you reject that the above proves that H and P have a
pathological relationship to each other seem to be your lack of
technical competence rather than dishonesty.
There is nothing wrong with my technical competence however
yours *is* suspect.
Nobody is denying that P is pathological input as its comes
from [Strachey, 1965]'s "Impossible Program";
// rec routine P
// �L :if T[P] go to L
// Return �
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{
L:if (T(Strachey_P))
goto L;
return;
}
int main()
{
Output("Input_Halts = ", T(Strachey_P));
}
_Strachey_P()
[000015b2](01) 55 push ebp
[000015b3](02) 8bec mov ebp,esp
[000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015ba](05) e813fdffff call 000012d2 // call T
[000015bf](03) 83c404 add esp,+04
[000015c2](02) 85c0 test eax,eax
[000015c4](02) 7402 jz 000015c8
[000015c6](02) ebed jmp 000015b5
[000015c8](01) 5d pop ebp
[000015c9](01) c3 ret
Size in bytes:(0024) [000015c9]
_main()
[000015d2](01) 55 push ebp
[000015d3](02) 8bec mov ebp,esp
[000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015da](05) e8f3fcffff call 000012d2 // call T
[000015df](03) 83c404 add esp,+04
[000015e2](01) 50 push eax
[000015e3](05) 6833040000 push 00000433
[000015e8](05) e895eeffff call 00000482
[000015ed](03) 83c408 add esp,+08
[000015f0](02) 33c0 xor eax,eax
[000015f2](01) 5d pop ebp
[000015f3](01) c3 ret
Size in bytes:(0034) [000015f3]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000015d2][001025c6][00000000] 55 push ebp
[000015d3][001025c6][00000000] 8bec mov ebp,esp
[000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push
Strachey_P [000015da][001025be][000015df] e8f3fcffff call
000012d2 // call T
Begin Simulation Execution Trace Stored at:21267a
Address_of_T:12d2
[000015b2][0021266a][0021266e] 55 push ebp
[000015b3][0021266a][0021266e] 8bec mov ebp,esp
[000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push
Strachey_P [000015ba][00212662][000015bf] e813fdffff call
000012d2 // call T Infinitely Recursive Simulation Detected
Simulation Stopped
T knows its own machine address and on this basis it can easily
examine its stored execution_trace of Strachey_P (see above) to
determine: (a) Strachey_P is calling T with the same arguments
that T was called with. (b) No instructions in Strachey_P could
possibly escape this otherwise infinitely recursive emulation.
There is no recursion in [Strachey, 1965] or the proofs based on
it that you are attempting to refute. Fail.
/Flibble
In other words you are saying that because a non-simulating halt
decider (that has no recursive emulation) cannot correctly
determine the halt status of its input that a simulating halt
decider (that has recursive emulation) cannot correctly determine
the halt status of its input.
We have already established that your simulating halt decider gets
the answer wrong if P calls H but isn't pathological.
We have not established that at all.
H1(P,P)==1 is the non-pathological instance.
In other words if there are no black dogs in the kitchen this
proves that there are no white cats in the living room.
You are the one trying to redefine H to be something else.
/Flibble
Not something else at all.
It is merely the case that no one besides me every bothered to fully investigate the effects of applying a simulating halt decider to the
wide open (any pure function of its inputs will do) specification of
the halting problem proofs.
On 6/26/2022 2:00 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 11:27:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 6:15 AM, Mr Flibble wrote:
On Sun, 26 Jun 2022 05:31:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:03 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, >>>>>>>>>> and determines what it does, without actually executing
it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt.
He's invoked H | on it and H reports that it doesn't halt. >>>>>>>>> He's run P(P) and it halts. The obvious conclusion is that >>>>>>>>> PO's dry run (if he has indeed done such a thing) is
incorrect.
We do our little energy budget on tigers, and find that
tigers spend more energy than they take in. Well potentially >>>>>>>> this is dynamite. One explanation is that the law of
conservation of energy is wrong. Except, before we
countenance that explanation, we need to rule out a much
simpler explanation. Which is that our measurements are
wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be
doing, by dry-running it, and then actually run P(P) and
obtained a different result. He also found that H agreed with >>>>>>>> the dry run. It's hard to paraphrase his conclusion, but it
is extensive and far-reaching in its implications.
He is just waffling. There is no conclusion, just a constant
twisting and turning to find some why to persuade people that
the wrong answer is the right one. He's being doing this for
years with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is
putting up anything he can think of to keep the discussion
going. It should simply have stopped once he'd been clear
that H(P,P) == 0 is correct "even though P(P) halts" but the
traces and the verbiage is keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true, >>>>>>>> then it has similar implications for computer science that
disproving the conservation law has for physics.
When a student comes to me and says that her program to add 5
and 6 gives 12, I don't, even for a moment, imagine that the
laws of logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was
incorrect. Lots of people have suggested why it is
incorrect. But they can't actually see the code. PO needs to >>>>>>>> understand that no-one will accept the complicated,
far-reaching explanation, until the simple explanation has
been ruled out.
For what it's worth, I don't think there is any "dry run"
going on here at all. PO decide years ago that H(H_Hat,
H_Hat) would be 0 because he knew (correctly) that H could
spot what would happen if H did not "intervene". Everything
since then -- the "it only halt because...", the "it wouldn't
halt if line 15 were commented out" and the rather less
explicitly stated "H_Hat does not get to its ret instruction
because a non top-level H aborts" are just the various
attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually
fractally wrong, so he's not correct about almost everything
he says at almost every level. For example, at one level he
now admits that a halt decider is impossible because H(X,Y)
must report "on its input" and the call X(Y) is not an input!
He did this to explain why H(P,P) is permitted to return 0
"even though P(P) halts", but it also makes it clear that
what he one thought was that halting problem is not solvable.
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that
is actually specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the
pathological input at issue here are YOUR PATHOLOGICAL LIES,
Olcott.
/Flibble
Computable functions are the basic objects of study in
computability theory.
Computable functions are the formalized analogue of the
intuitive notion of
algorithms, in the sense that a function is computable if
there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you reject that the above proves that H and P have a
pathological relationship to each other seem to be your lack of
technical competence rather than dishonesty.
There is nothing wrong with my technical competence however yours
*is* suspect.
Nobody is denying that P is pathological input as its comes
from [Strachey, 1965]'s "Impossible Program";
// rec routine P
// �L :if T[P] go to L
// Return �
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{
L:if (T(Strachey_P))
goto L;
return;
}
int main()
{
Output("Input_Halts = ", T(Strachey_P));
}
_Strachey_P()
[000015b2](01) 55 push ebp
[000015b3](02) 8bec mov ebp,esp
[000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015ba](05) e813fdffff call 000012d2 // call T
[000015bf](03) 83c404 add esp,+04
[000015c2](02) 85c0 test eax,eax
[000015c4](02) 7402 jz 000015c8
[000015c6](02) ebed jmp 000015b5
[000015c8](01) 5d pop ebp
[000015c9](01) c3 ret
Size in bytes:(0024) [000015c9]
_main()
[000015d2](01) 55 push ebp
[000015d3](02) 8bec mov ebp,esp
[000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015da](05) e8f3fcffff call 000012d2 // call T
[000015df](03) 83c404 add esp,+04
[000015e2](01) 50 push eax
[000015e3](05) 6833040000 push 00000433
[000015e8](05) e895eeffff call 00000482
[000015ed](03) 83c408 add esp,+08
[000015f0](02) 33c0 xor eax,eax
[000015f2](01) 5d pop ebp
[000015f3](01) c3 ret
Size in bytes:(0034) [000015f3]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000015d2][001025c6][00000000] 55 push ebp
[000015d3][001025c6][00000000] 8bec mov ebp,esp
[000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push
Strachey_P [000015da][001025be][000015df] e8f3fcffff call 000012d2
// call T
Begin Simulation Execution Trace Stored at:21267a
Address_of_T:12d2
[000015b2][0021266a][0021266e] 55 push ebp
[000015b3][0021266a][0021266e] 8bec mov ebp,esp
[000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push
Strachey_P [000015ba][00212662][000015bf] e813fdffff call 000012d2
// call T Infinitely Recursive Simulation Detected Simulation
Stopped
T knows its own machine address and on this basis it can easily
examine its stored execution_trace of Strachey_P (see above) to
determine: (a) Strachey_P is calling T with the same arguments
that T was called with. (b) No instructions in Strachey_P could
possibly escape this otherwise infinitely recursive emulation.
There is no recursion in [Strachey, 1965] or the proofs based on it
that you are attempting to refute. Fail.
/Flibble
In other words you are saying that because a non-simulating halt
decider (that has no recursive emulation) cannot correctly determine
the halt status of its input that a simulating halt decider (that has recursive emulation) cannot correctly determine the halt status of
its input.
In other words if there are no black dogs in the kitchen this proves
that there are no white cats in the living room.
On Sun, 26 Jun 2022 14:11:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:00 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 11:27:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 6:15 AM, Mr Flibble wrote:
On Sun, 26 Jun 2022 05:31:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:03 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, >>>>>>>>>>>> and determines what it does, without actually executing >>>>>>>>>>>> it.
Going back, now, to what you think needs to be resolved: >>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt. >>>>>>>>>>> He's invoked H | on it and H reports that it doesn't halt. >>>>>>>>>>> He's run P(P) and it halts. The obvious conclusion is that >>>>>>>>>>> PO's dry run (if he has indeed done such a thing) is
incorrect.
We do our little energy budget on tigers, and find that
tigers spend more energy than they take in. Well potentially >>>>>>>>>> this is dynamite. One explanation is that the law of
conservation of energy is wrong. Except, before we
countenance that explanation, we need to rule out a much
simpler explanation. Which is that our measurements are
wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be >>>>>>>>>> doing, by dry-running it, and then actually run P(P) and
obtained a different result. He also found that H agreed with >>>>>>>>>> the dry run. It's hard to paraphrase his conclusion, but it >>>>>>>>>> is extensive and far-reaching in its implications.
He is just waffling. There is no conclusion, just a constant >>>>>>>>> twisting and turning to find some why to persuade people that >>>>>>>>> the wrong answer is the right one. He's being doing this for >>>>>>>>> years with various degrees of obfuscation.
H does not report the correct result for P(P) and PO is
putting up anything he can think of to keep the discussion
going. It should simply have stopped once he'd been clear
that H(P,P) == 0 is correct "even though P(P) halts" but the >>>>>>>>> traces and the verbiage is keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's true, >>>>>>>>>> then it has similar implications for computer science that >>>>>>>>>> disproving the conservation law has for physics.
When a student comes to me and says that her program to add 5 >>>>>>>>> and 6 gives 12, I don't, even for a moment, imagine that the >>>>>>>>> laws of logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was
incorrect. Lots of people have suggested why it is
incorrect. But they can't actually see the code. PO needs to >>>>>>>>>> understand that no-one will accept the complicated,
far-reaching explanation, until the simple explanation has >>>>>>>>>> been ruled out.
For what it's worth, I don't think there is any "dry run"
going on here at all. PO decide years ago that H(H_Hat,
H_Hat) would be 0 because he knew (correctly) that H could
spot what would happen if H did not "intervene". Everything >>>>>>>>> since then -- the "it only halt because...", the "it wouldn't >>>>>>>>> halt if line 15 were commented out" and the rather less
explicitly stated "H_Hat does not get to its ret instruction >>>>>>>>> because a non top-level H aborts" are just the various
attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually
fractally wrong, so he's not correct about almost everything >>>>>>>>> he says at almost every level. For example, at one level he >>>>>>>>> now admits that a halt decider is impossible because H(X,Y)
must report "on its input" and the call X(Y) is not an input! >>>>>>>>> He did this to explain why H(P,P) is permitted to return 0 >>>>>>>>> "even though P(P) halts", but it also makes it clear that
what he one thought was that halting problem is not solvable. >>>>>>>>>
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that >>>>>>>> is actually specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the
pathological input at issue here are YOUR PATHOLOGICAL LIES,
Olcott.
/Flibble
Computable functions are the basic objects of study in
computability theory.
Computable functions are the formalized analogue of the
intuitive notion of
algorithms, in the sense that a function is computable if >>>>>> there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you reject that the above proves that H and P have a
pathological relationship to each other seem to be your lack of
technical competence rather than dishonesty.
There is nothing wrong with my technical competence however yours
*is* suspect.
Nobody is denying that P is pathological input as its comes
from [Strachey, 1965]'s "Impossible Program";
// rec routine P
// §L :if T[P] go to L
// Return §
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{
L:if (T(Strachey_P))
goto L;
return;
}
int main()
{
Output("Input_Halts = ", T(Strachey_P));
}
_Strachey_P()
[000015b2](01) 55 push ebp
[000015b3](02) 8bec mov ebp,esp
[000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015ba](05) e813fdffff call 000012d2 // call T
[000015bf](03) 83c404 add esp,+04
[000015c2](02) 85c0 test eax,eax
[000015c4](02) 7402 jz 000015c8
[000015c6](02) ebed jmp 000015b5
[000015c8](01) 5d pop ebp
[000015c9](01) c3 ret
Size in bytes:(0024) [000015c9]
_main()
[000015d2](01) 55 push ebp
[000015d3](02) 8bec mov ebp,esp
[000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015da](05) e8f3fcffff call 000012d2 // call T
[000015df](03) 83c404 add esp,+04
[000015e2](01) 50 push eax
[000015e3](05) 6833040000 push 00000433
[000015e8](05) e895eeffff call 00000482
[000015ed](03) 83c408 add esp,+08
[000015f0](02) 33c0 xor eax,eax
[000015f2](01) 5d pop ebp
[000015f3](01) c3 ret
Size in bytes:(0034) [000015f3]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000015d2][001025c6][00000000] 55 push ebp
[000015d3][001025c6][00000000] 8bec mov ebp,esp
[000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push
Strachey_P [000015da][001025be][000015df] e8f3fcffff call 000012d2
// call T
Begin Simulation Execution Trace Stored at:21267a
Address_of_T:12d2
[000015b2][0021266a][0021266e] 55 push ebp
[000015b3][0021266a][0021266e] 8bec mov ebp,esp
[000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push
Strachey_P [000015ba][00212662][000015bf] e813fdffff call 000012d2
// call T Infinitely Recursive Simulation Detected Simulation
Stopped
T knows its own machine address and on this basis it can easily
examine its stored execution_trace of Strachey_P (see above) to
determine: (a) Strachey_P is calling T with the same arguments
that T was called with. (b) No instructions in Strachey_P could
possibly escape this otherwise infinitely recursive emulation.
There is no recursion in [Strachey, 1965] or the proofs based on it
that you are attempting to refute. Fail.
/Flibble
In other words you are saying that because a non-simulating halt
decider (that has no recursive emulation) cannot correctly determine
the halt status of its input that a simulating halt decider (that has
recursive emulation) cannot correctly determine the halt status of
its input.
We have already established that your simulating halt decider gets the
answer wrong if P calls H but isn't pathological.
In other words if there are no black dogs in the kitchen this proves
that there are no white cats in the living room.
You are the one trying to redefine H to be something else.
/Flibble
On Sun, 26 Jun 2022 14:37:36 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:26 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 14:11:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:00 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 11:27:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 6:15 AM, Mr Flibble wrote:
On Sun, 26 Jun 2022 05:31:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:03 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>>>>>>>>>
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse >>>>>>>>>>>> wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the >>>>>>>>>>>>>> code, and determines what it does, without actually >>>>>>>>>>>>>> executing it.
Going back, now, to what you think needs to be resolved: >>>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt. >>>>>>>>>>>>> He's invoked H | on it and H reports that it doesn't halt. >>>>>>>>>>>>> He's run P(P) and it halts. The obvious conclusion is that >>>>>>>>>>>>> PO's dry run (if he has indeed done such a thing) is >>>>>>>>>>>>> incorrect.
We do our little energy budget on tigers, and find that >>>>>>>>>>>> tigers spend more energy than they take in. Well
potentially this is dynamite. One explanation is that the >>>>>>>>>>>> law of conservation of energy is wrong. Except, before we >>>>>>>>>>>> countenance that explanation, we need to rule out a much >>>>>>>>>>>> simpler explanation. Which is that our measurements are >>>>>>>>>>>> wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should be >>>>>>>>>>>> doing, by dry-running it, and then actually run P(P) and >>>>>>>>>>>> obtained a different result. He also found that H agreed >>>>>>>>>>>> with the dry run. It's hard to paraphrase his conclusion, >>>>>>>>>>>> but it is extensive and far-reaching in its implications. >>>>>>>>>>>He is just waffling. There is no conclusion, just a
constant twisting and turning to find some why to persuade >>>>>>>>>>> people that the wrong answer is the right one. He's being >>>>>>>>>>> doing this for years with various degrees of obfuscation. >>>>>>>>>>>
H does not report the correct result for P(P) and PO is
putting up anything he can think of to keep the discussion >>>>>>>>>>> going. It should simply have stopped once he'd been clear >>>>>>>>>>> that H(P,P) == 0 is correct "even though P(P) halts" but the >>>>>>>>>>> traces and the verbiage is keeping people keen.
The behaviour of code when run is different from the
correct behaviour of the code when simulated. If that's >>>>>>>>>>>> true, then it has similar implications for computer
science that disproving the conservation law has for
physics.
When a student comes to me and says that her program to add >>>>>>>>>>> 5 and 6 gives 12, I don't, even for a moment, imagine that >>>>>>>>>>> the laws of logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was
incorrect. Lots of people have suggested why it is
incorrect. But they can't actually see the code. PO needs >>>>>>>>>>>> to understand that no-one will accept the complicated, >>>>>>>>>>>> far-reaching explanation, until the simple explanation has >>>>>>>>>>>> been ruled out.
For what it's worth, I don't think there is any "dry run" >>>>>>>>>>> going on here at all. PO decide years ago that H(H_Hat, >>>>>>>>>>> H_Hat) would be 0 because he knew (correctly) that H could >>>>>>>>>>> spot what would happen if H did not "intervene". Everything >>>>>>>>>>> since then -- the "it only halt because...", the "it
wouldn't halt if line 15 were commented out" and the rather >>>>>>>>>>> less explicitly stated "H_Hat does not get to its ret
instruction because a non top-level H aborts" are just the >>>>>>>>>>> various attempt at after-the-fact justification.
I agree it's never quite so simple because PO is usually >>>>>>>>>>> fractally wrong, so he's not correct about almost everything >>>>>>>>>>> he says at almost every level. For example, at one level he >>>>>>>>>>> now admits that a halt decider is impossible because H(X,Y) >>>>>>>>>>> must report "on its input" and the call X(Y) is not an
input! He did this to explain why H(P,P) is permitted to >>>>>>>>>>> return 0 "even though P(P) halts", but it also makes it
clear that what he one thought was that halting problem is >>>>>>>>>>> not solvable.
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to an >>>>>>>>>> accept or reject state on the basis of the actual behavior >>>>>>>>>> that is actually specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input. >>>>>>>>>>
YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the
pathological input at issue here are YOUR PATHOLOGICAL LIES, >>>>>>>>> Olcott.
/Flibble
Computable functions are the basic objects of study in >>>>>>>> computability theory.
Computable functions are the formalized analogue of
the intuitive notion of
algorithms, in the sense that a function is
computable if there exists an algorithm
that can do the job of the function, i.e. given an
input of the function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you reject that the above proves that H and P have a
pathological relationship to each other seem to be your lack of >>>>>>>> technical competence rather than dishonesty.
There is nothing wrong with my technical competence however
yours *is* suspect.
Nobody is denying that P is pathological input as its comes
from [Strachey, 1965]'s "Impossible Program";
// rec routine P
// §L :if T[P] go to L
// Return §
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{
L:if (T(Strachey_P))
goto L;
return;
}
int main()
{
Output("Input_Halts = ", T(Strachey_P));
}
_Strachey_P()
[000015b2](01) 55 push ebp
[000015b3](02) 8bec mov ebp,esp
[000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015ba](05) e813fdffff call 000012d2 // call T
[000015bf](03) 83c404 add esp,+04
[000015c2](02) 85c0 test eax,eax
[000015c4](02) 7402 jz 000015c8
[000015c6](02) ebed jmp 000015b5
[000015c8](01) 5d pop ebp
[000015c9](01) c3 ret
Size in bytes:(0024) [000015c9]
_main()
[000015d2](01) 55 push ebp
[000015d3](02) 8bec mov ebp,esp
[000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015da](05) e8f3fcffff call 000012d2 // call T
[000015df](03) 83c404 add esp,+04
[000015e2](01) 50 push eax
[000015e3](05) 6833040000 push 00000433
[000015e8](05) e895eeffff call 00000482
[000015ed](03) 83c408 add esp,+08
[000015f0](02) 33c0 xor eax,eax
[000015f2](01) 5d pop ebp
[000015f3](01) c3 ret
Size in bytes:(0034) [000015f3]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000015d2][001025c6][00000000] 55 push ebp
[000015d3][001025c6][00000000] 8bec mov ebp,esp
[000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push
Strachey_P [000015da][001025be][000015df] e8f3fcffff call
000012d2 // call T
Begin Simulation Execution Trace Stored at:21267a
Address_of_T:12d2
[000015b2][0021266a][0021266e] 55 push ebp
[000015b3][0021266a][0021266e] 8bec mov ebp,esp
[000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push
Strachey_P [000015ba][00212662][000015bf] e813fdffff call
000012d2 // call T Infinitely Recursive Simulation Detected
Simulation Stopped
T knows its own machine address and on this basis it can easily
examine its stored execution_trace of Strachey_P (see above) to
determine: (a) Strachey_P is calling T with the same arguments
that T was called with. (b) No instructions in Strachey_P could
possibly escape this otherwise infinitely recursive emulation.
There is no recursion in [Strachey, 1965] or the proofs based on
it that you are attempting to refute. Fail.
/Flibble
In other words you are saying that because a non-simulating halt
decider (that has no recursive emulation) cannot correctly
determine the halt status of its input that a simulating halt
decider (that has recursive emulation) cannot correctly determine
the halt status of its input.
We have already established that your simulating halt decider gets
the answer wrong if P calls H but isn't pathological.
We have not established that at all.
Yes we have:
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 ...[000013eb][00102353][00000000] 50 push eax ...[000013ec][0010234f][00000427] 6827040000 push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 ...[000013f9][00102357][00000000] 33c0 xor eax,eax ...[000013fb][0010235b][00100000] 5d pop ebp ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but it is obvious that Px should always halt if H is a valid halt decider that
always returns a decision to its caller (Px). Olcott's H does not
return a decision to its caller (Px) and is thus invalid.
H1(P,P)==1 is the non-pathological instance.
See above.
In other words if there are no black dogs in the kitchen this
proves that there are no white cats in the living room.
You are the one trying to redefine H to be something else.
/Flibble
Not something else at all.
It is merely the case that no one besides me every bothered to fully
investigate the effects of applying a simulating halt decider to the
wide open (any pure function of its inputs will do) specification of
the halting problem proofs.
A simulating halt decider is invalid as it cannot return an answer of non-halting in finite time for all non-halting inputs as there is no
proven algorithm that can detect non-halting behaviour for the general
case.
/Flibble
On 6/26/2022 2:43 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 14:37:36 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:26 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 14:11:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:00 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 11:27:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 6:15 AM, Mr Flibble wrote:
On Sun, 26 Jun 2022 05:31:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:03 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>>>>>>>>>
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse >>>>>>>>>>>> wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the >>>>>>>>>>>>>> code, and determines what it does, without actually >>>>>>>>>>>>>> executing it.
Going back, now, to what you think needs to be resolved: >>>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't >>>>>>>>>>>>> halt. He's invoked H | on it and H reports that it >>>>>>>>>>>>> doesn't halt. He's run P(P) and it halts. The obvious >>>>>>>>>>>>> conclusion is that PO's dry run (if he has indeed done >>>>>>>>>>>>> such a thing) is incorrect.
We do our little energy budget on tigers, and find that >>>>>>>>>>>> tigers spend more energy than they take in. Well
potentially this is dynamite. One explanation is that the >>>>>>>>>>>> law of conservation of energy is wrong. Except, before we >>>>>>>>>>>> countenance that explanation, we need to rule out a much >>>>>>>>>>>> simpler explanation. Which is that our measurements are >>>>>>>>>>>> wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should >>>>>>>>>>>> be doing, by dry-running it, and then actually run P(P) >>>>>>>>>>>> and obtained a different result. He also found that H >>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his >>>>>>>>>>>> conclusion, but it is extensive and far-reaching in its >>>>>>>>>>>> implications.
He is just waffling. There is no conclusion, just a
constant twisting and turning to find some why to persuade >>>>>>>>>>> people that the wrong answer is the right one. He's being >>>>>>>>>>> doing this for years with various degrees of obfuscation. >>>>>>>>>>>
H does not report the correct result for P(P) and PO is >>>>>>>>>>> putting up anything he can think of to keep the discussion >>>>>>>>>>> going. It should simply have stopped once he'd been clear >>>>>>>>>>> that H(P,P) == 0 is correct "even though P(P) halts" but >>>>>>>>>>> the traces and the verbiage is keeping people keen. >>>>>>>>>>>> The behaviour of code when run is different from the >>>>>>>>>>>> correct behaviour of the code when simulated. If that's >>>>>>>>>>>> true, then it has similar implications for computer
science that disproving the conservation law has for >>>>>>>>>>>> physics.
When a student comes to me and says that her program to >>>>>>>>>>> add 5 and 6 gives 12, I don't, even for a moment, imagine >>>>>>>>>>> that the laws of logic and mathematics are in doubt.
But the obvious explanation is that the dry-run was
incorrect. Lots of people have suggested why it is
incorrect. But they can't actually see the code. PO needs >>>>>>>>>>>> to understand that no-one will accept the complicated, >>>>>>>>>>>> far-reaching explanation, until the simple explanation >>>>>>>>>>>> has been ruled out.
For what it's worth, I don't think there is any "dry run" >>>>>>>>>>> going on here at all. PO decide years ago that H(H_Hat, >>>>>>>>>>> H_Hat) would be 0 because he knew (correctly) that H could >>>>>>>>>>> spot what would happen if H did not "intervene".
Everything since then -- the "it only halt because...", >>>>>>>>>>> the "it wouldn't halt if line 15 were commented out" and >>>>>>>>>>> the rather less explicitly stated "H_Hat does not get to >>>>>>>>>>> its ret instruction because a non top-level H aborts" are >>>>>>>>>>> just the various attempt at after-the-fact justification. >>>>>>>>>>>
I agree it's never quite so simple because PO is usually >>>>>>>>>>> fractally wrong, so he's not correct about almost
everything he says at almost every level. For example, >>>>>>>>>>> at one level he now admits that a halt decider is
impossible because H(X,Y) must report "on its input" and >>>>>>>>>>> the call X(Y) is not an input! He did this to explain why >>>>>>>>>>> H(P,P) is permitted to return 0 "even though P(P) halts", >>>>>>>>>>> but it also makes it clear that what he one thought was >>>>>>>>>>> that halting problem is not solvable.
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to >>>>>>>>>> an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual
input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the
pathological input at issue here are YOUR PATHOLOGICAL LIES, >>>>>>>>> Olcott.
/Flibble
Computable functions are the basic objects of
study in computability theory.
Computable functions are the formalized analogue of >>>>>>>> the intuitive notion of
algorithms, in the sense that a function is
computable if there exists an algorithm
that can do the job of the function, i.e. given an >>>>>>>> input of the function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you reject that the above proves that H and P have a
pathological relationship to each other seem to be your lack >>>>>>>> of technical competence rather than dishonesty.
There is nothing wrong with my technical competence however
yours *is* suspect.
Nobody is denying that P is pathological input as its comes
from [Strachey, 1965]'s "Impossible Program";
// rec routine P
// �L :if T[P] go to L
// Return �
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{
L:if (T(Strachey_P))
goto L;
return;
}
int main()
{
Output("Input_Halts = ", T(Strachey_P));
}
_Strachey_P()
[000015b2](01) 55 push ebp
[000015b3](02) 8bec mov ebp,esp
[000015b5](05) 68b2150000 push 000015b2 // push
Strachey_P [000015ba](05) e813fdffff call 000012d2 //
call T [000015bf](03) 83c404 add esp,+04
[000015c2](02) 85c0 test eax,eax
[000015c4](02) 7402 jz 000015c8
[000015c6](02) ebed jmp 000015b5
[000015c8](01) 5d pop ebp
[000015c9](01) c3 ret
Size in bytes:(0024) [000015c9]
_main()
[000015d2](01) 55 push ebp
[000015d3](02) 8bec mov ebp,esp
[000015d5](05) 68b2150000 push 000015b2 // push
Strachey_P [000015da](05) e8f3fcffff call 000012d2 //
call T [000015df](03) 83c404 add esp,+04
[000015e2](01) 50 push eax
[000015e3](05) 6833040000 push 00000433
[000015e8](05) e895eeffff call 00000482
[000015ed](03) 83c408 add esp,+08
[000015f0](02) 33c0 xor eax,eax
[000015f2](01) 5d pop ebp
[000015f3](01) c3 ret
Size in bytes:(0034) [000015f3]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000015d2][001025c6][00000000] 55 push ebp
[000015d3][001025c6][00000000] 8bec mov ebp,esp
[000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push
Strachey_P [000015da][001025be][000015df] e8f3fcffff call
000012d2 // call T
Begin Simulation Execution Trace Stored at:21267a
Address_of_T:12d2
[000015b2][0021266a][0021266e] 55 push ebp
[000015b3][0021266a][0021266e] 8bec mov ebp,esp
[000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push
Strachey_P [000015ba][00212662][000015bf] e813fdffff call
000012d2 // call T Infinitely Recursive Simulation Detected
Simulation Stopped
T knows its own machine address and on this basis it can easily
examine its stored execution_trace of Strachey_P (see above) to
determine: (a) Strachey_P is calling T with the same arguments
that T was called with. (b) No instructions in Strachey_P could
possibly escape this otherwise infinitely recursive emulation.
There is no recursion in [Strachey, 1965] or the proofs based on
it that you are attempting to refute. Fail.
/Flibble
In other words you are saying that because a non-simulating halt
decider (that has no recursive emulation) cannot correctly
determine the halt status of its input that a simulating halt
decider (that has recursive emulation) cannot correctly determine
the halt status of its input.
We have already established that your simulating halt decider gets
the answer wrong if P calls H but isn't pathological.
We have not established that at all.
Yes we have:
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 ...[000013eb][00102353][00000000] 50 push eax ...[000013ec][0010234f][00000427] 6827040000 push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 ...[000013f9][00102357][00000000] 33c0 xor eax,eax ...[000013fb][0010235b][00100000] 5d pop ebp ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
H1(P,P)==1 is the non-pathological instance.
See above.
In other words if there are no black dogs in the kitchen this
proves that there are no white cats in the living room.
You are the one trying to redefine H to be something else.
/Flibble
Not something else at all.
It is merely the case that no one besides me every bothered to
fully investigate the effects of applying a simulating halt
decider to the wide open (any pure function of its inputs will do)
specification of the halting problem proofs.
A simulating halt decider is invalid as it cannot return an answer
of non-halting in finite time for all non-halting inputs as there
is no proven algorithm that can detect non-halting behaviour for
the general case.
/Flibble
We are back to your lack of sufficient software engineering skill.
You still don't understand that everything after P's function call to
H(P,P) is unreachable by P from:
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
This means that erasing the infinite loop can have no effect.
Here is the actual non-pathological input to H1(P,P):
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
H1(P,P)==1.
On Sun, 26 Jun 2022 14:54:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:43 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 14:37:36 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:26 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 14:11:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:00 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 11:27:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 6:15 AM, Mr Flibble wrote:
On Sun, 26 Jun 2022 05:31:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:03 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>>>>>>>>>>>
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse >>>>>>>>>>>>>> wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>>>>>>>>>>>>Exactly.
"Dry run" means that a human programmer looks at the >>>>>>>>>>>>>>>> code, and determines what it does, without actually >>>>>>>>>>>>>>>> executing it.
Going back, now, to what you think needs to be resolved: >>>>>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't >>>>>>>>>>>>>>> halt. He's invoked H | on it and H reports that it >>>>>>>>>>>>>>> doesn't halt. He's run P(P) and it halts. The obvious >>>>>>>>>>>>>>> conclusion is that PO's dry run (if he has indeed done >>>>>>>>>>>>>>> such a thing) is incorrect.
We do our little energy budget on tigers, and find that >>>>>>>>>>>>>> tigers spend more energy than they take in. Well
potentially this is dynamite. One explanation is that the >>>>>>>>>>>>>> law of conservation of energy is wrong. Except, before we >>>>>>>>>>>>>> countenance that explanation, we need to rule out a much >>>>>>>>>>>>>> simpler explanation. Which is that our measurements are >>>>>>>>>>>>>> wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should >>>>>>>>>>>>>> be doing, by dry-running it, and then actually run P(P) >>>>>>>>>>>>>> and obtained a different result. He also found that H >>>>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his >>>>>>>>>>>>>> conclusion, but it is extensive and far-reaching in its >>>>>>>>>>>>>> implications.
He is just waffling. There is no conclusion, just a >>>>>>>>>>>>> constant twisting and turning to find some why to persuade >>>>>>>>>>>>> people that the wrong answer is the right one. He's being >>>>>>>>>>>>> doing this for years with various degrees of obfuscation. >>>>>>>>>>>>>
H does not report the correct result for P(P) and PO is >>>>>>>>>>>>> putting up anything he can think of to keep the discussion >>>>>>>>>>>>> going. It should simply have stopped once he'd been clear >>>>>>>>>>>>> that H(P,P) == 0 is correct "even though P(P) halts" but >>>>>>>>>>>>> the traces and the verbiage is keeping people keen. >>>>>>>>>>>>>> The behaviour of code when run is different from the >>>>>>>>>>>>>> correct behaviour of the code when simulated. If that's >>>>>>>>>>>>>> true, then it has similar implications for computer >>>>>>>>>>>>>> science that disproving the conservation law has for >>>>>>>>>>>>>> physics.
When a student comes to me and says that her program to >>>>>>>>>>>>> add 5 and 6 gives 12, I don't, even for a moment, imagine >>>>>>>>>>>>> that the laws of logic and mathematics are in doubt. >>>>>>>>>>>>>
But the obvious explanation is that the dry-run was >>>>>>>>>>>>>> incorrect. Lots of people have suggested why it is >>>>>>>>>>>>>> incorrect. But they can't actually see the code. PO needs >>>>>>>>>>>>>> to understand that no-one will accept the complicated, >>>>>>>>>>>>>> far-reaching explanation, until the simple explanation >>>>>>>>>>>>>> has been ruled out.
For what it's worth, I don't think there is any "dry run" >>>>>>>>>>>>> going on here at all. PO decide years ago that H(H_Hat, >>>>>>>>>>>>> H_Hat) would be 0 because he knew (correctly) that H could >>>>>>>>>>>>> spot what would happen if H did not "intervene".
Everything since then -- the "it only halt because...", >>>>>>>>>>>>> the "it wouldn't halt if line 15 were commented out" and >>>>>>>>>>>>> the rather less explicitly stated "H_Hat does not get to >>>>>>>>>>>>> its ret instruction because a non top-level H aborts" are >>>>>>>>>>>>> just the various attempt at after-the-fact justification. >>>>>>>>>>>>>
I agree it's never quite so simple because PO is usually >>>>>>>>>>>>> fractally wrong, so he's not correct about almost
everything he says at almost every level. For example, >>>>>>>>>>>>> at one level he now admits that a halt decider is
impossible because H(X,Y) must report "on its input" and >>>>>>>>>>>>> the call X(Y) is not an input! He did this to explain why >>>>>>>>>>>>> H(P,P) is permitted to return 0 "even though P(P) halts", >>>>>>>>>>>>> but it also makes it clear that what he one thought was >>>>>>>>>>>>> that halting problem is not solvable.
YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to >>>>>>>>>>>> an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual >>>>>>>>>>>> input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the
pathological input at issue here are YOUR PATHOLOGICAL LIES, >>>>>>>>>>> Olcott.
/Flibble
Computable functions are the basic objects of
study in computability theory.
Computable functions are the formalized analogue of >>>>>>>>>> the intuitive notion of
algorithms, in the sense that a function is
computable if there exists an algorithm
that can do the job of the function, i.e. given an >>>>>>>>>> input of the function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function >>>>>>>>>>
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you reject that the above proves that H and P have a
pathological relationship to each other seem to be your lack >>>>>>>>>> of technical competence rather than dishonesty.
There is nothing wrong with my technical competence however
yours *is* suspect.
Nobody is denying that P is pathological input as its comes
from [Strachey, 1965]'s "Impossible Program";
// rec routine P
// §L :if T[P] go to L
// Return §
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{
L:if (T(Strachey_P))
goto L;
return;
}
int main()
{
Output("Input_Halts = ", T(Strachey_P));
}
_Strachey_P()
[000015b2](01) 55 push ebp
[000015b3](02) 8bec mov ebp,esp
[000015b5](05) 68b2150000 push 000015b2 // push
Strachey_P [000015ba](05) e813fdffff call 000012d2 //
call T [000015bf](03) 83c404 add esp,+04
[000015c2](02) 85c0 test eax,eax
[000015c4](02) 7402 jz 000015c8
[000015c6](02) ebed jmp 000015b5
[000015c8](01) 5d pop ebp
[000015c9](01) c3 ret
Size in bytes:(0024) [000015c9]
_main()
[000015d2](01) 55 push ebp
[000015d3](02) 8bec mov ebp,esp
[000015d5](05) 68b2150000 push 000015b2 // push
Strachey_P [000015da](05) e8f3fcffff call 000012d2 //
call T [000015df](03) 83c404 add esp,+04
[000015e2](01) 50 push eax
[000015e3](05) 6833040000 push 00000433
[000015e8](05) e895eeffff call 00000482
[000015ed](03) 83c408 add esp,+08
[000015f0](02) 33c0 xor eax,eax
[000015f2](01) 5d pop ebp
[000015f3](01) c3 ret
Size in bytes:(0034) [000015f3]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000015d2][001025c6][00000000] 55 push ebp
[000015d3][001025c6][00000000] 8bec mov ebp,esp
[000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push >>>>>>>> Strachey_P [000015da][001025be][000015df] e8f3fcffff call
000012d2 // call T
Begin Simulation Execution Trace Stored at:21267a
Address_of_T:12d2
[000015b2][0021266a][0021266e] 55 push ebp
[000015b3][0021266a][0021266e] 8bec mov ebp,esp
[000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push >>>>>>>> Strachey_P [000015ba][00212662][000015bf] e813fdffff call
000012d2 // call T Infinitely Recursive Simulation Detected
Simulation Stopped
T knows its own machine address and on this basis it can easily >>>>>>>> examine its stored execution_trace of Strachey_P (see above) to >>>>>>>> determine: (a) Strachey_P is calling T with the same arguments >>>>>>>> that T was called with. (b) No instructions in Strachey_P could >>>>>>>> possibly escape this otherwise infinitely recursive emulation. >>>>>>>>
There is no recursion in [Strachey, 1965] or the proofs based on >>>>>>> it that you are attempting to refute. Fail.
/Flibble
In other words you are saying that because a non-simulating halt
decider (that has no recursive emulation) cannot correctly
determine the halt status of its input that a simulating halt
decider (that has recursive emulation) cannot correctly determine
the halt status of its input.
We have already established that your simulating halt decider gets
the answer wrong if P calls H but isn't pathological.
We have not established that at all.
Yes we have:
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
H1(P,P)==1 is the non-pathological instance.
See above.
In other words if there are no black dogs in the kitchen this
proves that there are no white cats in the living room.
You are the one trying to redefine H to be something else.
/Flibble
Not something else at all.
It is merely the case that no one besides me every bothered to
fully investigate the effects of applying a simulating halt
decider to the wide open (any pure function of its inputs will do)
specification of the halting problem proofs.
A simulating halt decider is invalid as it cannot return an answer
of non-halting in finite time for all non-halting inputs as there
is no proven algorithm that can detect non-halting behaviour for
the general case.
/Flibble
We are back to your lack of sufficient software engineering skill.
You still don't understand that everything after P's function call to
H(P,P) is unreachable by P from:
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
This means that erasing the infinite loop can have no effect.
Here is the actual non-pathological input to H1(P,P):
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
H1(P,P)==1.
The only reason erasing the infinite loop has no effect is because your
H aborts the simulation which is an invalid thing to do.
/Flibble
On 6/26/2022 3:15 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 14:54:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:43 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 14:37:36 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:26 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 14:11:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:00 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 11:27:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 6:15 AM, Mr Flibble wrote:
On Sun, 26 Jun 2022 05:31:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:03 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>>>>>>>>>>>YOU KNOW THAT THIS IS TRUE
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben
Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>>>>>>>>>>>>Exactly.
"Dry run" means that a human programmer looks at the >>>>>>>>>>>>>>>> code, and determines what it does, without actually >>>>>>>>>>>>>>>> executing it.
Going back, now, to what you think needs to be >>>>>>>>>>>>>>> resolved: | He's dry-run P(P) and established that it >>>>>>>>>>>>>>> doesn't halt. He's invoked H | on it and H reports >>>>>>>>>>>>>>> that it doesn't halt. He's run P(P) and it halts. The >>>>>>>>>>>>>>> obvious conclusion is that PO's dry run (if he has >>>>>>>>>>>>>>> indeed done such a thing) is incorrect.
We do our little energy budget on tigers, and find that >>>>>>>>>>>>>> tigers spend more energy than they take in. Well >>>>>>>>>>>>>> potentially this is dynamite. One explanation is that >>>>>>>>>>>>>> the law of conservation of energy is wrong. Except, >>>>>>>>>>>>>> before we countenance that explanation, we need to >>>>>>>>>>>>>> rule out a much simpler explanation. Which is that our >>>>>>>>>>>>>> measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should >>>>>>>>>>>>>> be doing, by dry-running it, and then actually run P(P) >>>>>>>>>>>>>> and obtained a different result. He also found that H >>>>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his >>>>>>>>>>>>>> conclusion, but it is extensive and far-reaching in its >>>>>>>>>>>>>> implications.
He is just waffling. There is no conclusion, just a >>>>>>>>>>>>> constant twisting and turning to find some why to
persuade people that the wrong answer is the right one. >>>>>>>>>>>>> He's being doing this for years with various degrees >>>>>>>>>>>>> of obfuscation.
H does not report the correct result for P(P) and PO is >>>>>>>>>>>>> putting up anything he can think of to keep the
discussion going. It should simply have stopped once >>>>>>>>>>>>> he'd been clear that H(P,P) == 0 is correct "even
though P(P) halts" but the traces and the verbiage is >>>>>>>>>>>>> keeping people keen.
The behaviour of code when run is different from the >>>>>>>>>>>>>> correct behaviour of the code when simulated. If that's >>>>>>>>>>>>>> true, then it has similar implications for computer >>>>>>>>>>>>>> science that disproving the conservation law has for >>>>>>>>>>>>>> physics.
When a student comes to me and says that her program to >>>>>>>>>>>>> add 5 and 6 gives 12, I don't, even for a moment,
imagine that the laws of logic and mathematics are in >>>>>>>>>>>>> doubt.
But the obvious explanation is that the dry-run was >>>>>>>>>>>>>> incorrect. Lots of people have suggested why it is >>>>>>>>>>>>>> incorrect. But they can't actually see the code. PO >>>>>>>>>>>>>> needs to understand that no-one will accept the
complicated, far-reaching explanation, until the >>>>>>>>>>>>>> simple explanation has been ruled out.
For what it's worth, I don't think there is any "dry >>>>>>>>>>>>> run" going on here at all. PO decide years ago that >>>>>>>>>>>>> H(H_Hat, H_Hat) would be 0 because he knew (correctly) >>>>>>>>>>>>> that H could spot what would happen if H did not
"intervene". Everything since then -- the "it only halt >>>>>>>>>>>>> because...", the "it wouldn't halt if line 15 were >>>>>>>>>>>>> commented out" and the rather less explicitly stated >>>>>>>>>>>>> "H_Hat does not get to its ret instruction because a >>>>>>>>>>>>> non top-level H aborts" are just the various attempt at >>>>>>>>>>>>> after-the-fact justification.
I agree it's never quite so simple because PO is usually >>>>>>>>>>>>> fractally wrong, so he's not correct about almost
everything he says at almost every level. For example, >>>>>>>>>>>>> at one level he now admits that a halt decider is
impossible because H(X,Y) must report "on its input" and >>>>>>>>>>>>> the call X(Y) is not an input! He did this to explain >>>>>>>>>>>>> why H(P,P) is permitted to return 0 "even though P(P) >>>>>>>>>>>>> halts", but it also makes it clear that what he one >>>>>>>>>>>>> thought was that halting problem is not solvable. >>>>>>>>>>>>
A halt decider must compute the mapping from its inputs >>>>>>>>>>>> to an accept or reject state on the basis of the actual >>>>>>>>>>>> behavior that is actually specified by these inputs. >>>>>>>>>>>>
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual >>>>>>>>>>>> input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the >>>>>>>>>>> pathological input at issue here are YOUR PATHOLOGICAL >>>>>>>>>>> LIES, Olcott.
/Flibble
Computable functions are the basic objects of >>>>>>>>>> study in computability theory.
Computable functions are the formalized
analogue of the intuitive notion of
algorithms, in the sense that a function is
computable if there exists an algorithm
that can do the job of the function, i.e. given >>>>>>>>>> an input of the function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function >>>>>>>>>>
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you reject that the above proves that H and P have a >>>>>>>>>> pathological relationship to each other seem to be your
lack of technical competence rather than dishonesty.
There is nothing wrong with my technical competence however >>>>>>>>> yours *is* suspect.
Nobody is denying that P is pathological input as its comes >>>>>>>>> from [Strachey, 1965]'s "Impossible Program";
// rec routine P
// �L :if T[P] go to L
// Return �
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{
L:if (T(Strachey_P))
goto L;
return;
}
int main()
{
Output("Input_Halts = ", T(Strachey_P));
}
_Strachey_P()
[000015b2](01) 55 push ebp
[000015b3](02) 8bec mov ebp,esp
[000015b5](05) 68b2150000 push 000015b2 // push
Strachey_P [000015ba](05) e813fdffff call 000012d2 //
call T [000015bf](03) 83c404 add esp,+04
[000015c2](02) 85c0 test eax,eax
[000015c4](02) 7402 jz 000015c8
[000015c6](02) ebed jmp 000015b5
[000015c8](01) 5d pop ebp
[000015c9](01) c3 ret
Size in bytes:(0024) [000015c9]
_main()
[000015d2](01) 55 push ebp
[000015d3](02) 8bec mov ebp,esp
[000015d5](05) 68b2150000 push 000015b2 // push
Strachey_P [000015da](05) e8f3fcffff call 000012d2 //
call T [000015df](03) 83c404 add esp,+04
[000015e2](01) 50 push eax
[000015e3](05) 6833040000 push 00000433
[000015e8](05) e895eeffff call 00000482
[000015ed](03) 83c408 add esp,+08
[000015f0](02) 33c0 xor eax,eax
[000015f2](01) 5d pop ebp
[000015f3](01) c3 ret
Size in bytes:(0034) [000015f3]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>> [000015d2][001025c6][00000000] 55 push ebp
[000015d3][001025c6][00000000] 8bec mov ebp,esp
[000015d5][001025c2][000015b2] 68b2150000 push 000015b2 //
push Strachey_P [000015da][001025be][000015df] e8f3fcffff
call 000012d2 // call T
Begin Simulation Execution Trace Stored at:21267a
Address_of_T:12d2
[000015b2][0021266a][0021266e] 55 push ebp
[000015b3][0021266a][0021266e] 8bec mov ebp,esp
[000015b5][00212666][000015b2] 68b2150000 push 000015b2 //
push Strachey_P [000015ba][00212662][000015bf] e813fdffff
call 000012d2 // call T Infinitely Recursive Simulation
Detected Simulation Stopped
T knows its own machine address and on this basis it can
easily examine its stored execution_trace of Strachey_P (see >>>>>>>> above) to determine: (a) Strachey_P is calling T with the
same arguments that T was called with. (b) No instructions
in Strachey_P could possibly escape this otherwise
infinitely recursive emulation.
There is no recursion in [Strachey, 1965] or the proofs based
on it that you are attempting to refute. Fail.
/Flibble
In other words you are saying that because a non-simulating
halt decider (that has no recursive emulation) cannot correctly
determine the halt status of its input that a simulating halt
decider (that has recursive emulation) cannot correctly
determine the halt status of its input.
We have already established that your simulating halt decider
gets the answer wrong if P calls H but isn't pathological.
We have not established that at all.
Yes we have:
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
H1(P,P)==1 is the non-pathological instance.
See above.
In other words if there are no black dogs in the kitchen this
proves that there are no white cats in the living room.
You are the one trying to redefine H to be something else.
/Flibble
Not something else at all.
It is merely the case that no one besides me every bothered to
fully investigate the effects of applying a simulating halt
decider to the wide open (any pure function of its inputs will
do) specification of the halting problem proofs.
A simulating halt decider is invalid as it cannot return an answer
of non-halting in finite time for all non-halting inputs as there
is no proven algorithm that can detect non-halting behaviour for
the general case.
/Flibble
We are back to your lack of sufficient software engineering skill.
You still don't understand that everything after P's function call
to H(P,P) is unreachable by P from:
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
This means that erasing the infinite loop can have no effect.
Here is the actual non-pathological input to H1(P,P):
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
H1(P,P)==1.
The only reason erasing the infinite loop has no effect is because
your H aborts the simulation which is an invalid thing to do.
/Flibble
A simulating halt decider must always abort every simulation that
would otherwise never stop running.
It does the same thing for:
(a) Infinite loops
(b) Infinite recursion
(c) Infinitely recursive emulation
On Sun, 26 Jun 2022 15:37:43 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 3:15 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 14:54:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:43 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 14:37:36 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:26 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 14:11:02 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 2:00 PM, Mr Flibble wrote:
On Sun, 26 Jun 2022 11:27:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/26/2022 6:15 AM, Mr Flibble wrote:
On Sun, 26 Jun 2022 05:31:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 9:03 PM, Mr Flibble wrote:
On Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>>>>>>>>>>>>>YOU KNOW THAT THIS IS TRUE
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben >>>>>>>>>>>>>>>> Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>>>>>>>>>>>>>>Exactly.
"Dry run" means that a human programmer looks at the >>>>>>>>>>>>>>>>>> code, and determines what it does, without actually >>>>>>>>>>>>>>>>>> executing it.
Going back, now, to what you think needs to be >>>>>>>>>>>>>>>>> resolved: | He's dry-run P(P) and established that it >>>>>>>>>>>>>>>>> doesn't halt. He's invoked H | on it and H reports >>>>>>>>>>>>>>>>> that it doesn't halt. He's run P(P) and it halts. The >>>>>>>>>>>>>>>>> obvious conclusion is that PO's dry run (if he has >>>>>>>>>>>>>>>>> indeed done such a thing) is incorrect.
We do our little energy budget on tigers, and find that >>>>>>>>>>>>>>>> tigers spend more energy than they take in. Well >>>>>>>>>>>>>>>> potentially this is dynamite. One explanation is that >>>>>>>>>>>>>>>> the law of conservation of energy is wrong. Except, >>>>>>>>>>>>>>>> before we countenance that explanation, we need to >>>>>>>>>>>>>>>> rule out a much simpler explanation. Which is that our >>>>>>>>>>>>>>>> measurements are wrong.
Obviously.
Similarly, PO has worked out what he thinks P(P) should >>>>>>>>>>>>>>>> be doing, by dry-running it, and then actually run P(P) >>>>>>>>>>>>>>>> and obtained a different result. He also found that H >>>>>>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his >>>>>>>>>>>>>>>> conclusion, but it is extensive and far-reaching in its >>>>>>>>>>>>>>>> implications.
He is just waffling. There is no conclusion, just a >>>>>>>>>>>>>>> constant twisting and turning to find some why to >>>>>>>>>>>>>>> persuade people that the wrong answer is the right one. >>>>>>>>>>>>>>> He's being doing this for years with various degrees >>>>>>>>>>>>>>> of obfuscation.
H does not report the correct result for P(P) and PO is >>>>>>>>>>>>>>> putting up anything he can think of to keep the
discussion going. It should simply have stopped once >>>>>>>>>>>>>>> he'd been clear that H(P,P) == 0 is correct "even >>>>>>>>>>>>>>> though P(P) halts" but the traces and the verbiage is >>>>>>>>>>>>>>> keeping people keen.
The behaviour of code when run is different from the >>>>>>>>>>>>>>>> correct behaviour of the code when simulated. If that's >>>>>>>>>>>>>>>> true, then it has similar implications for computer >>>>>>>>>>>>>>>> science that disproving the conservation law has for >>>>>>>>>>>>>>>> physics.
When a student comes to me and says that her program to >>>>>>>>>>>>>>> add 5 and 6 gives 12, I don't, even for a moment, >>>>>>>>>>>>>>> imagine that the laws of logic and mathematics are in >>>>>>>>>>>>>>> doubt.
But the obvious explanation is that the dry-run was >>>>>>>>>>>>>>>> incorrect. Lots of people have suggested why it is >>>>>>>>>>>>>>>> incorrect. But they can't actually see the code. PO >>>>>>>>>>>>>>>> needs to understand that no-one will accept the >>>>>>>>>>>>>>>> complicated, far-reaching explanation, until the >>>>>>>>>>>>>>>> simple explanation has been ruled out.
For what it's worth, I don't think there is any "dry >>>>>>>>>>>>>>> run" going on here at all. PO decide years ago that >>>>>>>>>>>>>>> H(H_Hat, H_Hat) would be 0 because he knew (correctly) >>>>>>>>>>>>>>> that H could spot what would happen if H did not >>>>>>>>>>>>>>> "intervene". Everything since then -- the "it only halt >>>>>>>>>>>>>>> because...", the "it wouldn't halt if line 15 were >>>>>>>>>>>>>>> commented out" and the rather less explicitly stated >>>>>>>>>>>>>>> "H_Hat does not get to its ret instruction because a >>>>>>>>>>>>>>> non top-level H aborts" are just the various attempt at >>>>>>>>>>>>>>> after-the-fact justification.
I agree it's never quite so simple because PO is usually >>>>>>>>>>>>>>> fractally wrong, so he's not correct about almost >>>>>>>>>>>>>>> everything he says at almost every level. For example, >>>>>>>>>>>>>>> at one level he now admits that a halt decider is >>>>>>>>>>>>>>> impossible because H(X,Y) must report "on its input" and >>>>>>>>>>>>>>> the call X(Y) is not an input! He did this to explain >>>>>>>>>>>>>>> why H(P,P) is permitted to return 0 "even though P(P) >>>>>>>>>>>>>>> halts", but it also makes it clear that what he one >>>>>>>>>>>>>>> thought was that halting problem is not solvable. >>>>>>>>>>>>>>
A halt decider must compute the mapping from its inputs >>>>>>>>>>>>>> to an accept or reject state on the basis of the actual >>>>>>>>>>>>>> behavior that is actually specified by these inputs. >>>>>>>>>>>>>>
BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual >>>>>>>>>>>>>> input.
YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the >>>>>>>>>>>>> pathological input at issue here are YOUR PATHOLOGICAL >>>>>>>>>>>>> LIES, Olcott.
/Flibble
Computable functions are the basic objects of >>>>>>>>>>>> study in computability theory.
Computable functions are the formalized
analogue of the intuitive notion of
algorithms, in the sense that a function is >>>>>>>>>>>> computable if there exists an algorithm
that can do the job of the function, i.e. given >>>>>>>>>>>> an input of the function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function >>>>>>>>>>>>
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you reject that the above proves that H and P have a >>>>>>>>>>>> pathological relationship to each other seem to be your >>>>>>>>>>>> lack of technical competence rather than dishonesty.
There is nothing wrong with my technical competence however >>>>>>>>>>> yours *is* suspect.
Nobody is denying that P is pathological input as its comes >>>>>>>>>>> from [Strachey, 1965]'s "Impossible Program";
// rec routine P
// §L :if T[P] go to L
// Return §
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{
L:if (T(Strachey_P))
goto L;
return;
}
int main()
{
Output("Input_Halts = ", T(Strachey_P));
}
_Strachey_P()
[000015b2](01) 55 push ebp
[000015b3](02) 8bec mov ebp,esp
[000015b5](05) 68b2150000 push 000015b2 // push
Strachey_P [000015ba](05) e813fdffff call 000012d2 // >>>>>>>>>> call T [000015bf](03) 83c404 add esp,+04
[000015c2](02) 85c0 test eax,eax
[000015c4](02) 7402 jz 000015c8
[000015c6](02) ebed jmp 000015b5
[000015c8](01) 5d pop ebp
[000015c9](01) c3 ret
Size in bytes:(0024) [000015c9]
_main()
[000015d2](01) 55 push ebp
[000015d3](02) 8bec mov ebp,esp
[000015d5](05) 68b2150000 push 000015b2 // push
Strachey_P [000015da](05) e8f3fcffff call 000012d2 // >>>>>>>>>> call T [000015df](03) 83c404 add esp,+04
[000015e2](01) 50 push eax
[000015e3](05) 6833040000 push 00000433
[000015e8](05) e895eeffff call 00000482
[000015ed](03) 83c408 add esp,+08
[000015f0](02) 33c0 xor eax,eax
[000015f2](01) 5d pop ebp
[000015f3](01) c3 ret
Size in bytes:(0034) [000015f3]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>> [000015d2][001025c6][00000000] 55 push ebp
[000015d3][001025c6][00000000] 8bec mov ebp,esp
[000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // >>>>>>>>>> push Strachey_P [000015da][001025be][000015df] e8f3fcffff
call 000012d2 // call T
Begin Simulation Execution Trace Stored at:21267a
Address_of_T:12d2
[000015b2][0021266a][0021266e] 55 push ebp
[000015b3][0021266a][0021266e] 8bec mov ebp,esp
[000015b5][00212666][000015b2] 68b2150000 push 000015b2 // >>>>>>>>>> push Strachey_P [000015ba][00212662][000015bf] e813fdffff
call 000012d2 // call T Infinitely Recursive Simulation
Detected Simulation Stopped
T knows its own machine address and on this basis it can
easily examine its stored execution_trace of Strachey_P (see >>>>>>>>>> above) to determine: (a) Strachey_P is calling T with the
same arguments that T was called with. (b) No instructions >>>>>>>>>> in Strachey_P could possibly escape this otherwise
infinitely recursive emulation.
There is no recursion in [Strachey, 1965] or the proofs based >>>>>>>>> on it that you are attempting to refute. Fail.
/Flibble
In other words you are saying that because a non-simulating
halt decider (that has no recursive emulation) cannot correctly >>>>>>>> determine the halt status of its input that a simulating halt
decider (that has recursive emulation) cannot correctly
determine the halt status of its input.
We have already established that your simulating halt decider
gets the answer wrong if P calls H but isn't pathological.
We have not established that at all.
Yes we have:
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
H1(P,P)==1 is the non-pathological instance.
See above.
In other words if there are no black dogs in the kitchen this
proves that there are no white cats in the living room.
You are the one trying to redefine H to be something else.
/Flibble
Not something else at all.
It is merely the case that no one besides me every bothered to
fully investigate the effects of applying a simulating halt
decider to the wide open (any pure function of its inputs will
do) specification of the halting problem proofs.
A simulating halt decider is invalid as it cannot return an answer
of non-halting in finite time for all non-halting inputs as there
is no proven algorithm that can detect non-halting behaviour for
the general case.
/Flibble
We are back to your lack of sufficient software engineering skill.
You still don't understand that everything after P's function call
to H(P,P) is unreachable by P from:
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
This means that erasing the infinite loop can have no effect.
Here is the actual non-pathological input to H1(P,P):
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
H1(P,P)==1.
The only reason erasing the infinite loop has no effect is because
your H aborts the simulation which is an invalid thing to do.
/Flibble
A simulating halt decider must always abort every simulation that
would otherwise never stop running.
It does the same thing for:
(a) Infinite loops
(b) Infinite recursion
(c) Infinitely recursive emulation
It is wrong to do that. Why? Because you have no way of knowing if the simulation would never stop running as there is no known algorithm for detecting non-halting behaviour for the general case.
/Flibble
Mr Flibble <flibble@reddwarf.jmc> writes:
On Sun, 26 Jun 2022 14:40:26 -0400<a typically accurate refutation>
Richard Damon <Richard@Damon-Family.org> wrote:
If I reply to you Olcott will see your post. :)
Why would you do that?!! Being ignored by PO is blessing bestowed on
very few. He's said he'll ignore me a few times but, alas, he has not
yet done so. Imagine a world in which he never replies to anything you
post!
Of course he will never ignore every critic because talking down to
people who know the subject is how he feeds his fragile sense of
self-worth, but a few of us can live in hope.
On Sunday, 26 June 2022 at 11:43:07 UTC+1, olcott wrote:
On 6/26/2022 5:14 AM, Malcolm McLean wrote:You dry run P(P) and determined that it never halted.
On Sunday, 26 June 2022 at 00:56:03 UTC+1, Ben Bacarisse wrote:So basically you are utterly clueless that I conclusively proved that
Malcolm McLean <malcolm.ar...@gmail.com> writes:If the tiger experimenters kick up a fuss about showing you their
On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:Obviously.
Malcolm McLean <malcolm.ar...@gmail.com> writes:Exactly.
"Dry run" means that a human programmer looks at the code, and determines
what it does, without actually executing it.
Going back, now, to what you think needs to be resolved:
| He's dry-run P(P) and established that it doesn't halt. He's invoked H >>>>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts. >>>>>> The obvious conclusion is that PO's dry run (if he has indeed done such >>>>>> a thing) is incorrect.
We do our little energy budget on tigers, and find that tigers spend >>>>> more energy than they take in. Well potentially this is dynamite. One >>>>> explanation is that the law of conservation of energy is wrong.
Except, before we countenance that explanation, we need to rule out a >>>>> much simpler explanation. Which is that our measurements are wrong.
notebooks, when the notebooks are available and there's no logistical
reason for the refusal, then you can dismiss the idea that they've disproved
the law of conservation of energy out of hand. The two things, together, >>> an impossible claim and a shifty, evasive attitude make up an overwhelming >>> case against.
the correct and complete x86 emulation of the input to H(P,P) by H would
never reach its "ret" instruction and the direct execution of P(P) does
reach it "ret" instruction.
You ran H on P(P) and it reported non-halting. So that's extremely surprising,
since we've good reasons for supposing that H cannot classify P(p) correctly. You ran P(P) and it halted.
Now one explanation, which you don't offer, is that something is wrong with the computer. The halting theorem is false, H is correct, and P(P) halted because of a hardware error.
It is extremely unlikely that computer would malfunction like that. And it would
be a massive coincidence for it to so malfunction just at the moment
you needed to verify it disprove an established theorem. So that can be rejected.
And, in fairness, you don't offer that explanation.
Another explanation is that there is some difference between P(P), the call, and
P,P, the input to H. Now what sort of insanity is this? However I agree that we are forced to that type of explanation is we accept that the dry run of P(P)
is correct, the actual run of P(P) doesn't match the dry run, and the computer
is not malfunctioning.
But the obvious explanation is that the dry run of P(P) was not correct, H is not correct, as predicted by the theorem, and the computer is working correctly.
In fact, if H works on the principles that you have described, then the dry run
cannot be correct. This has been pointed out many times.
So at this point, you need to show H. Otherwise no-one will accept that dry run is
correct.
Just as, if your experiments on tigers show that they use more energy than they
consume, you have to show your notebooks. People will go through them with
a toothcomb, and, even if they can't find an error, they will still say that there must
be a simple measurement error somewhere, but they can't quite identify it. But
eventually, if you are right, more data will come in.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 461 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 22:03:11 |
| Calls: | 9,358 |
| Calls today: | 3 |
| Files: | 13,542 |
| Messages: | 6,084,040 |
| Posted today: | 2 |