Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.ai.philosophy    |    Perhaps we should ask SkyNet about this    |    59,235 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 57,714 of 59,235    |
|    Fred. Zwarts to All    |
|    Re: I have just proven the error of all     |
|    30 Jul 25 11:23:19    |
      XPost: comp.theory, sci.logic       From: F.Zwarts@HetNet.nl              Op 30.jul.2025 om 05:12 schreef olcott:       > On 7/29/2025 8:51 PM, Richard Damon wrote:       >> On 7/29/25 9:24 PM, olcott wrote:       >>> On 7/29/2025 5:37 PM, Richard Damon wrote:       >>>> On 7/29/25 12:53 PM, olcott wrote:       >>>>> On 7/28/2025 8:56 PM, Richard Damon wrote:       >>>>>> On 7/28/25 7:58 PM, olcott wrote:       >>>>>>> On 7/28/2025 6:49 PM, Richard Damon wrote:       >>>>>>>> On 7/28/25 7:20 PM, olcott wrote:       >>>>>>>>> On 7/28/2025 5:57 PM, Richard Damon wrote:       >>>>>>>>>> On 7/28/25 9:54 AM, olcott wrote:       >>>>>>>>>>> On 7/28/2025 8:21 AM, joes wrote:       >>>>>>>>>>>> Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:       >>>>>>>>>>>>> On 7/28/2025 2:30 AM, joes wrote:       >>>>>>>>>>>>>> Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:       >>>>>>>>>>>>>>> On 7/27/2025 9:48 PM, Richard Damon wrote:       >>>>>>>>>>>>>>>> On 7/27/25 8:20 PM, olcott wrote:       >>>>>>>>>>>>       >>>>>>>>>>>>>>>>> When DDD is emulated by HHH1 it need not emulate itself       >>>>>>>>>>>>>>>>> at all.       >>>>>>>>>>>>>>>> But "itself" doesn't matter to x86 instructions,       >>>>>>>>>>>>>>> By itself I mean the exact same machine code bytes at the       >>>>>>>>>>>>>>> exact same       >>>>>>>>>>>>>>> machine address.       >>>>>>>>>>>>>> Yeah, so when you change HHH to abort later, you also       >>>>>>>>>>>>>> change DDD.       >>>>>>>>>>>>> HHH is never changed.       >>>>>>>>>>>       >>>>>>>>>>>> It is changed in the hypothetical unaborted simulation. HHH       >>>>>>>>>>>> is reporting       >>>>>>>>>>>> on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the       >>>>>>>>>>>> halting DDD,       >>>>>>>>>>>> and definitely not on HHH(DDD), itself.       >>>>>>>>>>>>       >>>>>>>>>>>       >>>>>>>>>>> All halt deciders are required to predict the behavior       >>>>>>>>>>> of their input. HHH does correctly predict that DDD correctly       >>>>>>>>>>> simulated by HHH cannot possibly reach its own simulated       >>>>>>>>>>> "return" instruction final halt state.       >>>>>>>>>>>       >>>>>>>>>>       >>>>>>>>>> How is it a "correct prediction" if it sees something       >>>>>>>>>> different than what that DDD does.       >>>>>>>>>>       >>>>>>>>>       >>>>>>>>> What DDD does is keep calling HHH(DDD) in recursive       >>>>>>>>> simulation until HHH kills this whole process.       >>>>>>>>       >>>>>>>> But the behavior of the program continues past that (something       >>>>>>>> you don't seem to understand) and that behavior will also have       >>>>>>>> its HHH terminate the DDD it is simulating and return 0 to DDD       >>>>>>>> and then Halt.       >>>>>>>>       >>>>>>>> Your problem is you don't understand that the simulating HHH       >>>>>>>> doesn't define the behavior of DDD, it is the execution of DDD       >>>>>>>> that defines what a correct simulation of it is.       >>>>>>>>       >>>>>>>>>       >>>>>>>>>> Remember, to have simulated that DDD, it must have include the       >>>>>>>>>> code of the HHH that it was based on, which is the HHH that       >>>>>>>>>> made the prediction, and thus returns 0, so DDD will halt.       >>>>>>>>>>       >>>>>>>>>       >>>>>>>>> We are not asking: Does DDD() halt.       >>>>>>>>> That is (as it turns out) an incorrect question.       >>>>>>>>       >>>>>>>> No, that is EXACTLY the question.       >>>>>>>>       >>>>>>>> I guess you are just admitting that you whole world is based on       >>>>>>>> LYING about what things are supposed to be.       >>>>>>>>       >>>>>>>>>       >>>>>>>>> Turing machines cannot directly report on the behavior       >>>>>>>>> of other Turing machines they can at best indirectly       >>>>>>>>> report on the behavior of Turing machines through the       >>>>>>>>> proxy of finite string machine descriptions such as ⟨M⟩.       >>>>>>>>       >>>>>>>> Right, and HHH was given the equivalenet of (M) by being given       >>>>>>>> the code of *ALL* of DDD       >>>>>>>>       >>>>>>>> I guess you don't understand that fact, even though you CLAIM       >>>>>>>> the input is the proper representation of DDD.       >>>>>>>>       >>>>>>>>>       >>>>>>>>> Thus the behavior specified by the input finite string       >>>>>>>>> overrules and supersedes the behavior of the direct       >>>>>>>>> execution.       >>>>>>>>       >>>>>>>> No, it is DEFINED to be the behavior of the direct execution of       >>>>>>>> the program it represent.       >>>>>>>>       >>>>>>>       >>>>>>> *That has always been the fatal flaw of all of the proofs*       >>>>>>       >>>>>> No, your failure to follow the rules is what makes you just a liar.       >>>>>>       >>>>>       >>>>> _DDD()       >>>>> [00002192] 55 push ebp       >>>>> [00002193] 8bec mov ebp,esp       >>>>> [00002195] 6892210000 push 00002192 // push DDD       >>>>> [0000219a] e833f4ffff call 000015d2 // call HHH       >>>>> [0000219f] 83c404 add esp,+04       >>>>> [000021a2] 5d pop ebp       >>>>> [000021a3] c3 ret       >>>>> Size in bytes:(0018) [000021a3]       >>>>>       >>>>> When the above code is in the same memory space as HHH       >>>>> such that DDD calls HHH(DDD) and then HHH does emulate       >>>>> itself emulating DDD then this does specify recursive       >>>>> emulation.       >>>>>       >>>>> Anyone or anything that disagrees would be disagreeing       >>>>> with the definition of the x86 language.       >>>>>       >>>>       >>>> So, if HHH accesses that memory, it becomes part of the input.       >>>>       >>>       >>> It becomes part of the input in the sense that the       >>> correct simulation of the input to HHH(DDD) is not       >>> the same as the correct simulation of the input to       >>> HHH1(DDD) because DDD only calls HHH(DDD) and does       >>> not call HHH1(DDD).       >>>       >>> DDD correctly simulated by HHH cannot possibly       >>> halt thus HHH(DDD)==0 is correct.       >>>       >>> DDD correctly simulated by HHH1 does halt thus       >>> HHH(DDD)==1 is correct.       >>>       >>>       >>       >> It either *IS* or it *ISN'T* there is no middle.       >>       >       > This just occurred to me:       > *HHH(DDD)==0 is also correct for another different reason*       >       > Even if we construed the HHH that DDD calls a part of the       > program under test it is true that neither the simulated       > DDD nor the simulated HHH cannot possibly reach their own       > final halt state.       Indeed. But there are different reasons:       The simulating HHH fails to reach the final halt state of the simulation       because it does a premature abort, based on the wrong assumption that a       finite recursion specifies non-halting. Then the simulating HHH does       reach its own halt state when it reports non-halting.       The simulated HHH, that has a similar final halt state after it aborts,       does not reach it own final halt state, because the simulating HHH does       not allow it to reach it by the premature abort done by the simulating HHH.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca