| Bonita Montero <Bonita.Montero@gmail.com>: Sep 05 09:23PM +0200 You'll never beat C++11's stable_sort with C++17's parallel_policy()! Am 12.03.2022 um 23:06 schrieb Amine Moulay Ramdane: |
| olcott <polcott2@gmail.com>: Sep 04 10:16PM -0500 On 9/4/2022 1:07 PM, Richard Damon wrote: > answer. In fact, the proof shows that such a thing is IMPOSSIBLE. > FAIL. > Just showing how ignorant you are. void Px(ptr x) { int Halt_Status = Hx(x, x); if (Halt_Status) HERE: goto HERE; return; } int main() { Output("Input_Halts = ", Hx(Px, Px)); } I contend that that no function Hx can be defined such that its correctly simulated input Px could reach the final state of this simulated Px in any finite number of steps. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| olcott <NoOne@NoWhere.com>: Sep 05 09:51AM -0500 On 9/5/2022 5:49 AM, Otto J. Makela wrote: >> non-terminating behavior patterns. > You did not answer my question: if H() always returns a value, why would > a simulated H() also not always return a value in the simulation? I will give you the short answer, the simulated H is never invoked. > "Because I defined it so" is not a sufficient answer here. A simulating halt decider (SHD) always bases its halt status decision on correctly predicting whether or not it must abort the correct simulation of its input to prevent the infinite execution of this input. A simulating halt decider that does not abort its simulation of its input performs a correct and complete simulation of this input. The definition of a UTM says that any correct and complete simulation of an input derives the actual behavior of this simulated input. Thus if the correct and complete simulation of an input never reaches the final state of this input this means that this input specifies a non-halting sequence of instructions. The fact that the simulation of this input is aborted does not change the fact that this correctly simulated input cannot possibly reach its own final state. Once we know that the correctly simulated cannot possibly reach its own final state this input can be rejected as non-halting on the basis of the definition of non-halting: *never reaches its final state* void P(ptr x) { int Halt_Status = H(x, x); if (Halt_Status) HERE: goto HERE; return; } _P() [000010f2](01) 55 push ebp [000010f3](02) 8bec mov ebp,esp [000010f5](01) 51 push ecx [000010f6](03) 8b4508 mov eax,[ebp+08] [000010f9](01) 50 push eax // push P [000010fa](03) 8b4d08 mov ecx,[ebp+08] [000010fd](01) 51 push ecx // push P [000010fe](05) e88ffdffff call 00000e92 // call H [00001103](03) 83c408 add esp,+08 [00001106](03) 8945fc mov [ebp-04],eax [00001109](04) 837dfc00 cmp dword [ebp-04],+00 [0000110d](02) 7402 jz 00001111 [0000110f](02) ebfe jmp 0000110f [00001111](02) 8be5 mov esp,ebp [00001113](01) 5d pop ebp [00001114](01) c3 ret Size in bytes:(0035) [00001114] int main() { Output("Input_Halts = ", H(P, P)); } This is what happens if H never aborts the simulation of its input: (a) H(P,P) simulates P(P) that calls a simulated H(P,P) (b) that simulates P(P) that calls a simulated H(P,P) (c) that simulates P(P) that calls a simulated H(P,P) (d) that simulates P(P) that calls a simulated H(P,P)... When P is correctly simulated by H and H does not abort its simulation of P the first 8 instructions of P are simulated endlessly. Because a decider must always halt and a decider must always return that same value for the same input every time it is invoked H correctly recognizes the infinite behavior pattern of P before P invokes H(P,P) for the first time. At this point H aborts its simulation of P and rejects p as non-halting. *Halting problem proofs refuted on the basis of software engineering* ? https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment