On 5/22/2022 4:18 PM, Richard Damon wrote:
> 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 that, 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 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 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 counter-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 that 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][0025cd6a] 8b4508     mov eax,[ebp+08]
>>>> ...[00001358][0025cd62][00001352] 50         push eax      // push P
>>>> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
>>>> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
>>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>
>>>> H sees that P is calling the same function from the same machine
>>>> address with identical parameters, twice in sequence. This is the
>>>> infinite recursion (infinitely nested simulation) non-halting
>>>> behavior pattern.
>>>
>>> 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][001022a6][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
>>>>
>>>>
>>>>
>>>>
>>>

Posted in Google Chrome on Windows.

--
Copyright 2022 Pete Olcott

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