Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

All your files have been destroyed (sorry). Paul.


computers / comp.theory / Re: The Halting Problem proofs have a fatal flaw [ Visual Studio c/c++ project ]

Re: The Halting Problem proofs have a fatal flaw [ Visual Studio c/c++ project ]

<th2n07$fgth$1@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=39959&group=comp.theory#39959

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory
Subject: Re: The Halting Problem proofs have a fatal flaw [ Visual Studio
c/c++ project ]
Date: Wed, 28 Sep 2022 18:56:54 -0500
Organization: A noiseless patient Spider
Lines: 349
Message-ID: <th2n07$fgth$1@dont-email.me>
References: <09b41edc-a57b-4521-ba66-8517b55f2e69n@googlegroups.com>
<tgthrr$1rdj$1@gioia.aioe.org> <C8sYK.918322$%fx6.826267@fx14.ams1>
<tgtjg9$bor$1@gioia.aioe.org> <sEsYK.1635575$ulh3.952349@fx06.ams1>
<tgtmhj$3v66k$1@dont-email.me> <f8tYK.543903$wkZ5.502025@fx11.ams1>
<tgtntf$3v66k$3@dont-email.me> <8FtYK.699498$%q2.43782@fx15.ams1>
<tgtp7j$5p8$1@gioia.aioe.org> <o6uYK.242772$YVsf.228210@fx01.ams1>
<tgtrs5$rgq$1@gioia.aioe.org> <%IAYK.567410$YC96.259830@fx12.ams1>
<tgv4ah$3a6r$2@dont-email.me> <YhLYK.294354$G_96.174924@fx13.ams1>
<th06ba$67gl$1@dont-email.me> <0fNYK.114886$6gz7.30480@fx37.iad>
<th089p$2hg$1@gioia.aioe.org> <kLNYK.200849$elEa.79945@fx09.iad>
<th09vn$flf$1@gioia.aioe.org> <CfOYK.236274$PRW4.7213@fx11.iad>
<th0bjf$13fc$1@gioia.aioe.org> <1AOYK.231099$51Rb.45426@fx45.iad>
<th0dk0$1jat$1@gioia.aioe.org> <zdWYK.511940$Ny99.268522@fx16.iad>
<th1q44$cu0t$1@dont-email.me> <Wt4ZK.133330$479c.108846@fx48.iad>
<th2lgm$fdtd$1@dont-email.me> <AU4ZK.110024$tRy7.104864@fx36.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 28 Sep 2022 23:56:56 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="c6b266099a50a65dccd1a525d17cc3b3";
logging-data="508849"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19VbYcJjlaBEaG+LR34Knf6"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.0
Cancel-Lock: sha1:VbBfGU4m5NgqkO7QckDkESmI/5c=
Content-Language: en-US
In-Reply-To: <AU4ZK.110024$tRy7.104864@fx36.iad>
 by: olcott - Wed, 28 Sep 2022 23:56 UTC

