Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Old programmers never die, they just become managers.


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 ]

<zdWYK.511940$Ny99.268522@fx16.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx16.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.13.1
Subject: Re: The Halting Problem proofs have a fatal flaw [ Visual Studio
c/c++ project ]
Content-Language: en-US
Newsgroups: comp.theory
References: <09b41edc-a57b-4521-ba66-8517b55f2e69n@googlegroups.com>
<tgtdjp$k83$1@gioia.aioe.org> <w1rYK.918307$%fx6.414214@fx14.ams1>
<tgtftj$3rs8a$1@dont-email.me> <0ArYK.1232167$Eeb3.1026224@fx05.ams1>
<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>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <th0dk0$1jat$1@gioia.aioe.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 325
Message-ID: <zdWYK.511940$Ny99.268522@fx16.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 28 Sep 2022 07:28:30 -0400
X-Received-Bytes: 17343
 by: Richard Damon - Wed, 28 Sep 2022 11:28 UTC

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.

I think you also do understand what he said, as the only cases that
matter is where the simulation runs for more steps than it takes to
reach the final state (or infinite if it never does). The only cases
where you do this are for the Hx that never abort their simulations, so
only for the Px built on those.

Since H isn't a member of that set, neither is Px, so you haven't shown
anything about it.

You have just proved that you don't understand anything about the
problem or how to do logic. You have shown that your self-imposed
ignorance has made you a pathological lying idiot, and killed and buried
any reputation you had under your pile of falsehoods.

You have wasted the last 18 years of your life.

FAIL.

SubjectRepliesAuthor
o representing binary number naturally

By: Lew Pitcher on Mon, 26 Sep 2022

63Lew Pitcher
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor