Richard Damon <Richard@Damon-Family.org> Wrote in message:r
> On 5/22/22 2:42 PM, olcott wrote:> On 5/22/2022 1:30 PM, Richard Damon wrote:>> On 5/22/22 2:00 PM, olcott wrote:>>> That H(P,P)==0 is easily verified as correct by reverse engineering >>> what the behavior of the input to H(P,P) would be if we assume that H >>> performs a pure x86 emulation of its input. The x86 source-code of P >>> specifies everything that we need to know to do this.>>>> So, you are doing an analysis based on the assumption that an H CAN >> correct simulate its input AND answer at the same time?>>>> Until your prove that such an H can exist, you need to be very careful >> what you derive from this analysis.>>>>>>>> It is dead obvious that when H(P,P) correctly emulates its input that >>> the first 7 instructions of P are emulated.>>>>>> It is also dead obvious that when P calls H(P,P) that H emulates the >>> first 7 instructions of P again.>>>>>>> But that wouldn't actually happen!!!>>>> P calls H, so H needs to emulate the code of H since that is what is >> actually executing.>>>> THAT is a "Correct Simulation".>>> > Yes that is true, none-the-less we don't need to actually see the 237 > pages of the emulation of H to know that this H must also emulate the >
first 7 instructions of P.Right, and then the top level H aborts, so we don't get to see the rest of the correct simulaiton, which would show this embedded copy of H simulating the next embedded copy of H for its emulation of those sam e 7 instructions and then aborting its simulation and returning to the P that called it and that P halting.THAT is the correct Simulation of the input to H.H can not do that, because it has been programmed to abort its simulation at the point it did. But it shows the CORRECT SIMULATION does halt, and H used faulty logic to deicde that it would not.The question is NOT can H simulate this input to a Halting State, but can a CORRECT simulation of this input, with H defined to be what H is, reach a final state, which it does.If you want to claim foul and we can't use a different simulator to get the correct simulation, then that is just saying you aren't doing the Halting Problem, or that the Halting Problem is impossible to solve (what the Theorem says).Remember, Halting is a property of the program P, not the decider H.> >> Only an H that wasn't actually a computation, but somehow collesed >> calls to itself in its simulation would do anyting like th
at, but that >> means that H fails to be an actual computation itself, and thus not >> eligable to be a decider.>>>>> This makes it dead obvious that the correct x86 emulation of the >>> input to H(P,P) never reaches its last instruction and halts.>>>> Starting from an incorrect definition of a "Correct Trace" leads to >> garbage.>>>>>>>> Because all of my reviewers have consistently denied this easily >>> verified fact for six months it seems unreasonable to believe that >>> this is an honest mistake.>>>>>> Because what you claim isn't what actually happens. At least not in >> the space that you claim to be working in.>>>> You just repeat the claims, you never actually show that the rebutals >> are incorrect. That just proves your own ignorance.>>>>>>>> This is an explanation of a key new insight into the halting problem >>> provided in the language of software engineering. Technical computer >>> science terms are explained using software engineering terms.>>>> Then actually provide the actual definition of the term you are >> claiming make things clear.>>>>>>>> To fully understand this paper a software engineer must be an expert >>> in: the C programming language, the x86 progra
mming 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 computer science term ?halting? means that a Turing Machine >>> terminated normally reaching its last instruction known as its ?final >>> state?. This is the same idea as when a function returns to its >>> caller as opposed to and contrast with getting stuck in an infinite >>> loop or infinite recursion.>>>> Ok. since P(P) Halts, why is H(P,P) == 0 not wrong, since H(P,P) is >> supposed to be asking about the PROGRAM P, not some mythical behavior >> of the input.>>>>>>>> In computability theory, the halting problem is the problem of >>> determining,>>> from a description of an arbitrary computer program and an >>> input, whether>>> the program will finish running, or continue to run forever. >>> Alan Turing proved>>> in 1936 that a general algorithm to solve the halting problem >>> for all possible>>> program-input pairs cannot exist.>>>> Right, H(P,P) is to determine if P(P) Halts.>>>> Since P(P) Halts, the answer H(P,P) == 0 must be incorrect
.>>>>>>>> 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>>>> Yep, that is the proof that you can't make an actual decider compute >> the Halting Function.>>>>>>>> Technically a halt decider is a program that computes the mapping >>> from a pair of input finite strings to its own accept or reject state >>> based on the actual behavior specified by these finite strings. In >>> other words it determines whether or not its input would halt and >>> returns 0 or 1 accordingly.>>>> Right, an Arbitrary decide just needs to always halt on all input to >> create a mapping of input to outputs.>>>> To be a "Something" Decider, that mapping must match the "Something" >> function as defined.>>>>>>>> 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>>>>>> The most definitive way to determine the actual behavior of the >>> actual input is to simply simulate this input and watch its behavior. >>> This is the ultimate measure of the actual behavior of the input. A >>> simulating halt decider (SHD) simulates its input and determines the >>> halt status of this input on the basis of the behavior of this >>> correctly simulated of its input.>>>> Ok, but if the correct simulation of the input takes longer that the >> SHD allows, it doesn't get the data it needs to make the decision.>>>> It has been shown that if you SHD runs until it can actually PROVE >> that it has the right answer, it will NEVER halt on the input P,P >> where P is built on this "contrary" pattern.>>>> You haven't even TRIED to prove that you can will reach an answer in >> finite time.>>>>>>>> The x86utm operating system was created so that all of the details of >>> the the halting problem c
ounter-example could be examined at the much >>> higher level of abstraction of the C/x86 computer languages. It is >>> based on a very powerful x86 emulator.>>>> Ok.>>>>>> The function named P was defined to do the opposite of whatever H >>> reports that it will do. If H(P,P) reports that its input halts, P >>> invokes an infinite loop. If H(P,P) reports that its input is >>> non-halting, P immediately halts.>>>> Right, which shows that H was wrong.>>>> The only way that H(P,P) == 0 is correct, is if P(P) runs forever and >> never halts.>>>> The fact that it halt, PROVES that H was wrong.>>>>>>>> The technical computer science term "halt" means that a program will >>> reach its last instruction technically called its final state. For P >>> this would be its machine address [0000136c].>>>> Which it does, for an ACTUALLY RUN P.>>>> There is NO requriement that H be able to simulate to that point.>>>>>>>> H simulates its input one x86 instruction at a time using an x86 >>> emulator. As soon as H(P,P) detects the same infinitely repeating >>> pattern (that we can all see), it aborts its simulation and rejects >>> its input.>>>> And there is NO finite pattern that exists that proves t
hat fact.>>>> ANY pattern you claim is such a pattern, when programmed into H, makes >> the actual execution of P(P) Halt, and thus is incorret.>>>>>>>> Anyone that is an expert in the C programming language, the x86 >>> programming language, exactly how C translates into x86 and what an >>> x86 processor emulator is can easily verify that the correctly >>> simulated input to H(P,P) by H specifies a non-halting sequence of >>> configurations.>>>> Nope. It is easy to verify that if H(P,P) is defined to return 0 after >> a finite time, that P(P) will Halt.>>>>>>>>>> Software engineering experts can reverse-engineer what the correct >>> x86 emulation of the input to H(P,P) would be for one emulation and >>> one nested emulation thus confirming that the provided execution >>> trace is correct. They can do this entirely on the basis of the x86 >>> source-code for P with no need to see the source-code or execution >>> trace of H.>>>> Ok, so we have the trace of the first emulation, and a trace of the >> second, both of them show that P(P) calls H(P,P) and is waiting for an >> answer.>>>>>>>> The function named H continues to simulate its input using an x86 >>> emulator until this input
either halts on its own or H detects that >>> it would never halt. If its input halts H returns 1. If H detects >>> that its input would never halt H returns 0.>>>> So you have the contradiction. If H returns 0, it shows that ALL the >> P(P)'s will Halt.>>>> If H doesn't return 0, it shows that it doesn't answer for that input, >> and thus fails.>>>> It is invalid logic to use a different H for doing the actual decision >> an to build P from, they need to be EXACT copies and actual >> computations, thus ALL copies do the same thing.>>>>>>>> #include <stdint.h>>>> #define u32 uint32_t>>>>>> void P(u32 x)>>> {>>> if (H(x, x))>>> HERE: goto HERE;>>> return;>>> }>>>>>> int main()>>> {>>> Output("Input_Halts = ", H((u32)P, (u32)P));>>> }>>>>>> _P()>>> [00001352](01) 55 push ebp>>> [00001353](02) 8bec mov ebp,esp>>> [00001355](03) 8b4508 mov eax,[ebp+08]>>> [00001358](01) 50 push eax // push P>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]>>> [0000135c](01) 51 push ecx // push P>>> [0000135d](05) e840feffff call 000011a2 // call H>>> [00001362](03) 83c408 add esp,+08>>> [00001365
](02) 85c0 test eax,eax>>> [00001367](02) 7402 jz 0000136b>>> [00001369](02) ebfe jmp 00001369>>> [0000136b](01) 5d pop ebp>>> [0000136c](01) c3 ret>>> Size in bytes:(0027) [0000136c]>>>>>> _main()>>> [00001372](01) 55 push ebp>>> [00001373](02) 8bec mov ebp,esp>>> [00001375](05) 6852130000 push 00001352 // push P>>> [0000137a](05) 6852130000 push 00001352 // push P>>> [0000137f](05) e81efeffff call 000011a2 // call H>>> [00001384](03) 83c408 add esp,+08>>> [00001387](01) 50 push eax>>> [00001388](05) 6823040000 push 00000423 // "Input_Halts = ">>> [0000138d](05) e8e0f0ffff call 00000472 // call Output>>> [00001392](03) 83c408 add esp,+08>>> [00001395](02) 33c0 xor eax,eax>>> [00001397](01) 5d pop ebp>>> [00001398](01) c3 ret>>> Size in bytes:(0039) [00001398]>>>>>> machine stack stack machine assembly>>> address address data code language>>> ======== ======== ======== ========= =============>>> ...[00001372][0010229e][00000000] 55 push
ebp>>> ...[00001373][0010229e][00000000] 8bec mov ebp,esp>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P>>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp>>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]>>> ...[00001358][0021233a][00001352] 50 push eax // push P>>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]>>> ...[0000135c][00212336][00001352] 51 push ecx // push P>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H>>>> And this is the error.>>>> The top level simulation NEVER sees this below, and thus this is a >> FALSE trace.>>>> You just are proving you don't understand what a trace is supposed to >> show.>>>>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P>>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp>>> ...[00001355][0025cd66][002
5cd6a] 8b4508 mov eax,[ebp+08]>>> ...[00001358][0025cd62][00001352] 50 push eax // push P>>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]>>> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped>>>>>> H sees that P is calling the same function from the same machine >>> address with identical parameters, twice in sequence. This is the >>> infinite recursion (infinitely nested simulation) non-halting >>> behavior pattern.>>>> If it does, it is using unsound logic, as it is based on false premises.>>>>>>>> ...[00001384][0010229e][00000000] 83c408 add esp,+08>>> ...[00001387][0010229a][00000000] 50 push eax>>> ...[00001388][00102296][00000423] 6823040000 push 00000423 // >>> "Input_Halts = ">>> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call >>> Output>>> Input_Halts = 0>>> ...[00001392][0010229e][00000000] 83c408 add esp,+08>>> ...[00001395][0010229e][00000000] 33c0 xor eax,eax>>> ...[00001397][001022a2][00100000] 5d pop ebp>>> ...[00001398][001022
a6][00000004] c3 ret>>> Number_of_User_Instructions(1)>>> Number of Instructions Executed(15892) = 237 pages>>>>>> The correct simulation of the input to H(P,P) and the direct >>> execution of P(P) are not computationally equivalent thus need not >>> have the same halting behavior.>>>> The H is NOT a Halting Decider.>>>> The DEFINITION of a Halting Decider IS that it is answering about the >> behavior of the machine the input represents.>>>> Thus, if H is a Halt Decider, the "behavior of the input", for H(P,P) >> must be exactly P(P).>>>> FAIL.>>>>>>>>>> Halting problem undecidability and infinitely nested simulation (V5)>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5 >>>>>>>>>>>>>>> >

Test of android USENET Client
--
test

----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html