On 9/28/2022 6:37 PM, Richard Damon wrote:
> On 9/28/22 7:31 PM, olcott wrote:
>> On 9/28/2022 6:08 PM, Richard Damon wrote:
>>> On 9/28/22 11:44 AM, olcott wrote:
>>>> On 9/28/2022 6:28 AM, Richard Damon wrote:
>>>>> On 9/27/22 11:04 PM, olcott wrote:
>>>>>> On 9/27/2022 9:46 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 9/27/22 10:30 PM, olcott wrote:
>>>>>>>> On 9/27/2022 9:24 PM, Richard Damon wrote:
>>>>>>>>> On 9/27/22 10:02 PM, olcott wrote:
>>>>>>>>>> On 9/27/2022 8:50 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/27/22 9:33 PM, olcott wrote:
>>>>>>>>>>>> On 9/27/2022 8:15 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/27/22 9:00 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/27/2022 6:02 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/27/22 11:19 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/27/2022 6:00 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 9/26/22 11:49 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/26/2022 10:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 9/26/22 11:04 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/26/2022 9:58 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 9/26/22 10:41 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/26/2022 9:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/26/22 10:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/2022 8:49 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/22 9:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/2022 8:15 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/22 8:58 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/2022 7:36 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/22 8:25 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/2022 6:59 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/22 7:46 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/22 2:03 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/2022 12:19 PM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2022-09-26, Lew Pitcher
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <lew.pitcher@digitalfreehold.ca>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry, guy, but comp.lang.c is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not the place to discuss this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sort of thing. Why don't you try
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory ?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Because Olcott postings will push
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you out of visibility?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If people would give me a fair and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> honest review I could quit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> posting. You gave up on me before
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I could point out the error with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the diagonalization argument that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you relied on for your rebuttal:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The diagonalization argument
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merely proves that no value returned
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to P from its call to H can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possibly be correct. This argument
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> totally ignores that the return
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> value from H is unreachable by its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P caller when H is based
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on a simulating halt decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This makes it impossible for P to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do the opposite of whatever H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decides.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Complete halt deciding system
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Visual Studio Project)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) x86utm operating system
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) complete x86 emulator
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (c) Several halt deciders and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> their inputs contained within Halt7.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You keep making the same mistake
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> again and again. H IS NOT SUPPOSED
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TO BE RECURSIVE.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) is not recursive.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Your H is recursive because P isn't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive and yet you have to abort
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your infinite recursion: the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursion is caused by your H and not by
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P.  Nowhere in any halting problem
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proof does it state that the call to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H by P is recursive in nature BECAUSE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H IS NOT SUPPOSED TO EXECUTE P, H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> IS SUPPOSED TO *ANALYSE* P.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nowhere in any HP proof (besides mine)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is the idea of a simulating halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider (SHD) ever thought all the way
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> through.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Because the proof doesn't care at all
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> how the decider got the answer,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Because the definition of a UTM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies that the correct simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of a machine description provides the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actual behavior of the underlying
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine whenever any simulating halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider must abort its simulation to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prevent infinite simulation it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessarily correct to report that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this input does not halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Right, which means it CAN'T be a UTM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and thus *ITS* simulation does not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> define the "behavior of the input".
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The behavior of the correct simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the input is its actual behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That H correctly predicts that its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct simulation never stops running
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unless aborted conclusively proves that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this correctly simulated input would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never reach its own final state in 1 to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ∞ steps of correct simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But the behavior the halting problem is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> asking for is the behavior of the actual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Only within the context that no one ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bothered to think the application of a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating halt decider all the way through.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, the DEFINITION of a Halt Decider is to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decide on the behavior of the Actual Machine.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> That definition is made obsolete by a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating halt decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, the definition IS the definition.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't get to change it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I created a new concept that makes earlier
>>>>>>>>>>>>>>>>>>>>>>>>>> ideas about this obsolete:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Because the definition of a UTM specifies that
>>>>>>>>>>>>>>>>>>>>>>>>>> the correct simulation of a machine
>>>>>>>>>>>>>>>>>>>>>>>>>> description provides the actual behavior of
>>>>>>>>>>>>>>>>>>>>>>>>>> the underlying machine whenever any simulating
>>>>>>>>>>>>>>>>>>>>>>>>>> halt decider must abort its simulation to
>>>>>>>>>>>>>>>>>>>>>>>>>> prevent infinite simulation it is necessarily
>>>>>>>>>>>>>>>>>>>>>>>>>> correct to report that this input does not halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Because the above is verified as correct on
>>>>>>>>>>>>>>>>>>>>>>>>>> the basis of the meaning of its words it is
>>>>>>>>>>>>>>>>>>>>>>>>>> irrefutable.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Right, but H isn't a UTM, so its simulation
>>>>>>>>>>>>>>>>>>>>>>>>> doesn't matter.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Unless you can specify that material difference
>>>>>>>>>>>>>>>>>>>>>>>> between the two, that would seem to prove that
>>>>>>>>>>>>>>>>>>>>>>>> you are technically incompetent.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> H doesn't correctly repoduce the behavior of a
>>>>>>>>>>>>>>>>>>>>>>> non-halting input.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thus, it isn't a UTM.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy
>>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩      // subscripts
>>>>>>>>>>>>>>>>>>>>>> indicate unique finite strings
>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates
>>>>>>>>>>>>>>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Then these steps would keep repeating: (unless
>>>>>>>>>>>>>>>>>>>>>> their simulation is aborted)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Note, you say "unless their simulation is aborted"
>>>>>>>>>>>>>>>>>>>>> but your defiition of H DOES abort its simulation,
>>>>>>>>>>>>>>>>>>>>> thus this doesn't occur.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates
>>>>>>>>>>>>>>>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>>>>>>>>>>>>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates
>>>>>>>>>>>>>>>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>>>>>>>>>>>>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates
>>>>>>>>>>>>>>>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> This exact same behavior occurs when we replace H
>>>>>>>>>>>>>>>>>>>>>> with a UTM.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But since H ISN'T a UTM, you can't assume that it is.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H is designed to predict the result of 1 to ∞
>>>>>>>>>>>>>>>>>>>> correctly simulated steps, thus predict the behavior
>>>>>>>>>>>>>>>>>>>> of a UTM simulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Except it doesn't do that.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H does correctly predict the actual behavior of 1 to ∞
>>>>>>>>>>>>>>>>>> simulated steps of P.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope, since we have shown that if H(P,P) returns 0,
>>>>>>>>>>>>>>>>> then P(P) will Halt.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *That is false and you know it so you are a liar for the
>>>>>>>>>>>>>>>> 500th time*
>>>>>>>>>>>>>>>> *You know that you are not referring to the behavior of
>>>>>>>>>>>>>>>> an input to H*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, I am refering to the input to H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The input to H(P,P) represents the computation P(P), or
>>>>>>>>>>>>>>> your P isn't the required "impossible Program".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You cannot find a competent source that agrees that the
>>>>>>>>>>>>>> actual behavior of the input is not provided by the
>>>>>>>>>>>>>> correct simulation of this input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Correct AND COMPLETE simulation of the input.
>>>>>>>>>>>>>
>>>>>>>>>>>> So like I said you have no source, you and most other are
>>>>>>>>>>>> only going by learned-by-rote so when a new issue comes up
>>>>>>>>>>>> your flounder. The others here not going by learned-by-rote
>>>>>>>>>>>> are going by total cluelessness.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> What about the Linz definition of a Halt Decider, the one YOU
>>>>>>>>>>> quote.
>>>>>>>>>>
>>>>>>>>>> He does not say that the correct simulation of an input does
>>>>>>>>>> not provide the actual behavior of this input. You will find
>>>>>>>>>> no competent person that will disagree with me on this point.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But he DOES say that the DEFINITION of the right answer is the
>>>>>>>>> behavior of the machine that input describes, so THAT is the
>>>>>>>>> behavior that counts.
>>>>>>>>>
>>>>>>>> People that know these things more deeply than learned-by-rote
>>>>>>>> will understand that my alternative definition is sound.
>>>>>>>
>>>>>>> No, it is WRONG, since it doesn't match.
>>>>>>>
>>>>>>> That is like saying Two is the right answer to the question of
>>>>>>> How many cats you have, when you have one cats and one dog,
>>>>>>> because dogs are really pretty much like a cat.
>>>>>>>
>>>>>>> FAIL.
>>>>>>>
>>>>>>>>
>>>>>>>> We can know that it is sound by simply knowing that the correct
>>>>>>>> simulation of the input does provide the actual behavior of this
>>>>>>>> input. We know this on the basis of the definition of a UTM.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> The CORRECT AND COMPLETE.
>>>>>>>
>>>>>>> Not being complete, it CAN'T show the actual behavior.
>>>>>>>
>>>>>>> That is like getting off the highway at the second exit, well
>>>>>>> before you get into the city, and announce that traffic is clear
>>>>>>> into the city, because you didn't see any traffic.
>>>>>>>
>>>>>>> You are just PROVING our stupidity.
>>>>>>
>>>>>> Mike already corrected you on this.
>>>>>> The correct simulation of 1 to ∞ steps of the input *is*
>>>>>> computationally equivalent to the direct execution of 1 to ∞ steps
>>>>>> of the input.
>>>>>>
>>>>>> How can you disagree with this besides lying?
>>>>>>
>>>>>>
>>>>>
>>>>> So, what SINGLED EXACT INPUT have you done this for?
>>>>>
>>>>> Remember, exact of your members of Px are DIFFERENT!
>>>>>
>>>>> You only "correctly simulate" a given input once, for a single
>>>>> number between 1 and infinity, so you never have a valuation of 1
>>>>> to infinite steps for any input except those that are basd on an Hx
>>>>> that never stops them, and thos Hx never abort.
>>>>>
>>>>
>>>> You cannot find a competent source that agrees that the actual
>>>> behavior of the input is not provided by the correct simulation of
>>>> this input therefore
>>>>
>>>
>>> Except that the problem is that "Correct Simulation" is generally
>>> taken to be a Correct and Complete Simulation,
>>
>> *No it is not and Mike already corrected you on this*
>> You stubbornly insistent on lying.
>
> The ONLY definition of "simulation" for Turing Machines that I know of
> is the UTM, and it only does a complete simulation of its input.
>
> Care to provide a reliable source that defines a "Correct Simulation" as
> to include a partial one that is applicable here?

If you weren't a despicable lying bastard you would already acknowledge
that 1 to ∞ simulated steps of a machine description is necessarily
computationally equivalent to a corresponding 1 to ∞ steps of direct
execution.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

SubjectRepliesAuthor
o representing binary number naturally

By: Lew Pitcher on Mon, 26 Sep 2022

63Lew Pitcher
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor