Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Why use Windows, since there is a door? (By fachat@galileo.rhein-neckar.de, Andre Fachat)


devel / comp.theory / Re: Simulating halt decider applied to a simpler input

SubjectAuthor
* Simulating halt decider applied to a simpler inputolcott
`* Simulating halt decider applied to a simpler inputRichard Damon
 `* Simulating halt decider applied to a simpler inputMr Flibble
  `* Simulating halt decider applied to a simpler inputRichard Damon
   +* Simulating halt decider applied to a simpler inputolcott
   |`* Simulating halt decider applied to a simpler inputRichard Damon
   | `* Simulating halt decider applied to a simpler inputolcott
   |  `* Simulating halt decider applied to a simpler inputRichard Damon
   |   `* Simulating halt decider applied to a simpler inputolcott
   |    `* Simulating halt decider applied to a simpler inputRichard Damon
   |     +* Simulating halt decider applied to a simpler inputMr Flibble
   |     |+- Simulating halt decider applied to a simpler inputolcott
   |     |`* Simulating halt decider applied to a simpler inputRichard Damon
   |     | `* Simulating halt decider applied to a simpler inputMr Flibble
   |     |  +- Simulating halt decider applied to a simpler inputolcott
   |     |  `* Simulating halt decider applied to a simpler inputRichard Damon
   |     |   +* Simulating halt decider applied to a simpler inputolcott
   |     |   |`* Simulating halt decider applied to a simpler inputRichard Damon
   |     |   | `* Simulating halt decider applied to a simpler inputolcott
   |     |   |  `* Simulating halt decider applied to a simpler inputRichard Damon
   |     |   |   `* Simulating halt decider applied to a simpler inputolcott
   |     |   |    `* Simulating halt decider applied to a simpler inputRichard Damon
   |     |   |     +* Simulating halt decider applied to a simpler inputolcott
   |     |   |     |`* Simulating halt decider applied to a simpler inputRichard Damon
   |     |   |     | `* Simulating halt decider applied to a simpler inputolcott
   |     |   |     |  `* Simulating halt decider applied to a simpler inputRichard Damon
   |     |   |     |   +* Simulating halt decider applied to a simpler inputMr Flibble
   |     |   |     |   |`- Simulating halt decider applied to a simpler inputRichard Damon
   |     |   |     |   `* Simulating halt decider applied to a simpler inputolcott
   |     |   |     |    `- Simulating halt decider applied to a simpler inputRichard Damon
   |     |   |     `* Simulating halt decider applied to a simpler inputolcott
   |     |   |      `* Simulating halt decider applied to a simpler inputRichard Damon
   |     |   |       `* Simulating halt decider applied to a simpler inputolcott
   |     |   |        `- Simulating halt decider applied to a simpler inputRichard Damon
   |     |   `* Simulating halt decider applied to a simpler inputMr Flibble
   |     |    `* Simulating halt decider applied to a simpler inputRichard Damon
   |     |     +* Simulating halt decider applied to a simpler inputMr Flibble
   |     |     |`* Simulating halt decider applied to a simpler inputRichard Damon
   |     |     | `* Simulating halt decider applied to a simpler inputMr Flibble
   |     |     |  +* Simulating halt decider applied to a simpler inputRichard Damon
   |     |     |  |+* Simulating halt decider applied to a simpler inputMr Flibble
   |     |     |  ||`- Simulating halt decider applied to a simpler inputRichard Damon
   |     |     |  |`* Simulating halt decider applied to a simpler inputolcott
   |     |     |  | `- Simulating halt decider applied to a simpler inputRichard Damon
   |     |     |  +* Simulating halt decider applied to a simpler inputolcott
   |     |     |  |`* Simulating halt decider applied to a simpler inputRichard Damon
   |     |     |  | `* Simulating halt decider applied to a simpler inputolcott
   |     |     |  |  `* Simulating halt decider applied to a simpler inputRichard Damon
   |     |     |  |   +* Simulating halt decider applied to a simpler inputolcott
   |     |     |  |   |`* Simulating halt decider applied to a simpler inputRichard Damon
   |     |     |  |   | +* Simulating halt decider applied to a simpler inputMr Flibble
   |     |     |  |   | |`* Simulating halt decider applied to a simpler inputRichard Damon
   |     |     |  |   | | `* Simulating halt decider applied to a simpler inputMr Flibble
   |     |     |  |   | |  +- Simulating halt decider applied to a simpler inputolcott
   |     |     |  |   | |  `- Simulating halt decider applied to a simpler inputRichard Damon
   |     |     |  |   | `* Simulating halt decider applied to a simpler inputolcott
   |     |     |  |   |  `* Simulating halt decider applied to a simpler inputRichard Damon
   |     |     |  |   |   `* Simulating halt decider applied to a simpler inputolcott
   |     |     |  |   |    `* Simulating halt decider applied to a simpler inputRichard Damon
   |     |     |  |   |     +* Simulating halt decider applied to a simpler inputolcott
   |     |     |  |   |     |`* Simulating halt decider applied to a simpler inputRichard Damon
   |     |     |  |   |     | `* Simulating halt decider applied to a simpler inputolcott
   |     |     |  |   |     |  `* Simulating halt decider applied to a simpler inputRichard Damon
   |     |     |  |   |     |   `* Simulating halt decider applied to a simpler inputolcott
   |     |     |  |   |     |    `* Simulating halt decider applied to a simpler inputRichard Damon
   |     |     |  |   |     |     `- Simulating halt decider applied to a simpler inputolcott
   |     |     |  |   |     `* Olcottaholics anonymousBen Bacarisse
   |     |     |  |   |      `* E correctly simulated by H would never reach its last instruction andolcott
   |     |     |  |   |       `* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |        `* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |         `* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |          `* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |           +* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |`* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |           | `* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |  +* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |           |  |`* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |  | +* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |           |  | |`* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |  | | `* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |           |  | |  `* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |  | |   `* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |           |  | |    `* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |  | |     `* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |           |  | |      `* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |  | |       `* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |           |  | |        `* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |  | |         `* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |           |  | |          +* E correctly simulated by H would never reach its last instruction and terminate Mr Flibble
   |     |     |  |   |           |  | |          |+* E correctly simulated by H would never reach its last instructionDennis Bush
   |     |     |  |   |           |  | |          ||`* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |           |  | |          || `* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |  | |          ||  +* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |           |  | |          ||  |+* E correctly simulated by H would never reach its last instruction and terminate Mr Flibble
   |     |     |  |   |           |  | |          ||  ||`* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |           |  | |          ||  || `- E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |  | |          ||  |`* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |  | |          ||  | `* E correctly simulated by H would never reach its last instruction and terminate Mr Flibble
   |     |     |  |   |           |  | |          ||  |  +* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |           |  | |          ||  |  |`- E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |  | |          ||  |  `* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |  | |          ||  `* E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   |           |  | |          |`* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |  | |          `* E correctly simulated by H would never reach its last instructionRichard Damon
   |     |     |  |   |           |  | `- E correctly simulated by H would never reach its last instruction and terminate Mr Flibble
   |     |     |  |   |           |  `- E correctly simulated by H would never reach its last instruction and terminate Mr Flibble
   |     |     |  |   |           `- E correctly simulated by H would never reach its last instructionolcott
   |     |     |  |   `* Simulating halt decider applied to a simpler inputMr Flibble
   |     |     |  `- Simulating halt decider applied to a simpler inputolcott
   |     |     `- Simulating halt decider applied to a simpler inputMr Flibble
   |     `* Simulating halt decider applied to a simpler inputolcott
   `* Simulating halt decider applied to a simpler inputJeff Barnett

Pages:1234567
Re: Simulating halt decider applied to a simpler input

<1EPbL.70684$Jjx8.59867@fx15.iad>

  copy mid

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

  copy link   Newsgroups: sci.logic comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx15.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.2
Subject: Re: Simulating halt decider applied to a simpler input
Content-Language: en-US
Newsgroups: sci.logic,comp.theory
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm9ed$u30u$8@dont-email.me> <tkmvum$18v4$1@gioia.aioe.org>
<tkn0i4$1efu$1@gioia.aioe.org> <tknbbt$140dq$1@dont-email.me>
<MTNbL.90219$2Rs3.48881@fx12.iad> <20221112143106.0000780b@reddwarf.jmc.corp>
<tkoavt$16bfq$1@dont-email.me> <LwObL.82893$8ga9.66084@fx18.iad>
<tkoe0q$16k3v$1@dont-email.me> <2dPbL.83577$8ga9.3830@fx18.iad>
<tkog28$16k3v$4@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tkog28$16k3v$4@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 197
Message-ID: <1EPbL.70684$Jjx8.59867@fx15.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: Sat, 12 Nov 2022 11:14:49 -0500
X-Received-Bytes: 10060
 by: Richard Damon - Sat, 12 Nov 2022 16:14 UTC

On 11/12/22 11:02 AM, olcott wrote:
> On 11/12/2022 9:46 AM, Richard Damon wrote:
>> On 11/12/22 10:27 AM, olcott wrote:
>>> On 11/12/2022 8:58 AM, Richard Damon wrote:
>>>> On 11/12/22 9:35 AM, olcott wrote:
>>>>> On 11/12/2022 8:31 AM, Mr Flibble wrote:
>>>>>> On Sat, 12 Nov 2022 09:15:04 -0500
>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>
>>>>>>> On 11/12/22 12:35 AM, olcott wrote:
>>>>>>>> On 11/11/2022 8:31 PM, Sergi o wrote:
>>>>>>>>> On 11/11/2022 8:21 PM, olcott wrote:
>>>>>>>>>> On 11/11/2022 1:56 PM, Jeff Barnett wrote:
>>>>>>>>>>> On 11/11/2022 11:43 AM, Richard Damon wrote:
>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>> It is my understanding that Olcott has blocked you and I would
>>>>>>>>>>>>> have thought given your intelligence you would also understand
>>>>>>>>>>>>> that.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>> I don't think he has actually blocked me, just mostly ignores
>>>>>>>>>>>> me.
>>>>>>>>>>>>
>>>>>>>>>>>> I say this because at times he seems to respond to what I say,
>>>>>>>>>>>> even if not in a direct reply,
>>>>>>>>>>>>
>>>>>>>>>>>> Also, when someone like you replies, even if he has blocked me,
>>>>>>>>>>>> he will still see me.
>>>>>>>>>>>>
>>>>>>>>>>>> More importantly, If anyone naive wanders into the archives, I
>>>>>>>>>>>> want enough evidence to be around to point out his errors.
>>>>>>>>>>>
>>>>>>>>>>> How is that working? Do you really think that repeating yourself
>>>>>>>>>>> literally 1000's of times makes good reading? Almost anyone who
>>>>>>>>>>> can look deeply enough into the logic will notice you engaging
>>>>>>>>>>> in a supposed dialogue with a stone wall (actually a stone
>>>>>>>>>>> brain). After your first half dozen messages a few years ago,
>>>>>>>>>>> you have added nothing to the conversation. Time to move on.
>>>>>>>>>>>> Note also, my longer replies shows what I know and provide
>>>>>>>>>>>> reasoning behind the claims, showing the Truth.
>>>>>>>>>>>
>>>>>>>>>>> It's a trivial truth and few will be fooled. Further, the real
>>>>>>>>>>> truth tellers and teachers do not hang out in these groups or
>>>>>>>>>>> archives. Too many truth tellers too few acolytes shrewd enough
>>>>>>>>>>> to know who has the inside track on god's word. Did you know
>>>>>>>>>>> that PO, in his less lucid moments, thinks he's a truth teller
>>>>>>>>>>> too? Truth tellers only pass the word when they preach to the
>>>>>>>>>>> choir.
>>>>>>>>>>>> His short claims, and guff replies just show that he doesn't
>>>>>>>>>>>> actually know what he is talking about, and reveals his
>>>>>>>>>>>> ignorance. If he tries to put his explanation into explicit
>>>>>>>>>>>> words, his errors become very apparent, I think even to him, so
>>>>>>>>>>>> he just refuses.
>>>>>>>>>>>
>>>>>>>>>>> So what? Rather than save the world from a babbling idiot, why
>>>>>>>>>>> not rescue homeless puppies at risk? You would be doing a better
>>>>>>>>>>> thing and would be more admired. A mathematical social worker is
>>>>>>>>>>> not needed.
>>>>>>>>>>>
>>>>>>>>>>> I think, instead, you don't know what to do with your time and
>>>>>>>>>>> have select this task to fill the gaps. Anyone studying the
>>>>>>>>>>> archives will notice that PO is the clear victor in all these
>>>>>>>>>>> threads. His head is too thick to be bothered by facts or
>>>>>>>>>>> sort-of facts; he's too ignorant and proud to be bothered by
>>>>>>>>>>> anyone else's facts or religion; and some of your presentations
>>>>>>>>>>> (articles) are not worded in the best way or are slightly
>>>>>>>>>>> misleading to someone who doesn't already know most of what you
>>>>>>>>>>> meant to say. (That's a problem with most of us writing articles
>>>>>>>>>>> without a few hours reflection before posting.) You will not win
>>>>>>>>>>> this way.
>>>>>>>>>>>
>>>>>>>>>>> Since I think you seek recognition for your efforts as a white
>>>>>>>>>>> knight and it's not working, I suggest you go black hat! Beat PO
>>>>>>>>>>> at his own game: Initiate threads five to twenty times a week;
>>>>>>>>>>> Have response chains where you respond significant numbers of
>>>>>>>>>>> times to your own articles; Be outrageous!
>>>>>>>>>>>
>>>>>>>>>>> This will only work if you devote enough time to take all of the
>>>>>>>>>>> PO USENET distinctions away from him. You must, every month, win
>>>>>>>>>>> the honors for (1) most threads started, (2) most number of
>>>>>>>>>>> responses to threads you have started, (3) most posts by an
>>>>>>>>>>> individual, (4) threads with largest number of indentations, (5)
>>>>>>>>>>> the highest number of almost repetitious posts - slight
>>>>>>>>>>> variations required, (6) highest percentage of silly
>>>>>>>>>>> capitalization, and (7) most times breaking USENET rules on text
>>>>>>>>>>> postings.
>>>>>>>>>>>
>>>>>>>>>>> When you follow the above seven point program (and you are well
>>>>>>>>>>> on your way in many of the points) you will eclipse PO and he
>>>>>>>>>>> will go POOF into a heap of dust. You will have won! At last.
>>>>>>>>>>> and history and the titles will be yours. You will be known to
>>>>>>>>>>> future USENET generations, for as long as the archives are
>>>>>>>>>>> maintained, as a winner.
>>>>>>>>>>>
>>>>>>>>>>> However, and this is an important however, you will have
>>>>>>>>>>> approximately the same impact on the truth as you do now. Why
>>>>>>>>>>> not have fun instead?
>>>>>>>>>>
>>>>>>>>>> I made the basis of my proof much easier to understand so that
>>>>>>>>>> anyone that is an expert in the C programming language would be
>>>>>>>>>> able to understand a simulating halt decider.
>>>>>>>>>>
>>>>>>>>>> void E(void (*x)())
>>>>>>>>>> {
>>>>>>>>>>     H(x, x);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> When H(D,D) returns 0 it correctly predicts that D correctly
>>>>>>>>>> simulated by H would never reach its own final state and
>>>>>>>>>> terminate normally after 1 to ∞ of correct simulation.
>>>>>>>>>>
>>>>>>>>>> I predict that no one will be able to find any actual error with
>>>>>>>>>> that.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> if it doesn't bust the compiler, run it through a code checker,
>>>>>>>>> lots of free ones out there
>>>>>>>>>
>>>>>>>>> https://www.onlinegdb.com/online_c_compiler
>>>>>>>>
>>>>>>>>
>>>>>>>> The last remaining issue is the acceptance of the notion of a
>>>>>>>> simulating halt decider.
>>>>>>>
>>>>>>> Why, It is actually a well know concept, as a PARTIAL solution of
>>>>>>> the
>>>>>>> problem.
>>>>>>>
>>>>>>> I remember it being shown as why you CAN'T just solve the problem
>>>>>>> with one.
>>>>>>>
>>>>>>> Your ignorance of the history of this topic has doomed you to repeat
>>>>>>> all the errors that others have made in the past.
>>>>>>
>>>>>> A simulating halt decider is Olcott's idea.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> Thanks. I was thinking about filing a trademark on it.
>>>>>
>>>>
>>>> Go ahead and waste your money.
>>>>
>>>> I remember the discussion of trying to determine halting by
>>>> simulation back in my school days, so not a new concept. Normally
>>>> showing the simple reasons about why it doesn't work.
>>>>
>>>
>>> What you are remembering is that a halt decider cannot correctly
>>> determine the halt status of an input by only simulating this input
>>> because some inputs never terminate.
>>>
>>> A simulating halt decider simulates its input in debug step mode and
>>> examines the execution trace of this input for non-halting behavior
>>> patterns.
>>
>> And it has been well known that non-halting does not have a finite set
>> of cases that always detect it.
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> void E(void (*x)())
> {
>   H(x, x);
> }
>
> It is an easily verified fact that Infinite_Loop and E are correctly
> recognized as specifying non-halting behavior to H.
>
>


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<tkoh4r$16k3v$6@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic
Subject: Re: Simulating halt decider applied to a simpler input
Date: Sat, 12 Nov 2022 10:20:42 -0600
Organization: A noiseless patient Spider
Lines: 77
Message-ID: <tkoh4r$16k3v$6@dont-email.me>
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<tkmqdh$vlno$1@dont-email.me> <RkDbL.64705$s2l3.8581@fx10.iad>
<tkn0p8$1f0o$1@gioia.aioe.org> <2NDbL.106883$U709.73582@fx16.iad>
<tkn1i8$1m9b$1@gioia.aioe.org> <yXDbL.106886$U709.39749@fx16.iad>
<tkn5on$v3b$1@gioia.aioe.org> <%HNbL.90216$2Rs3.25035@fx12.iad>
<tkobf8$16bfq$2@dont-email.me> <gEObL.82921$8ga9.23987@fx18.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 12 Nov 2022 16:20:43 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="d8c82b31b36f6d47fb6bf54a1e329d6a";
logging-data="1265791"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+P057d16zyLkc11fD5Npmf"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.4.2
Cancel-Lock: sha1:OarloPnrao9U7A+oPj71UziN6Ek=
In-Reply-To: <gEObL.82921$8ga9.23987@fx18.iad>
Content-Language: en-US
 by: olcott - Sat, 12 Nov 2022 16:20 UTC

On 11/12/2022 9:06 AM, Richard Damon wrote:
> On 11/12/22 9:43 AM, olcott wrote:
>> On 11/12/2022 8:02 AM, Richard Damon wrote:
>>> On 11/11/22 11:00 PM, olcott wrote:
>>>> On 11/11/2022 8:56 PM, Richard Damon wrote:
>>>>> On 11/11/22 9:48 PM, olcott wrote:
>>>>>> On 11/11/2022 8:45 PM, Richard Damon wrote:
>>>>>>> On 11/11/22 9:35 PM, olcott wrote:
>>>>>
>>>>>> Yes and when embedded_H can predict this in a finite number of
>>>>>> steps then it is a halt decider for ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>
>>>>>
>>>>> Except that it can't do that since it is shown that H^ <H^> Will
>>>>> halt in this case, so it is impossible to correctly predict that a
>>>>> correct simulation of the input <H^> <H^> will not halt.
>>>> A simulating halt decider must correctly predict (in a finite number
>>>> of steps whether or not its simulated input would ever stop running
>>>> if it never aborted its simulation of its input.
>>>>
>>>>
>>>
>>> Right, it must, but it can't. Again, your Egish is lacking because
>>> you are too stupid.
>>>
>>> If you claim it can, what pattern did it use to detect this, that
>>> ALWAYS shows the program is non-halting?
>>>
>>> I will note that E(E) calling H(E,E) is NOT such a pattern, as E(E)
>>> will halt if H(E,E) is defined to abort that simulation and return 0.
>> void Infinite_Loop()
>> {
>>    HERE: goto HERE;
>> }
>>
>> It is an easily verified fact that Infinite_Loop correctly simulated
>> by H would never reach its own last instruction and terminate normally
>> after 1 to ∞ steps of correct simulation.
>>
>> void E(void (*x)())
>> {
>>    H(x, x);
>> }
>>
>> It is an easily verified fact that E correctly simulated by H would
>> never reach its own last instruction and terminate normally after 1 to
>> ∞ steps of correct simulation.
>>
>>
>
> Then verify it. Hard to do since E(E) does halt since H(E,E) returns 0.
>
E correctly simulated by H
E correctly simulated by H
E correctly simulated by H
E correctly simulated by H
E correctly simulated by H

would never reach its own last instruction and terminate normally after
1 to ∞ steps of correct simulation.

Since you know this is true I don't see why you continue to lie about it.

When H(E,E) returns 0 it is correctly rejecting its input on the basis
that E correctly simulated by H would never reach its own last
instruction and terminate normally after 1 to ∞ steps of correct simulation.

The definition of a UTM specifies that the correct simulation of a
machine description provides the actual behavior specified by this
machine description thus H is correct to base its halt status decision
on E correctly simulated by H.

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

Re: Simulating halt decider applied to a simpler input

<AKPbL.71109$Jjx8.70154@fx15.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx15.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.2
Subject: Re: Simulating halt decider applied to a simpler input
Content-Language: en-US
Newsgroups: comp.theory
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <KWObL.90235$2Rs3.32051@fx12.iad>
<tkogb4$16k3v$5@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tkogb4$16k3v$5@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 221
Message-ID: <AKPbL.71109$Jjx8.70154@fx15.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: Sat, 12 Nov 2022 11:21:49 -0500
X-Received-Bytes: 11529
 by: Richard Damon - Sat, 12 Nov 2022 16:21 UTC

On 11/12/22 11:06 AM, olcott wrote:
> On 11/12/2022 9:26 AM, Richard Damon wrote:
>> On 11/12/22 10:03 AM, Mr Flibble wrote:
>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>> {
>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any H that does abort its simulation to prevent the infinite
>>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>
>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so any
>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>
>>>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>>>> halt decision of non-halting; it needs to instead be mapped to
>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>
>>>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>> directly express a reference.
>>>>>>>>>
>>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>>>> different way.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>>> actually a decider.
>>>>>>>>
>>>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>
>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>> calls the decider.
>>>>>>>>
>>>>>>>> After that, it is the deciders job to make the decision in finite
>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>
>>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>>> the requirements.
>>>>>>>>
>>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>>> copy of something that just happens to be its own description.
>>>>>>>>
>>>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>>> effect of the Self-Reference just lets us see that the task turns
>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>
>>>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>>>> not due to self reference or infinite copies but because the input
>>>>>>> tries to do the opposite of what the decider decides; the category
>>>>>>> error that I have identified is different: it is an error of self
>>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>>> fact that the input references a decider rather than being related
>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>
>>>>>>> /Flibble
>>>>>>
>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>>> ANY input and answer in finite time, If an input causes it to make
>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>> requirements.
>>>>>>
>>>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>>> if H is actualy a Turing Machine.
>>>>>>
>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>> admitting that your H can't actually be a Turing Machine, but must
>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>> requirement to be the needed decider.
>>>>>
>>>>> In which case we get infinite turning machines all the way down: yet
>>>>> another manifestation of the category error I have identified.
>>>>>
>>>>> /Flibble
>>>>
>>>> Where are infinite machines? There is ONE machine being run, either H
>>>> or D, and it SIMULATING others, and if we get an infinite sequence of
>>>> simulations we have just shown that H was defective because it failed
>>>> to answer in finite time.
>>>>
>>>> This isn't a category error, but a design error in H.
>>>>
>>>> Note, when we start H, there is exactly two machines present in
>>>> representation on the tape, and two is much smaller than infinity.
>>>
>>> Nope, if,
>>>
>>> a) H is a copy, and
>>> b) H is a Turing Machine, and
>>> c) D is an input into H, and
>>> d) D references H, and
>>> e) H references D,
>>>
>>> then (d) and (e) repeat ad infinitum so we get infinite Turing Machines
>>> all the way down: a manifestation of the category error I have
>>> identified.
>>>
>>> /Flibble
>>>
>>
>> H doesn't reference D, in fact it CAN'T because D doesn't exist when H
>> is created. You can't actually reference something that doesn't exist.
> void D(void (*x)())
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> So if I smash a Boston cream pie in your face you will say blub, blub
> blub (speaking through pie dripping from your face) there is no pie.
>


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<6PPbL.71121$Jjx8.38057@fx15.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx15.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.2
Subject: Re: Simulating halt decider applied to a simpler input
Content-Language: en-US
Newsgroups: comp.theory
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tkofba$16k3v$2@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 222
Message-ID: <6PPbL.71121$Jjx8.38057@fx15.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: Sat, 12 Nov 2022 11:26:38 -0500
X-Received-Bytes: 11245
 by: Richard Damon - Sat, 12 Nov 2022 16:26 UTC

On 11/12/22 10:50 AM, olcott wrote:
> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>> On Sat, 12 Nov 2022 09:52:12 -0500
>> Richard Damon <Richard@Damon-Family.org> wrote:
>>
>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>
>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>> {
>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Any H that does abort its simulation to prevent the infinite
>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>
>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so any
>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>
>>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>>> halt decision of non-halting; it needs to instead be mapped to
>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> Nope, no self reference.
>>>>>>>>>
>>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>> directly express a reference.
>>>>>>>>
>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>>> different way.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>> actually a decider.
>>>>>>>
>>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>> description of itself, which is also simple to make.
>>>>>>>
>>>>>>> When run it makes a second copy of its description, and then
>>>>>>> calls the decider.
>>>>>>>
>>>>>>> After that, it is the deciders job to make the decision in finite
>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>
>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>> the requirements.
>>>>>>>
>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>> copy of something that just happens to be its own description.
>>>>>>>
>>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>> effect of the Self-Reference just lets us see that the task turns
>>>>>>> out be be impossible, so no such program exists.
>>>>>>
>>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>>> not due to self reference or infinite copies but because the input
>>>>>> tries to do the opposite of what the decider decides; the category
>>>>>> error that I have identified is different: it is an error of self
>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>> fact that the input references a decider rather than being related
>>>>>> to what the input does with the decision result of a decider.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> But the infinite copies is a error in the Decider, not in
>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>> ANY input and answer in finite time, If an input causes it to make
>>>>> infinite copies, then the decided just doesn't meet its
>>>>> requirements.
>>>>>
>>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>> if H is actualy a Turing Machine.
>>>>>
>>>>> All your declaration of a "Category Error" here is doing is
>>>>> admitting that your H can't actually be a Turing Machine, but must
>>>>> be of a HIGHER order logic system, which means H fails the
>>>>> requirement to be the needed decider.
>>>>
>>>> In which case we get infinite turning machines all the way down: yet
>>>> another manifestation of the category error I have identified.
>>>>
>>>> /Flibble
>>>
>>> Where are infinite machines? There is ONE machine being run, either H
>>> or D, and it SIMULATING others, and if we get an infinite sequence of
>>> simulations we have just shown that H was defective because it failed
>>> to answer in finite time.
>>>
>>> This isn't a category error, but a design error in H.
>>>
>>> Note, when we start H, there is exactly two machines present in
>>> representation on the tape, and two is much smaller than infinity.
>>
>> Nope, if,
>>
>> a) H is a copy, and
>> b) H is a Turing Machine, and
>> c) D is an input into H, and
>> d) D references H, and
>> e) H references D,
>>
>> then (d) and (e) repeat ad infinitum so we get infinite Turing Machines
>> all the way down: a manifestation of the category error I have
>> identified.
>>
>> /Flibble
>>
>
> void E(void (*x)())
> {
>   H(x, x);
> }
>
> The point is
> that D correctly simulated by H would never reach its own last
> instruction and terminate normally after 1 to ∞ steps of correct
> simulation.
>
> When H returns 0 to main() it is indicating
>
> that D correctly simulated by H would never reach its own last
> instruction and terminate normally after 1 to ∞ steps of correct
> simulation.
>


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<20221112164256.0000371e@reddwarf.jmc.corp>

  copy mid

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

  copy link   Newsgroups: sci.logic comp.theory
Date: Sat, 12 Nov 2022 16:42:56 +0000
From: flib...@reddwarf.jmc.corp (Mr Flibble)
Newsgroups: sci.logic,comp.theory
Subject: Re: Simulating halt decider applied to a simpler input
Message-ID: <20221112164256.0000371e@reddwarf.jmc.corp>
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad> <20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad> <tkm9ed$u30u$8@dont-email.me> <tkmvum$18v4$1@gioia.aioe.org> <tkn0i4$1efu$1@gioia.aioe.org> <tknbbt$140dq$1@dont-email.me> <MTNbL.90219$2Rs3.48881@fx12.iad> <20221112143106.0000780b@reddwarf.jmc.corp> <tkoavt$16bfq$1@dont-email.me> <LwObL.82893$8ga9.66084@fx18.iad> <20221112151611.00000462@reddwarf.jmc.corp> <e9PbL.83198$8ga9.33939@fx18.iad> <20221112155240.00005446@reddwarf.jmc.corp> <rzPbL.70276$Jjx8.10873@fx15.iad>
Organization: NewsDemon - www.newsdemon.com
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Lines: 209
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder.usenetexpress.com!tr1.eu1.usenetexpress.com!news.newsdemon.com!not-for-mail
NNTP-Posting-Date: Sat, 12 Nov 2022 16:42:56 +0000
X-Received-Bytes: 11010
X-Complaints-To: abuse@newsdemon.com
 by: Mr Flibble - Sat, 12 Nov 2022 16:42 UTC

On Sat, 12 Nov 2022 11:09:56 -0500
Richard Damon <Richard@Damon-Family.org> wrote:

> On 11/12/22 10:52 AM, Mr Flibble wrote:
> > On Sat, 12 Nov 2022 10:41:58 -0500
> > Richard Damon <Richard@Damon-Family.org> wrote:
> >
> >> On 11/12/22 10:16 AM, Mr Flibble wrote:
> >>> On Sat, 12 Nov 2022 09:58:47 -0500
> >>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>
> >>>> On 11/12/22 9:35 AM, olcott wrote:
> >>>>> On 11/12/2022 8:31 AM, Mr Flibble wrote:
> >>>>>> On Sat, 12 Nov 2022 09:15:04 -0500
> >>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>
> >>>>>>> On 11/12/22 12:35 AM, olcott wrote:
> >>>>>>>> On 11/11/2022 8:31 PM, Sergi o wrote:
> >>>>>>>>> On 11/11/2022 8:21 PM, olcott wrote:
> >>>>>>>>>> On 11/11/2022 1:56 PM, Jeff Barnett wrote:
> >>>>>>>>>>> On 11/11/2022 11:43 AM, Richard Damon wrote:
> >>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> It is my understanding that Olcott has blocked you and I
> >>>>>>>>>>>>> would have thought given your intelligence you would
> >>>>>>>>>>>>> also understand that.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>
> >>>>>>>>>>>> I don't think he has actually blocked me, just mostly
> >>>>>>>>>>>> ignores me.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I say this because at times he seems to respond to what I
> >>>>>>>>>>>> say, even if not in a direct reply,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Also, when someone like you replies, even if he has
> >>>>>>>>>>>> blocked me, he will still see me.
> >>>>>>>>>>>>
> >>>>>>>>>>>> More importantly, If anyone naive wanders into the
> >>>>>>>>>>>> archives, I want enough evidence to be around to point
> >>>>>>>>>>>> out his errors.
> >>>>>>>>>>>
> >>>>>>>>>>> How is that working? Do you really think that repeating
> >>>>>>>>>>> yourself literally 1000's of times makes good reading?
> >>>>>>>>>>> Almost anyone who can look deeply enough into the logic
> >>>>>>>>>>> will notice you engaging in a supposed dialogue with a
> >>>>>>>>>>> stone wall (actually a stone brain). After your first half
> >>>>>>>>>>> dozen messages a few years ago, you have added nothing to
> >>>>>>>>>>> the conversation. Time to move on.
> >>>>>>>>>>>> Note also, my longer replies shows what I know and
> >>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
> >>>>>>>>>>>
> >>>>>>>>>>> It's a trivial truth and few will be fooled. Further, the
> >>>>>>>>>>> real truth tellers and teachers do not hang out in these
> >>>>>>>>>>> groups or archives. Too many truth tellers too few
> >>>>>>>>>>> acolytes shrewd enough to know who has the inside track
> >>>>>>>>>>> on god's word. Did you know that PO, in his less lucid
> >>>>>>>>>>> moments, thinks he's a truth teller too? Truth tellers
> >>>>>>>>>>> only pass the word when they preach to the choir.
> >>>>>>>>>>>> His short claims, and guff replies just show that he
> >>>>>>>>>>>> doesn't actually know what he is talking about, and
> >>>>>>>>>>>> reveals his ignorance. If he tries to put his explanation
> >>>>>>>>>>>> into explicit words, his errors become very apparent, I
> >>>>>>>>>>>> think even to him, so he just refuses.
> >>>>>>>>>>>
> >>>>>>>>>>> So what? Rather than save the world from a babbling idiot,
> >>>>>>>>>>> why not rescue homeless puppies at risk? You would be
> >>>>>>>>>>> doing a better thing and would be more admired. A
> >>>>>>>>>>> mathematical social worker is not needed.
> >>>>>>>>>>>
> >>>>>>>>>>> I think, instead, you don't know what to do with your time
> >>>>>>>>>>> and have select this task to fill the gaps. Anyone
> >>>>>>>>>>> studying the archives will notice that PO is the clear
> >>>>>>>>>>> victor in all these threads. His head is too thick to be
> >>>>>>>>>>> bothered by facts or sort-of facts; he's too ignorant and
> >>>>>>>>>>> proud to be bothered by anyone else's facts or religion;
> >>>>>>>>>>> and some of your presentations (articles) are not worded
> >>>>>>>>>>> in the best way or are slightly misleading to someone who
> >>>>>>>>>>> doesn't already know most of what you meant to say.
> >>>>>>>>>>> (That's a problem with most of us writing articles
> >>>>>>>>>>> without a few hours reflection before posting.) You will
> >>>>>>>>>>> not win this way.
> >>>>>>>>>>>
> >>>>>>>>>>> Since I think you seek recognition for your efforts as a
> >>>>>>>>>>> white knight and it's not working, I suggest you go black
> >>>>>>>>>>> hat! Beat PO at his own game: Initiate threads five to
> >>>>>>>>>>> twenty times a week; Have response chains where you
> >>>>>>>>>>> respond significant numbers of times to your own
> >>>>>>>>>>> articles; Be outrageous!
> >>>>>>>>>>>
> >>>>>>>>>>> This will only work if you devote enough time to take all
> >>>>>>>>>>> of the PO USENET distinctions away from him. You must,
> >>>>>>>>>>> every month, win the honors for (1) most threads started,
> >>>>>>>>>>> (2) most number of responses to threads you have started,
> >>>>>>>>>>> (3) most posts by an individual, (4) threads with largest
> >>>>>>>>>>> number of indentations, (5) the highest number of almost
> >>>>>>>>>>> repetitious posts - slight variations required, (6)
> >>>>>>>>>>> highest percentage of silly capitalization, and (7) most
> >>>>>>>>>>> times breaking USENET rules on text postings.
> >>>>>>>>>>>
> >>>>>>>>>>> When you follow the above seven point program (and you are
> >>>>>>>>>>> well on your way in many of the points) you will eclipse
> >>>>>>>>>>> PO and he will go POOF into a heap of dust. You will have
> >>>>>>>>>>> won! At last. and history and the titles will be yours.
> >>>>>>>>>>> You will be known to future USENET generations, for as
> >>>>>>>>>>> long as the archives are maintained, as a winner.
> >>>>>>>>>>>
> >>>>>>>>>>> However, and this is an important however, you will have
> >>>>>>>>>>> approximately the same impact on the truth as you do now.
> >>>>>>>>>>> Why not have fun instead?
> >>>>>>>>>>
> >>>>>>>>>> I made the basis of my proof much easier to understand so
> >>>>>>>>>> that anyone that is an expert in the C programming language
> >>>>>>>>>> would be able to understand a simulating halt decider.
> >>>>>>>>>>
> >>>>>>>>>> void E(void (*x)())
> >>>>>>>>>> {
> >>>>>>>>>>     H(x, x);
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> When H(D,D) returns 0 it correctly predicts that D
> >>>>>>>>>> correctly simulated by H would never reach its own final
> >>>>>>>>>> state and terminate normally after 1 to ∞ of correct
> >>>>>>>>>> simulation.
> >>>>>>>>>>
> >>>>>>>>>> I predict that no one will be able to find any actual error
> >>>>>>>>>> with that.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> if it doesn't bust the compiler, run it through a code
> >>>>>>>>> checker, lots of free ones out there
> >>>>>>>>>
> >>>>>>>>> https://www.onlinegdb.com/online_c_compiler
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> The last remaining issue is the acceptance of the notion of a
> >>>>>>>> simulating halt decider.
> >>>>>>>
> >>>>>>> Why, It is actually a well know concept, as a PARTIAL solution
> >>>>>>> of the problem.
> >>>>>>>
> >>>>>>> I remember it being shown as why you CAN'T just solve the
> >>>>>>> problem with one.
> >>>>>>>
> >>>>>>> Your ignorance of the history of this topic has doomed you to
> >>>>>>> repeat all the errors that others have made in the past.
> >>>>>>
> >>>>>> A simulating halt decider is Olcott's idea.
> >>>>>>
> >>>>>> /Flibble
> >>>>>>
> >>>>>
> >>>>> Thanks. I was thinking about filing a trademark on it.
> >>>>>
> >>>>
> >>>> Go ahead and waste your money.
> >>>>
> >>>> I remember the discussion of trying to determine halting by
> >>>> simulation back in my school days, so not a new concept. Normally
> >>>> showing the simple reasons about why it doesn't work.
> >>>>
> >>>> Note, this is pre-internet, so your Google searches not bringing
> >>>> it up is understandable.
> >>>>
> >>>> Likely didn't reach "published papers" as it was a well known
> >>>> dead end so no need to write the paper.
> >>>
> >>> So you have no evidence to backup that claim. So no prior art
> >>> leaving Olcott free to trademark or file a patent.
> >>>
> >>> /Flibble
> >>>
> >>
> >> He can't file a patent, as he has publicly disclosed the idea too
> >> long ago. Public disclosure precludes later patent. If he filed a
> >> preliminary patent BEFORE disclosure, he is given a limited amount
> >> of time to finalize it, but I think too much time has passed now
> >> for that to be an option.
> >>
> >> There is also the problem tha that you need to demonstrate that it
> >> works.
> >
> > You are obviously unaware of the USPTO which allows patent trolls to
> > file vague nebulous patents all the time that are certainly not
> > "demonstrated to work". Patent trolls don't make money by creating
> > patented product, they make money through litigation if they think
> > their vague patents can be asserted in a congenial legal district.
> >
> > /Flibble
> >
>
> And you are not aware that such patents can be declared invalid, and
> the trolls required to pay the legal fees of the chalenger if said
> patent is determined to have been fraudulently field.
>
> Yes, some trolls do get away with invalid patents because it isn't
> worth the effort.
>
> Note also, "work" doesn't need to be commercially viable, so can be a
> low standard in some fields.
>
> A patent must include a sample implementation of the invention it
> claims, and claims about what that implementation can do. "Lying"
> about that ability invalidates the patent.


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<Y6QbL.85722$8ga9.81272@fx18.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx18.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.2
Subject: Re: Simulating halt decider applied to a simpler input
Content-Language: en-US
Newsgroups: comp.theory,sci.logic
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<tkmqdh$vlno$1@dont-email.me> <RkDbL.64705$s2l3.8581@fx10.iad>
<tkn0p8$1f0o$1@gioia.aioe.org> <2NDbL.106883$U709.73582@fx16.iad>
<tkn1i8$1m9b$1@gioia.aioe.org> <yXDbL.106886$U709.39749@fx16.iad>
<tkn5on$v3b$1@gioia.aioe.org> <%HNbL.90216$2Rs3.25035@fx12.iad>
<tkobf8$16bfq$2@dont-email.me> <gEObL.82921$8ga9.23987@fx18.iad>
<tkoh4r$16k3v$6@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tkoh4r$16k3v$6@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 104
Message-ID: <Y6QbL.85722$8ga9.81272@fx18.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: Sat, 12 Nov 2022 11:47:49 -0500
X-Received-Bytes: 5610
 by: Richard Damon - Sat, 12 Nov 2022 16:47 UTC

On 11/12/22 11:20 AM, olcott wrote:
> On 11/12/2022 9:06 AM, Richard Damon wrote:
>> On 11/12/22 9:43 AM, olcott wrote:
>>> On 11/12/2022 8:02 AM, Richard Damon wrote:
>>>> On 11/11/22 11:00 PM, olcott wrote:
>>>>> On 11/11/2022 8:56 PM, Richard Damon wrote:
>>>>>> On 11/11/22 9:48 PM, olcott wrote:
>>>>>>> On 11/11/2022 8:45 PM, Richard Damon wrote:
>>>>>>>> On 11/11/22 9:35 PM, olcott wrote:
>>>>>>
>>>>>>> Yes and when embedded_H can predict this in a finite number of
>>>>>>> steps then it is a halt decider for ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>
>>>>>>
>>>>>> Except that it can't do that since it is shown that H^ <H^> Will
>>>>>> halt in this case, so it is impossible to correctly predict that a
>>>>>> correct simulation of the input <H^> <H^> will not halt.
>>>>> A simulating halt decider must correctly predict (in a finite
>>>>> number of steps whether or not its simulated input would ever stop
>>>>> running if it never aborted its simulation of its input.
>>>>>
>>>>>
>>>>
>>>> Right, it must, but it can't. Again, your Egish is lacking because
>>>> you are too stupid.
>>>>
>>>> If you claim it can, what pattern did it use to detect this, that
>>>> ALWAYS shows the program is non-halting?
>>>>
>>>> I will note that E(E) calling H(E,E) is NOT such a pattern, as E(E)
>>>> will halt if H(E,E) is defined to abort that simulation and return 0.
>>> void Infinite_Loop()
>>> {
>>>    HERE: goto HERE;
>>> }
>>>
>>> It is an easily verified fact that Infinite_Loop correctly simulated
>>> by H would never reach its own last instruction and terminate
>>> normally after 1 to ∞ steps of correct simulation.
>>>
>>> void E(void (*x)())
>>> {
>>>    H(x, x);
>>> }
>>>
>>> It is an easily verified fact that E correctly simulated by H would
>>> never reach its own last instruction and terminate normally after 1
>>> to ∞ steps of correct simulation.
>>>
>>>
>>
>> Then verify it. Hard to do since E(E) does halt since H(E,E) returns 0.
>>
> E correctly simulated by H
> E correctly simulated by H
> E correctly simulated by H
> E correctly simulated by H
> E correctly simulated by H

Which is a STRAWMAN, or is H not a Halt Decider,

A Halt Decider needs to decide on the direct exectution of the input, or
the input simulated by a UTM, which, by definition, never aborts its
simulation, so H isn't a UTM.

FAIL.

>
> would never reach its own last instruction and terminate normally after
> 1 to ∞ steps of correct simulation.
>
> Since you know this is true I don't see why you continue to lie about it.

No, you THINK that Strawman statement is a usable basis, but it isn't.

You are just proving your stupidity by repeating it.

>
> When H(E,E) returns 0 it is correctly rejecting its input on the basis
> that E correctly simulated by H would never reach its own last
> instruction and terminate normally after 1 to ∞ steps of correct
> simulation.
>
> The definition of a UTM specifies that the correct simulation of a
> machine description provides the actual behavior specified by this
> machine description thus H is correct to base its halt status decision
> on E correctly simulated by H.
>
>

Except H isn't a UTM. H can base its answer on what a UTM would do when
simulating the input, but since H isn't a UTM, it can't use itself.

UTM(E,E) will see E call H(E,E), then H simulating E(E) until it sees it
call H(E,E) again, and then abort its simulation and return 0 to E and
then E halt.

Ths the correct answer is HALTING.

You are just showing you just fundamentally don't understand even the
basics of the field you are talking about, showing your stupidity. This
incompetence is of such a high magnatude, it seems that you are likely a
pathological liar to not be able to see the errors in your logic,
totally unable to tell the difference between truth and error.

Re: Simulating halt decider applied to a simpler input

<tkojg4$172nl$2@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!news.niel.me!aioe.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic
Subject: Re: Simulating halt decider applied to a simpler input
Date: Sat, 12 Nov 2022 11:00:52 -0600
Organization: A noiseless patient Spider
Lines: 285
Message-ID: <tkojg4$172nl$2@dont-email.me>
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
<6PPbL.71121$Jjx8.38057@fx15.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 12 Nov 2022 17:00:53 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="d8c82b31b36f6d47fb6bf54a1e329d6a";
logging-data="1280757"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/AALf0NdB5fm2ffcaCBEoH"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.4.2
Cancel-Lock: sha1:X8Nrzmp5JsRUENMlUvmGbt4DpxI=
In-Reply-To: <6PPbL.71121$Jjx8.38057@fx15.iad>
Content-Language: en-US
 by: olcott - Sat, 12 Nov 2022 17:00 UTC

On 11/12/2022 10:26 AM, Richard Damon wrote:
> On 11/12/22 10:50 AM, olcott wrote:
>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>> {
>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any H that does abort its simulation to prevent the infinite
>>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>
>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so any
>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>
>>>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>>>> halt decision of non-halting; it needs to instead be mapped to
>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>
>>>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>> directly express a reference.
>>>>>>>>>
>>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>>>> different way.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>>> actually a decider.
>>>>>>>>
>>>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>
>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>> calls the decider.
>>>>>>>>
>>>>>>>> After that, it is the deciders job to make the decision in finite
>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>
>>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>>> the requirements.
>>>>>>>>
>>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>>> copy of something that just happens to be its own description.
>>>>>>>>
>>>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>>> effect of the Self-Reference just lets us see that the task turns
>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>
>>>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>>>> not due to self reference or infinite copies but because the input
>>>>>>> tries to do the opposite of what the decider decides; the category
>>>>>>> error that I have identified is different: it is an error of self
>>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>>> fact that the input references a decider rather than being related
>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>
>>>>>>> /Flibble
>>>>>>
>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>>> ANY input and answer in finite time, If an input causes it to make
>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>> requirements.
>>>>>>
>>>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>>> if H is actualy a Turing Machine.
>>>>>>
>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>> admitting that your H can't actually be a Turing Machine, but must
>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>> requirement to be the needed decider.
>>>>>
>>>>> In which case we get infinite turning machines all the way down: yet
>>>>> another manifestation of the category error I have identified.
>>>>>
>>>>> /Flibble
>>>>
>>>> Where are infinite machines? There is ONE machine being run, either H
>>>> or D, and it SIMULATING others, and if we get an infinite sequence of
>>>> simulations we have just shown that H was defective because it failed
>>>> to answer in finite time.
>>>>
>>>> This isn't a category error, but a design error in H.
>>>>
>>>> Note, when we start H, there is exactly two machines present in
>>>> representation on the tape, and two is much smaller than infinity.
>>>
>>> Nope, if,
>>>
>>> a) H is a copy, and
>>> b) H is a Turing Machine, and
>>> c) D is an input into H, and
>>> d) D references H, and
>>> e) H references D,
>>>
>>> then (d) and (e) repeat ad infinitum so we get infinite Turing Machines
>>> all the way down: a manifestation of the category error I have
>>> identified.
>>>
>>> /Flibble
>>>
>>
>> void E(void (*x)())
>> {
>>    H(x, x);
>> }
>>
>> The point is
>> that D correctly simulated by H would never reach its own last
>> instruction and terminate normally after 1 to ∞ steps of correct
>> simulation.
>>
>> When H returns 0 to main() it is indicating
>>
>> that D correctly simulated by H would never reach its own last
>> instruction and terminate normally after 1 to ∞ steps of correct
>> simulation.
>>
>
> Except D is NOT correctly simulated by H, so that is a incorrect
> statement. When it is correctly simulated by something other than H, it
> will come to a final state, showing your statement is wrong.
In order for the simulation to actually be incorrect the execution trace
of the simulated E must diverge from the behavior that the line-by-line
x86 source-code of E specifies.


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<tkojm4$172nl$3@dont-email.me>

  copy mid

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

  copy link   Newsgroups: sci.logic comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: sci.logic,comp.theory
Subject: Re: Simulating halt decider applied to a simpler input
Date: Sat, 12 Nov 2022 11:04:03 -0600
Organization: A noiseless patient Spider
Lines: 219
Message-ID: <tkojm4$172nl$3@dont-email.me>
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm9ed$u30u$8@dont-email.me> <tkmvum$18v4$1@gioia.aioe.org>
<tkn0i4$1efu$1@gioia.aioe.org> <tknbbt$140dq$1@dont-email.me>
<MTNbL.90219$2Rs3.48881@fx12.iad> <20221112143106.0000780b@reddwarf.jmc.corp>
<tkoavt$16bfq$1@dont-email.me> <LwObL.82893$8ga9.66084@fx18.iad>
<20221112151611.00000462@reddwarf.jmc.corp> <e9PbL.83198$8ga9.33939@fx18.iad>
<20221112155240.00005446@reddwarf.jmc.corp> <rzPbL.70276$Jjx8.10873@fx15.iad>
<20221112164256.0000371e@reddwarf.jmc.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 12 Nov 2022 17:04:04 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="d8c82b31b36f6d47fb6bf54a1e329d6a";
logging-data="1280757"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/5NvaJGQN3jzCDH2clRivW"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.4.2
Cancel-Lock: sha1:UmTSCv3MonUr3qZbytVLkzObl68=
In-Reply-To: <20221112164256.0000371e@reddwarf.jmc.corp>
Content-Language: en-US
 by: olcott - Sat, 12 Nov 2022 17:04 UTC

On 11/12/2022 10:42 AM, Mr Flibble wrote:
> On Sat, 12 Nov 2022 11:09:56 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 11/12/22 10:52 AM, Mr Flibble wrote:
>>> On Sat, 12 Nov 2022 10:41:58 -0500
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 11/12/22 10:16 AM, Mr Flibble wrote:
>>>>> On Sat, 12 Nov 2022 09:58:47 -0500
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>
>>>>>> On 11/12/22 9:35 AM, olcott wrote:
>>>>>>> On 11/12/2022 8:31 AM, Mr Flibble wrote:
>>>>>>>> On Sat, 12 Nov 2022 09:15:04 -0500
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>
>>>>>>>>> On 11/12/22 12:35 AM, olcott wrote:
>>>>>>>>>> On 11/11/2022 8:31 PM, Sergi o wrote:
>>>>>>>>>>> On 11/11/2022 8:21 PM, olcott wrote:
>>>>>>>>>>>> On 11/11/2022 1:56 PM, Jeff Barnett wrote:
>>>>>>>>>>>>> On 11/11/2022 11:43 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you and I
>>>>>>>>>>>>>>> would have thought given your intelligence you would
>>>>>>>>>>>>>>> also understand that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I say this because at times he seems to respond to what I
>>>>>>>>>>>>>> say, even if not in a direct reply,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>
>>>>>>>>>>>>> How is that working? Do you really think that repeating
>>>>>>>>>>>>> yourself literally 1000's of times makes good reading?
>>>>>>>>>>>>> Almost anyone who can look deeply enough into the logic
>>>>>>>>>>>>> will notice you engaging in a supposed dialogue with a
>>>>>>>>>>>>> stone wall (actually a stone brain). After your first half
>>>>>>>>>>>>> dozen messages a few years ago, you have added nothing to
>>>>>>>>>>>>> the conversation. Time to move on.
>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It's a trivial truth and few will be fooled. Further, the
>>>>>>>>>>>>> real truth tellers and teachers do not hang out in these
>>>>>>>>>>>>> groups or archives. Too many truth tellers too few
>>>>>>>>>>>>> acolytes shrewd enough to know who has the inside track
>>>>>>>>>>>>> on god's word. Did you know that PO, in his less lucid
>>>>>>>>>>>>> moments, thinks he's a truth teller too? Truth tellers
>>>>>>>>>>>>> only pass the word when they preach to the choir.
>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his explanation
>>>>>>>>>>>>>> into explicit words, his errors become very apparent, I
>>>>>>>>>>>>>> think even to him, so he just refuses.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So what? Rather than save the world from a babbling idiot,
>>>>>>>>>>>>> why not rescue homeless puppies at risk? You would be
>>>>>>>>>>>>> doing a better thing and would be more admired. A
>>>>>>>>>>>>> mathematical social worker is not needed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think, instead, you don't know what to do with your time
>>>>>>>>>>>>> and have select this task to fill the gaps. Anyone
>>>>>>>>>>>>> studying the archives will notice that PO is the clear
>>>>>>>>>>>>> victor in all these threads. His head is too thick to be
>>>>>>>>>>>>> bothered by facts or sort-of facts; he's too ignorant and
>>>>>>>>>>>>> proud to be bothered by anyone else's facts or religion;
>>>>>>>>>>>>> and some of your presentations (articles) are not worded
>>>>>>>>>>>>> in the best way or are slightly misleading to someone who
>>>>>>>>>>>>> doesn't already know most of what you meant to say.
>>>>>>>>>>>>> (That's a problem with most of us writing articles
>>>>>>>>>>>>> without a few hours reflection before posting.) You will
>>>>>>>>>>>>> not win this way.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since I think you seek recognition for your efforts as a
>>>>>>>>>>>>> white knight and it's not working, I suggest you go black
>>>>>>>>>>>>> hat! Beat PO at his own game: Initiate threads five to
>>>>>>>>>>>>> twenty times a week; Have response chains where you
>>>>>>>>>>>>> respond significant numbers of times to your own
>>>>>>>>>>>>> articles; Be outrageous!
>>>>>>>>>>>>>
>>>>>>>>>>>>> This will only work if you devote enough time to take all
>>>>>>>>>>>>> of the PO USENET distinctions away from him. You must,
>>>>>>>>>>>>> every month, win the honors for (1) most threads started,
>>>>>>>>>>>>> (2) most number of responses to threads you have started,
>>>>>>>>>>>>> (3) most posts by an individual, (4) threads with largest
>>>>>>>>>>>>> number of indentations, (5) the highest number of almost
>>>>>>>>>>>>> repetitious posts - slight variations required, (6)
>>>>>>>>>>>>> highest percentage of silly capitalization, and (7) most
>>>>>>>>>>>>> times breaking USENET rules on text postings.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When you follow the above seven point program (and you are
>>>>>>>>>>>>> well on your way in many of the points) you will eclipse
>>>>>>>>>>>>> PO and he will go POOF into a heap of dust. You will have
>>>>>>>>>>>>> won! At last. and history and the titles will be yours.
>>>>>>>>>>>>> You will be known to future USENET generations, for as
>>>>>>>>>>>>> long as the archives are maintained, as a winner.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, and this is an important however, you will have
>>>>>>>>>>>>> approximately the same impact on the truth as you do now.
>>>>>>>>>>>>> Why not have fun instead?
>>>>>>>>>>>>
>>>>>>>>>>>> I made the basis of my proof much easier to understand so
>>>>>>>>>>>> that anyone that is an expert in the C programming language
>>>>>>>>>>>> would be able to understand a simulating halt decider.
>>>>>>>>>>>>
>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>> {
>>>>>>>>>>>>     H(x, x);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> When H(D,D) returns 0 it correctly predicts that D
>>>>>>>>>>>> correctly simulated by H would never reach its own final
>>>>>>>>>>>> state and terminate normally after 1 to ∞ of correct
>>>>>>>>>>>> simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> I predict that no one will be able to find any actual error
>>>>>>>>>>>> with that.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> if it doesn't bust the compiler, run it through a code
>>>>>>>>>>> checker, lots of free ones out there
>>>>>>>>>>>
>>>>>>>>>>> https://www.onlinegdb.com/online_c_compiler
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The last remaining issue is the acceptance of the notion of a
>>>>>>>>>> simulating halt decider.
>>>>>>>>>
>>>>>>>>> Why, It is actually a well know concept, as a PARTIAL solution
>>>>>>>>> of the problem.
>>>>>>>>>
>>>>>>>>> I remember it being shown as why you CAN'T just solve the
>>>>>>>>> problem with one.
>>>>>>>>>
>>>>>>>>> Your ignorance of the history of this topic has doomed you to
>>>>>>>>> repeat all the errors that others have made in the past.
>>>>>>>>
>>>>>>>> A simulating halt decider is Olcott's idea.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> Thanks. I was thinking about filing a trademark on it.
>>>>>>>
>>>>>>
>>>>>> Go ahead and waste your money.
>>>>>>
>>>>>> I remember the discussion of trying to determine halting by
>>>>>> simulation back in my school days, so not a new concept. Normally
>>>>>> showing the simple reasons about why it doesn't work.
>>>>>>
>>>>>> Note, this is pre-internet, so your Google searches not bringing
>>>>>> it up is understandable.
>>>>>>
>>>>>> Likely didn't reach "published papers" as it was a well known
>>>>>> dead end so no need to write the paper.
>>>>>
>>>>> So you have no evidence to backup that claim. So no prior art
>>>>> leaving Olcott free to trademark or file a patent.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> He can't file a patent, as he has publicly disclosed the idea too
>>>> long ago. Public disclosure precludes later patent. If he filed a
>>>> preliminary patent BEFORE disclosure, he is given a limited amount
>>>> of time to finalize it, but I think too much time has passed now
>>>> for that to be an option.
>>>>
>>>> There is also the problem tha that you need to demonstrate that it
>>>> works.
>>>
>>> You are obviously unaware of the USPTO which allows patent trolls to
>>> file vague nebulous patents all the time that are certainly not
>>> "demonstrated to work". Patent trolls don't make money by creating
>>> patented product, they make money through litigation if they think
>>> their vague patents can be asserted in a congenial legal district.
>>>
>>> /Flibble
>>>
>>
>> And you are not aware that such patents can be declared invalid, and
>> the trolls required to pay the legal fees of the chalenger if said
>> patent is determined to have been fraudulently field.
>>
>> Yes, some trolls do get away with invalid patents because it isn't
>> worth the effort.
>>
>> Note also, "work" doesn't need to be commercially viable, so can be a
>> low standard in some fields.
>>
>> A patent must include a sample implementation of the invention it
>> claims, and claims about what that implementation can do. "Lying"
>> about that ability invalidates the patent.
>
> Filing a patent and ruling a filed patent is invalid in court are two
> different things, dear.
>
> /Flibble
>


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<3pQbL.72242$Jjx8.39346@fx15.iad>

  copy mid

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

  copy link   Newsgroups: sci.logic comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx15.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.2
Subject: Re: Simulating halt decider applied to a simpler input
Content-Language: en-US
Newsgroups: sci.logic,comp.theory
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm9ed$u30u$8@dont-email.me> <tkmvum$18v4$1@gioia.aioe.org>
<tkn0i4$1efu$1@gioia.aioe.org> <tknbbt$140dq$1@dont-email.me>
<MTNbL.90219$2Rs3.48881@fx12.iad> <20221112143106.0000780b@reddwarf.jmc.corp>
<tkoavt$16bfq$1@dont-email.me> <LwObL.82893$8ga9.66084@fx18.iad>
<20221112151611.00000462@reddwarf.jmc.corp> <e9PbL.83198$8ga9.33939@fx18.iad>
<20221112155240.00005446@reddwarf.jmc.corp> <rzPbL.70276$Jjx8.10873@fx15.iad>
<20221112164256.0000371e@reddwarf.jmc.corp>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <20221112164256.0000371e@reddwarf.jmc.corp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 225
Message-ID: <3pQbL.72242$Jjx8.39346@fx15.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: Sat, 12 Nov 2022 12:07:07 -0500
X-Received-Bytes: 12006
 by: Richard Damon - Sat, 12 Nov 2022 17:07 UTC

On 11/12/22 11:42 AM, Mr Flibble wrote:
> On Sat, 12 Nov 2022 11:09:56 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 11/12/22 10:52 AM, Mr Flibble wrote:
>>> On Sat, 12 Nov 2022 10:41:58 -0500
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 11/12/22 10:16 AM, Mr Flibble wrote:
>>>>> On Sat, 12 Nov 2022 09:58:47 -0500
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>
>>>>>> On 11/12/22 9:35 AM, olcott wrote:
>>>>>>> On 11/12/2022 8:31 AM, Mr Flibble wrote:
>>>>>>>> On Sat, 12 Nov 2022 09:15:04 -0500
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>
>>>>>>>>> On 11/12/22 12:35 AM, olcott wrote:
>>>>>>>>>> On 11/11/2022 8:31 PM, Sergi o wrote:
>>>>>>>>>>> On 11/11/2022 8:21 PM, olcott wrote:
>>>>>>>>>>>> On 11/11/2022 1:56 PM, Jeff Barnett wrote:
>>>>>>>>>>>>> On 11/11/2022 11:43 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you and I
>>>>>>>>>>>>>>> would have thought given your intelligence you would
>>>>>>>>>>>>>>> also understand that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I say this because at times he seems to respond to what I
>>>>>>>>>>>>>> say, even if not in a direct reply,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>
>>>>>>>>>>>>> How is that working? Do you really think that repeating
>>>>>>>>>>>>> yourself literally 1000's of times makes good reading?
>>>>>>>>>>>>> Almost anyone who can look deeply enough into the logic
>>>>>>>>>>>>> will notice you engaging in a supposed dialogue with a
>>>>>>>>>>>>> stone wall (actually a stone brain). After your first half
>>>>>>>>>>>>> dozen messages a few years ago, you have added nothing to
>>>>>>>>>>>>> the conversation. Time to move on.
>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It's a trivial truth and few will be fooled. Further, the
>>>>>>>>>>>>> real truth tellers and teachers do not hang out in these
>>>>>>>>>>>>> groups or archives. Too many truth tellers too few
>>>>>>>>>>>>> acolytes shrewd enough to know who has the inside track
>>>>>>>>>>>>> on god's word. Did you know that PO, in his less lucid
>>>>>>>>>>>>> moments, thinks he's a truth teller too? Truth tellers
>>>>>>>>>>>>> only pass the word when they preach to the choir.
>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his explanation
>>>>>>>>>>>>>> into explicit words, his errors become very apparent, I
>>>>>>>>>>>>>> think even to him, so he just refuses.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So what? Rather than save the world from a babbling idiot,
>>>>>>>>>>>>> why not rescue homeless puppies at risk? You would be
>>>>>>>>>>>>> doing a better thing and would be more admired. A
>>>>>>>>>>>>> mathematical social worker is not needed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think, instead, you don't know what to do with your time
>>>>>>>>>>>>> and have select this task to fill the gaps. Anyone
>>>>>>>>>>>>> studying the archives will notice that PO is the clear
>>>>>>>>>>>>> victor in all these threads. His head is too thick to be
>>>>>>>>>>>>> bothered by facts or sort-of facts; he's too ignorant and
>>>>>>>>>>>>> proud to be bothered by anyone else's facts or religion;
>>>>>>>>>>>>> and some of your presentations (articles) are not worded
>>>>>>>>>>>>> in the best way or are slightly misleading to someone who
>>>>>>>>>>>>> doesn't already know most of what you meant to say.
>>>>>>>>>>>>> (That's a problem with most of us writing articles
>>>>>>>>>>>>> without a few hours reflection before posting.) You will
>>>>>>>>>>>>> not win this way.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since I think you seek recognition for your efforts as a
>>>>>>>>>>>>> white knight and it's not working, I suggest you go black
>>>>>>>>>>>>> hat! Beat PO at his own game: Initiate threads five to
>>>>>>>>>>>>> twenty times a week; Have response chains where you
>>>>>>>>>>>>> respond significant numbers of times to your own
>>>>>>>>>>>>> articles; Be outrageous!
>>>>>>>>>>>>>
>>>>>>>>>>>>> This will only work if you devote enough time to take all
>>>>>>>>>>>>> of the PO USENET distinctions away from him. You must,
>>>>>>>>>>>>> every month, win the honors for (1) most threads started,
>>>>>>>>>>>>> (2) most number of responses to threads you have started,
>>>>>>>>>>>>> (3) most posts by an individual, (4) threads with largest
>>>>>>>>>>>>> number of indentations, (5) the highest number of almost
>>>>>>>>>>>>> repetitious posts - slight variations required, (6)
>>>>>>>>>>>>> highest percentage of silly capitalization, and (7) most
>>>>>>>>>>>>> times breaking USENET rules on text postings.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When you follow the above seven point program (and you are
>>>>>>>>>>>>> well on your way in many of the points) you will eclipse
>>>>>>>>>>>>> PO and he will go POOF into a heap of dust. You will have
>>>>>>>>>>>>> won! At last. and history and the titles will be yours.
>>>>>>>>>>>>> You will be known to future USENET generations, for as
>>>>>>>>>>>>> long as the archives are maintained, as a winner.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, and this is an important however, you will have
>>>>>>>>>>>>> approximately the same impact on the truth as you do now.
>>>>>>>>>>>>> Why not have fun instead?
>>>>>>>>>>>>
>>>>>>>>>>>> I made the basis of my proof much easier to understand so
>>>>>>>>>>>> that anyone that is an expert in the C programming language
>>>>>>>>>>>> would be able to understand a simulating halt decider.
>>>>>>>>>>>>
>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>> {
>>>>>>>>>>>>     H(x, x);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> When H(D,D) returns 0 it correctly predicts that D
>>>>>>>>>>>> correctly simulated by H would never reach its own final
>>>>>>>>>>>> state and terminate normally after 1 to ∞ of correct
>>>>>>>>>>>> simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> I predict that no one will be able to find any actual error
>>>>>>>>>>>> with that.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> if it doesn't bust the compiler, run it through a code
>>>>>>>>>>> checker, lots of free ones out there
>>>>>>>>>>>
>>>>>>>>>>> https://www.onlinegdb.com/online_c_compiler
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The last remaining issue is the acceptance of the notion of a
>>>>>>>>>> simulating halt decider.
>>>>>>>>>
>>>>>>>>> Why, It is actually a well know concept, as a PARTIAL solution
>>>>>>>>> of the problem.
>>>>>>>>>
>>>>>>>>> I remember it being shown as why you CAN'T just solve the
>>>>>>>>> problem with one.
>>>>>>>>>
>>>>>>>>> Your ignorance of the history of this topic has doomed you to
>>>>>>>>> repeat all the errors that others have made in the past.
>>>>>>>>
>>>>>>>> A simulating halt decider is Olcott's idea.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> Thanks. I was thinking about filing a trademark on it.
>>>>>>>
>>>>>>
>>>>>> Go ahead and waste your money.
>>>>>>
>>>>>> I remember the discussion of trying to determine halting by
>>>>>> simulation back in my school days, so not a new concept. Normally
>>>>>> showing the simple reasons about why it doesn't work.
>>>>>>
>>>>>> Note, this is pre-internet, so your Google searches not bringing
>>>>>> it up is understandable.
>>>>>>
>>>>>> Likely didn't reach "published papers" as it was a well known
>>>>>> dead end so no need to write the paper.
>>>>>
>>>>> So you have no evidence to backup that claim. So no prior art
>>>>> leaving Olcott free to trademark or file a patent.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> He can't file a patent, as he has publicly disclosed the idea too
>>>> long ago. Public disclosure precludes later patent. If he filed a
>>>> preliminary patent BEFORE disclosure, he is given a limited amount
>>>> of time to finalize it, but I think too much time has passed now
>>>> for that to be an option.
>>>>
>>>> There is also the problem tha that you need to demonstrate that it
>>>> works.
>>>
>>> You are obviously unaware of the USPTO which allows patent trolls to
>>> file vague nebulous patents all the time that are certainly not
>>> "demonstrated to work". Patent trolls don't make money by creating
>>> patented product, they make money through litigation if they think
>>> their vague patents can be asserted in a congenial legal district.
>>>
>>> /Flibble
>>>
>>
>> And you are not aware that such patents can be declared invalid, and
>> the trolls required to pay the legal fees of the chalenger if said
>> patent is determined to have been fraudulently field.
>>
>> Yes, some trolls do get away with invalid patents because it isn't
>> worth the effort.
>>
>> Note also, "work" doesn't need to be commercially viable, so can be a
>> low standard in some fields.
>>
>> A patent must include a sample implementation of the invention it
>> claims, and claims about what that implementation can do. "Lying"
>> about that ability invalidates the patent.
>
> Filing a patent and ruling a filed patent is invalid in court are two
> different things, dear.
>
> /Flibble
>


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<_9RbL.5611$gBW5.2085@fx06.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx06.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.2
Subject: Re: Simulating halt decider applied to a simpler input
Content-Language: en-US
Newsgroups: comp.theory,sci.logic
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
<6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tkojg4$172nl$2@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 303
Message-ID: <_9RbL.5611$gBW5.2085@fx06.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: Sat, 12 Nov 2022 12:59:18 -0500
X-Received-Bytes: 15224
 by: Richard Damon - Sat, 12 Nov 2022 17:59 UTC

On 11/12/22 12:00 PM, olcott wrote:
> On 11/12/2022 10:26 AM, Richard Damon wrote:
>> On 11/12/22 10:50 AM, olcott wrote:
>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>
>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the infinite
>>>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so any
>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>
>>>>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>>>>> halt decision of non-halting; it needs to instead be mapped to
>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>
>>>>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>>> directly express a reference.
>>>>>>>>>>
>>>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>>>>> different way.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>>>> actually a decider.
>>>>>>>>>
>>>>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>
>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>> calls the decider.
>>>>>>>>>
>>>>>>>>> After that, it is the deciders job to make the decision in finite
>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>
>>>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>>>> the requirements.
>>>>>>>>>
>>>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>>>> copy of something that just happens to be its own description.
>>>>>>>>>
>>>>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>>>> effect of the Self-Reference just lets us see that the task turns
>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>
>>>>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>>>>> not due to self reference or infinite copies but because the input
>>>>>>>> tries to do the opposite of what the decider decides; the category
>>>>>>>> error that I have identified is different: it is an error of self
>>>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>>>> fact that the input references a decider rather than being related
>>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>>>> ANY input and answer in finite time, If an input causes it to make
>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>> requirements.
>>>>>>>
>>>>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>>>> if H is actualy a Turing Machine.
>>>>>>>
>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>> admitting that your H can't actually be a Turing Machine, but must
>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>> requirement to be the needed decider.
>>>>>>
>>>>>> In which case we get infinite turning machines all the way down: yet
>>>>>> another manifestation of the category error I have identified.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> Where are infinite machines? There is ONE machine being run, either H
>>>>> or D, and it SIMULATING others, and if we get an infinite sequence of
>>>>> simulations we have just shown that H was defective because it failed
>>>>> to answer in finite time.
>>>>>
>>>>> This isn't a category error, but a design error in H.
>>>>>
>>>>> Note, when we start H, there is exactly two machines present in
>>>>> representation on the tape, and two is much smaller than infinity.
>>>>
>>>> Nope, if,
>>>>
>>>> a) H is a copy, and
>>>> b) H is a Turing Machine, and
>>>> c) D is an input into H, and
>>>> d) D references H, and
>>>> e) H references D,
>>>>
>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing Machines
>>>> all the way down: a manifestation of the category error I have
>>>> identified.
>>>>
>>>> /Flibble
>>>>
>>>
>>> void E(void (*x)())
>>> {
>>>    H(x, x);
>>> }
>>>
>>> The point is
>>> that D correctly simulated by H would never reach its own last
>>> instruction and terminate normally after 1 to ∞ steps of correct
>>> simulation.
>>>
>>> When H returns 0 to main() it is indicating
>>>
>>> that D correctly simulated by H would never reach its own last
>>> instruction and terminate normally after 1 to ∞ steps of correct
>>> simulation.
>>>
>>
>> Except D is NOT correctly simulated by H, so that is a incorrect
>> statement. When it is correctly simulated by something other than H,
>> it will come to a final state, showing your statement is wrong.
> In order for the simulation to actually be incorrect the execution trace
> of the simulated E must diverge from the behavior that the line-by-line
> x86 source-code of E specifies.


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<tkonum$17cpp$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic
Subject: Re: Simulating halt decider applied to a simpler input
Date: Sat, 12 Nov 2022 12:16:53 -0600
Organization: A noiseless patient Spider
Lines: 312
Message-ID: <tkonum$17cpp$1@dont-email.me>
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
<6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me>
<_9RbL.5611$gBW5.2085@fx06.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 12 Nov 2022 18:16:54 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="d8c82b31b36f6d47fb6bf54a1e329d6a";
logging-data="1291065"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18CruAV3xphkO4hN9zuqK5D"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.4.2
Cancel-Lock: sha1:5BasMmlpHDKGzqLlCm2Ho/6pylE=
In-Reply-To: <_9RbL.5611$gBW5.2085@fx06.iad>
Content-Language: en-US
 by: olcott - Sat, 12 Nov 2022 18:16 UTC

On 11/12/2022 11:59 AM, Richard Damon wrote:
> On 11/12/22 12:00 PM, olcott wrote:
>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>> On 11/12/22 10:50 AM, olcott wrote:
>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>
>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the infinite
>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so any
>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be mapped to
>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>
>>>>>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>
>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>>>>>> different way.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>>>>> actually a decider.
>>>>>>>>>>
>>>>>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>
>>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>>> calls the decider.
>>>>>>>>>>
>>>>>>>>>> After that, it is the deciders job to make the decision in finite
>>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>
>>>>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>>>>> the requirements.
>>>>>>>>>>
>>>>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>>>>> copy of something that just happens to be its own description.
>>>>>>>>>>
>>>>>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>>>>> effect of the Self-Reference just lets us see that the task turns
>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>
>>>>>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>>>>>> not due to self reference or infinite copies but because the input
>>>>>>>>> tries to do the opposite of what the decider decides; the category
>>>>>>>>> error that I have identified is different: it is an error of self
>>>>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>>>>> fact that the input references a decider rather than being related
>>>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>>>>> ANY input and answer in finite time, If an input causes it to make
>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>> requirements.
>>>>>>>>
>>>>>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>
>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>> admitting that your H can't actually be a Turing Machine, but must
>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>> requirement to be the needed decider.
>>>>>>>
>>>>>>> In which case we get infinite turning machines all the way down: yet
>>>>>>> another manifestation of the category error I have identified.
>>>>>>>
>>>>>>> /Flibble
>>>>>>
>>>>>> Where are infinite machines? There is ONE machine being run, either H
>>>>>> or D, and it SIMULATING others, and if we get an infinite sequence of
>>>>>> simulations we have just shown that H was defective because it failed
>>>>>> to answer in finite time.
>>>>>>
>>>>>> This isn't a category error, but a design error in H.
>>>>>>
>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>> representation on the tape, and two is much smaller than infinity.
>>>>>
>>>>> Nope, if,
>>>>>
>>>>> a) H is a copy, and
>>>>> b) H is a Turing Machine, and
>>>>> c) D is an input into H, and
>>>>> d) D references H, and
>>>>> e) H references D,
>>>>>
>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>> Machines
>>>>> all the way down: a manifestation of the category error I have
>>>>> identified.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> void E(void (*x)())
>>>> {
>>>>    H(x, x);
>>>> }
>>>>
>>>> The point is
>>>> that D correctly simulated by H would never reach its own last
>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>> simulation.
>>>>
>>>> When H returns 0 to main() it is indicating
>>>>
>>>> that D correctly simulated by H would never reach its own last
>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>> simulation.
>>>>
>>>
>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>> statement. When it is correctly simulated by something other than H,
>>> it will come to a final state, showing your statement is wrong.
>> In order for the simulation to actually be incorrect the execution
>> trace of the simulated E must diverge from the behavior that the
>> line-by-line x86 source-code of E specifies.
>
> Right, and since you simulation does NOT continue past the call to H, it
> is "incorrect" in the sense that the actual code does continue past that
> point, so it does not actually match the behavior of that machine.
>
>>
>> The first seven lines of the execution trace of the simulated E
>> exactly match the behavior specified by the first seven lines of the
>> x86 source code of E. This conclusively proves beyond all possible
>> doubt that these first seven lines have been simulated correctly.
>
> Right, so H has correctly done a PARTIAL simulation of its input, which
> does NOT prove the input is non-halting.
>
>>
>> *H correctly determines that E never halts*
>>
>> void E(void (*x)())
>> {
>>    H(x, x);
>> }
>>
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H(E, E));
>> }
>>
>> _E()
>> [000019d2] 55             push ebp
>> [000019d3] 8bec           mov ebp,esp
>> [000019d5] 8b4508         mov eax,[ebp+08]
>> [000019d8] 50             push eax
>> [000019d9] 8b4d08         mov ecx,[ebp+08]
>> [000019dc] 51             push ecx
>> [000019dd] e8b0f9ffff     call 00001392
>> [000019e2] 83c408         add esp,+08
>> [000019e5] 5d             pop ebp
>> [000019e6] c3             ret
>> Size in bytes:(0021) [000019e6]
>>
>> _main()
>> [000019f2] 55             push ebp
>> [000019f3] 8bec           mov ebp,esp
>> [000019f5] 68d2190000     push 000019d2
>> [000019fa] 68d2190000     push 000019d2
>> [000019ff] e88ef9ffff     call 00001392
>> [00001a04] 83c408         add esp,+08
>> [00001a07] 50             push eax
>> [00001a08] 6893060000     push 00000693
>> [00001a0d] e8a0ecffff     call 000006b2
>> [00001a12] 83c408         add esp,+08
>> [00001a15] 33c0           xor eax,eax
>> [00001a17] 5d             pop ebp
>> [00001a18] c3             ret
>> Size in bytes:(0039) [00001a18]
>>
>>   machine   stack     stack     machine    assembly
>>   address   address   data      code       language
>>   ========  ========  ========  =========  =============
>> [000019f2][00102a7c][00000000] 55         push ebp
>> [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>
>> H: Begin Simulation   Execution Trace Stored at:112b28
>> Address_of_H:1392
>> [000019d2][00112b14][00112b18] 55         push ebp
>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>> [000019d8][00112b10][000019d2] 50         push eax         // push E
>> [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
>> [000019dc][00112b0c][000019d2] 51         push ecx         // push E
>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    // call H
>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>
>> H correctly reports that E correctly simulated by H cannot possibly
>> reach its own final state at machine address [000019e6] and terminate
>> normally in 1 to ∞ steps of correct simulation.
>>
>>
>
> So you are just admitting you don't understand the Halting Criteria.
>
> The fact that H stops its simulation before it gets to the end does NOT
> prove that the machine being simulated, or a correct and complete
> simultion of the input would be non-halting.
We must handle only one point at a time because you are easily
overwhelmed. You usually cannot even handle one point at a time until
this point is repeated 20 or more times.


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<20221112181916.000042d0@reddwarf.jmc.corp>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Date: Sat, 12 Nov 2022 18:19:16 +0000
From: flib...@reddwarf.jmc.corp (Mr Flibble)
Newsgroups: comp.theory,sci.logic
Subject: Re: Simulating halt decider applied to a simpler input
Message-ID: <20221112181916.000042d0@reddwarf.jmc.corp>
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad> <20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad> <tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad> <tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad> <tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad> <20221111215433.00005425@reddwarf.jmc.corp> <dSAbL.106246$U709.51175@fx16.iad> <20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad> <20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad> <20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad> <20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me> <6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me> <_9RbL.5611$gBW5.2085@fx06.iad>
Organization: NewsDemon - www.newsdemon.com
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Lines: 357
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder.usenetexpress.com!tr1.eu1.usenetexpress.com!news.newsdemon.com!not-for-mail
NNTP-Posting-Date: Sat, 12 Nov 2022 18:19:16 +0000
X-Received-Bytes: 17609
X-Complaints-To: abuse@newsdemon.com
 by: Mr Flibble - Sat, 12 Nov 2022 18:19 UTC

On Sat, 12 Nov 2022 12:59:18 -0500
Richard Damon <Richard@Damon-Family.org> wrote:

> On 11/12/22 12:00 PM, olcott wrote:
> > On 11/12/2022 10:26 AM, Richard Damon wrote:
> >> On 11/12/22 10:50 AM, olcott wrote:
> >>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
> >>>> On Sat, 12 Nov 2022 09:52:12 -0500
> >>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>
> >>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
> >>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
> >>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
> >>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
> >>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
> >>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
> >>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
> >>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
> >>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
> >>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked
> >>>>>>>>>>>>>>>>>>>> you and I would have thought given your
> >>>>>>>>>>>>>>>>>>>> intelligence you would also understand that.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
> >>>>>>>>>>>>>>>>>>> mostly ignores me.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
> >>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he
> >>>>>>>>>>>>>>>>>>> has blocked me, he will still see me.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
> >>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to
> >>>>>>>>>>>>>>>>>>> point out his errors.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
> >>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the
> >>>>>>>>>>>>>>>>>>> Truth.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that
> >>>>>>>>>>>>>>>>>>> he doesn't actually know what he is talking
> >>>>>>>>>>>>>>>>>>> about, and reveals his ignorance. If he tries to
> >>>>>>>>>>>>>>>>>>> put his explanation into explicit words, his
> >>>>>>>>>>>>>>>>>>> errors become very apparent, I think even to him,
> >>>>>>>>>>>>>>>>>>> so he just refuses.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
> >>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet
> >>>>>>>>>>>>>>>>>> naive readers are not in my target audience.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
> >>>>>>>>>>>>>>>>> Halting Decider.
> >>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
> >>>>>>>>>>>>>>>> Turing machine (UTM) knows that the behavior of D
> >>>>>>>>>>>>>>>> correctly simulated by H provides H with a correct
> >>>>>>>>>>>>>>>> basis for its halt status decision.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> void E(void (*x)())
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>         H(x, x);
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
> >>>>>>>>>>>>>> infinite execution of E is correct to report
> >>>>>>>>>>>>>> non-halting. No shell game can correctly deny this.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
> >>>>>>>>>>>>> because the CORRECT simulation, as will the diret
> >>>>>>>>>>>>> exectuion, will halt. Note, such an H doesn't do a
> >>>>>>>>>>>>> correct simulation, so any arguement based on it doing
> >>>>>>>>>>>>> so it just WRONG.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The need to abort the simulation is due to the self
> >>>>>>>>>>>> reference category error present in the proof; what
> >>>>>>>>>>>> Olcott is getting wrong is the mapping of the need to
> >>>>>>>>>>>> abort the simulation to a halt decision of non-halting;
> >>>>>>>>>>>> it needs to instead be mapped to INVALID INPUT.
> >>>>>>>>>>>>
> >>>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>> Nope, no self reference.
> >>>>>>>>>>>
> >>>>>>>>>>> E just has a copy of the H that claim to be deciding it,
> >>>>>>>>>>> not a "reference" to it. Turing Machines do not have the
> >>>>>>>>>>> power to directly express a reference.
> >>>>>>>>>>
> >>>>>>>>>> Nope, if it isn't a self reference then it is infinite
> >>>>>>>>>> copies all the way down so is the same category error
> >>>>>>>>>> manifesting in a different way.
> >>>>>>>>>>
> >>>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>> Only if the "decider" makes that happen, in which case it
> >>>>>>>>> isn't actually a decider.
> >>>>>>>>>
> >>>>>>>>> If we assume a prospective decider exists, then the
> >>>>>>>>> "Impossible" program is simple to make from it, and is
> >>>>>>>>> given one copy of the description of itself, which is also
> >>>>>>>>> simple to make.
> >>>>>>>>>
> >>>>>>>>> When run it makes a second copy of its description, and then
> >>>>>>>>> calls the decider.
> >>>>>>>>>
> >>>>>>>>> After that, it is the deciders job to make the decision in
> >>>>>>>>> finite time, by whatever method it wants. If it gets stuck
> >>>>>>>>> in your infinite loop, the decider is just wrong.
> >>>>>>>>>
> >>>>>>>>> The proof shows that what ever answer the decider does give
> >>>>>>>>> (if it gives one) will be wrong, and thus the decider
> >>>>>>>>> doesn't meet the requirements.
> >>>>>>>>>
> >>>>>>>>> No "Self Reference" in sight there only a program being
> >>>>>>>>> given a copy of something that just happens to be its own
> >>>>>>>>> description.
> >>>>>>>>>
> >>>>>>>>> The only place we get any form of "Reference", is when we
> >>>>>>>>> try to ANALYSE or DESIGN the H to try to meet the
> >>>>>>>>> challenge. There the effect of the Self-Reference just lets
> >>>>>>>>> us see that the task turns out be be impossible, so no such
> >>>>>>>>> program exists.
> >>>>>>>>
> >>>>>>>> You are fractally wrong on all fronts: in the traditional
> >>>>>>>> halting problem proofs based on [Strachey 1965] the program
> >>>>>>>> is impossible not due to self reference or infinite copies
> >>>>>>>> but because the input tries to do the opposite of what the
> >>>>>>>> decider decides; the category error that I have identified
> >>>>>>>> is different: it is an error of self reference and/or
> >>>>>>>> infinite copies; it is an error related to the fact that the
> >>>>>>>> input references a decider rather than being related to what
> >>>>>>>> the input does with the decision result of a decider.
> >>>>>>>>
> >>>>>>>> /Flibble
> >>>>>>>
> >>>>>>> But the infinite copies is a error in the Decider, not in
> >>>>>>> Strachey's program. The decider is SUPPOSED to be able to
> >>>>>>> handle ANY input and answer in finite time, If an input
> >>>>>>> causes it to make infinite copies, then the decided just
> >>>>>>> doesn't meet its requirements.
> >>>>>>>
> >>>>>>> Turing Machine can ALWAYS be legally built based on another
> >>>>>>> Turing Machine as a base. The only reason it wouldn't be
> >>>>>>> allowed is if H isn't actually a Turing Machine, so it CAN'T
> >>>>>>> be a category error if H is actualy a Turing Machine.
> >>>>>>>
> >>>>>>> All your declaration of a "Category Error" here is doing is
> >>>>>>> admitting that your H can't actually be a Turing Machine, but
> >>>>>>> must be of a HIGHER order logic system, which means H fails
> >>>>>>> the requirement to be the needed decider.
> >>>>>>
> >>>>>> In which case we get infinite turning machines all the way
> >>>>>> down: yet another manifestation of the category error I have
> >>>>>> identified.
> >>>>>>
> >>>>>> /Flibble
> >>>>>
> >>>>> Where are infinite machines? There is ONE machine being run,
> >>>>> either H or D, and it SIMULATING others, and if we get an
> >>>>> infinite sequence of simulations we have just shown that H was
> >>>>> defective because it failed to answer in finite time.
> >>>>>
> >>>>> This isn't a category error, but a design error in H.
> >>>>>
> >>>>> Note, when we start H, there is exactly two machines present in
> >>>>> representation on the tape, and two is much smaller than
> >>>>> infinity.
> >>>>
> >>>> Nope, if,
> >>>>
> >>>> a) H is a copy, and
> >>>> b) H is a Turing Machine, and
> >>>> c) D is an input into H, and
> >>>> d) D references H, and
> >>>> e) H references D,
> >>>>
> >>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
> >>>> Machines all the way down: a manifestation of the category error
> >>>> I have identified.
> >>>>
> >>>> /Flibble
> >>>>
> >>>
> >>> void E(void (*x)())
> >>> {
> >>>    H(x, x);
> >>> }
> >>>
> >>> The point is
> >>> that D correctly simulated by H would never reach its own last
> >>> instruction and terminate normally after 1 to ∞ steps of correct
> >>> simulation.
> >>>
> >>> When H returns 0 to main() it is indicating
> >>>
> >>> that D correctly simulated by H would never reach its own last
> >>> instruction and terminate normally after 1 to ∞ steps of correct
> >>> simulation.
> >>>
> >>
> >> Except D is NOT correctly simulated by H, so that is a incorrect
> >> statement. When it is correctly simulated by something other than
> >> H, it will come to a final state, showing your statement is wrong.
> >>
> > In order for the simulation to actually be incorrect the execution
> > trace of the simulated E must diverge from the behavior that the
> > line-by-line x86 source-code of E specifies.
>
> Right, and since you simulation does NOT continue past the call to H,
> it is "incorrect" in the sense that the actual code does continue
> past that point, so it does not actually match the behavior of that
> machine.
>
> >
> > The first seven lines of the execution trace of the simulated E
> > exactly match the behavior specified by the first seven lines of
> > the x86 source code of E. This conclusively proves beyond all
> > possible doubt that these first seven lines have been simulated
> > correctly.
>
> Right, so H has correctly done a PARTIAL simulation of its input,
> which does NOT prove the input is non-halting.
>
> >
> > *H correctly determines that E never halts*
> >
> > void E(void (*x)())
> > {
> >   H(x, x);
> > }
> >
> >
> > int main()
> > {
> >   Output("Input_Halts = ", H(E, E));
> > }
> >
> > _E()
> > [000019d2] 55             push ebp
> > [000019d3] 8bec           mov ebp,esp
> > [000019d5] 8b4508         mov eax,[ebp+08]
> > [000019d8] 50             push eax
> > [000019d9] 8b4d08         mov ecx,[ebp+08]
> > [000019dc] 51             push ecx
> > [000019dd] e8b0f9ffff     call 00001392
> > [000019e2] 83c408         add esp,+08
> > [000019e5] 5d             pop ebp
> > [000019e6] c3             ret
> > Size in bytes:(0021) [000019e6]
> >
> > _main()
> > [000019f2] 55             push ebp
> > [000019f3] 8bec           mov ebp,esp
> > [000019f5] 68d2190000     push 000019d2
> > [000019fa] 68d2190000     push 000019d2
> > [000019ff] e88ef9ffff     call 00001392
> > [00001a04] 83c408         add esp,+08
> > [00001a07] 50             push eax
> > [00001a08] 6893060000     push 00000693
> > [00001a0d] e8a0ecffff     call 000006b2
> > [00001a12] 83c408         add esp,+08
> > [00001a15] 33c0           xor eax,eax
> > [00001a17] 5d             pop ebp
> > [00001a18] c3             ret
> > Size in bytes:(0039) [00001a18]
> >
> >  machine   stack     stack     machine    assembly
> >  address   address   data      code       language
> >  ========  ========  ========  =========  ============> > [000019f2][00102a7c][00000000] 55         push ebp
> > [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
> > [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
> > [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
> > [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
> >
> > H: Begin Simulation   Execution Trace Stored at:112b28
> > Address_of_H:1392
> > [000019d2][00112b14][00112b18] 55         push ebp
> > [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
> > [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
> > [000019d8][00112b10][000019d2] 50         push eax         // push E
> > [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
> > [000019dc][00112b0c][000019d2] 51         push ecx         // push E
> > [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    // call H
> > H: Infinitely Recursive Simulation Detected Simulation Stopped
> >
> > H correctly reports that E correctly simulated by H cannot possibly
> > reach its own final state at machine address [000019e6] and
> > terminate normally in 1 to ∞ steps of correct simulation.
> >
> >
>
> So you are just admitting you don't understand the Halting Criteria.
>
> The fact that H stops its simulation before it gets to the end does
> NOT prove that the machine being simulated, or a correct and complete
> simultion of the input would be non-halting.
>
> Or, do you claim that you have correctly climbed Mount Everest since
> ever step of you climb of it were correct?
>
> You are just proving you lack of understanding of the meaning of a
> correct simulation.


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<7xRbL.11594$o6Z5.1319@fx07.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx07.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.2
Subject: Re: Simulating halt decider applied to a simpler input
Content-Language: en-US
Newsgroups: comp.theory,sci.logic
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
<6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me>
<_9RbL.5611$gBW5.2085@fx06.iad> <tkonum$17cpp$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tkonum$17cpp$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 339
Message-ID: <7xRbL.11594$o6Z5.1319@fx07.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: Sat, 12 Nov 2022 13:24:00 -0500
X-Received-Bytes: 17122
 by: Richard Damon - Sat, 12 Nov 2022 18:24 UTC

On 11/12/22 1:16 PM, olcott wrote:
> On 11/12/2022 11:59 AM, Richard Damon wrote:
>> On 11/12/22 12:00 PM, olcott wrote:
>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>
>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the
>>>>>>>>>>>>>>>>>>>>> Truth.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so
>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be
>>>>>>>>>>>>>> mapped to
>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>
>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>>>>>>> different way.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>>>>>> actually a decider.
>>>>>>>>>>>
>>>>>>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>>
>>>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>>>> calls the decider.
>>>>>>>>>>>
>>>>>>>>>>> After that, it is the deciders job to make the decision in
>>>>>>>>>>> finite
>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>>
>>>>>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>>>>>> the requirements.
>>>>>>>>>>>
>>>>>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>>>>>> copy of something that just happens to be its own description.
>>>>>>>>>>>
>>>>>>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>>>>>> effect of the Self-Reference just lets us see that the task
>>>>>>>>>>> turns
>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>
>>>>>>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>>>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>>>>>>> not due to self reference or infinite copies but because the
>>>>>>>>>> input
>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>> category
>>>>>>>>>> error that I have identified is different: it is an error of self
>>>>>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>>>>>> fact that the input references a decider rather than being
>>>>>>>>>> related
>>>>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>>>>>> ANY input and answer in finite time, If an input causes it to make
>>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>>> requirements.
>>>>>>>>>
>>>>>>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>>>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>>
>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>> admitting that your H can't actually be a Turing Machine, but must
>>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>>> requirement to be the needed decider.
>>>>>>>>
>>>>>>>> In which case we get infinite turning machines all the way down:
>>>>>>>> yet
>>>>>>>> another manifestation of the category error I have identified.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>> either H
>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>> sequence of
>>>>>>> simulations we have just shown that H was defective because it
>>>>>>> failed
>>>>>>> to answer in finite time.
>>>>>>>
>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>
>>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>>> representation on the tape, and two is much smaller than infinity.
>>>>>>
>>>>>> Nope, if,
>>>>>>
>>>>>> a) H is a copy, and
>>>>>> b) H is a Turing Machine, and
>>>>>> c) D is an input into H, and
>>>>>> d) D references H, and
>>>>>> e) H references D,
>>>>>>
>>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>>> Machines
>>>>>> all the way down: a manifestation of the category error I have
>>>>>> identified.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> void E(void (*x)())
>>>>> {
>>>>>    H(x, x);
>>>>> }
>>>>>
>>>>> The point is
>>>>> that D correctly simulated by H would never reach its own last
>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>> simulation.
>>>>>
>>>>> When H returns 0 to main() it is indicating
>>>>>
>>>>> that D correctly simulated by H would never reach its own last
>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>> simulation.
>>>>>
>>>>
>>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>>> statement. When it is correctly simulated by something other than H,
>>>> it will come to a final state, showing your statement is wrong.
>>> In order for the simulation to actually be incorrect the execution
>>> trace of the simulated E must diverge from the behavior that the
>>> line-by-line x86 source-code of E specifies.
>>
>> Right, and since you simulation does NOT continue past the call to H,
>> it is "incorrect" in the sense that the actual code does continue past
>> that point, so it does not actually match the behavior of that machine.
>>
>>>
>>> The first seven lines of the execution trace of the simulated E
>>> exactly match the behavior specified by the first seven lines of the
>>> x86 source code of E. This conclusively proves beyond all possible
>>> doubt that these first seven lines have been simulated correctly.
>>
>> Right, so H has correctly done a PARTIAL simulation of its input,
>> which does NOT prove the input is non-halting.
>>
>>>
>>> *H correctly determines that E never halts*
>>>
>>> void E(void (*x)())
>>> {
>>>    H(x, x);
>>> }
>>>
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H(E, E));
>>> }
>>>
>>> _E()
>>> [000019d2] 55             push ebp
>>> [000019d3] 8bec           mov ebp,esp
>>> [000019d5] 8b4508         mov eax,[ebp+08]
>>> [000019d8] 50             push eax
>>> [000019d9] 8b4d08         mov ecx,[ebp+08]
>>> [000019dc] 51             push ecx
>>> [000019dd] e8b0f9ffff     call 00001392
>>> [000019e2] 83c408         add esp,+08
>>> [000019e5] 5d             pop ebp
>>> [000019e6] c3             ret
>>> Size in bytes:(0021) [000019e6]
>>>
>>> _main()
>>> [000019f2] 55             push ebp
>>> [000019f3] 8bec           mov ebp,esp
>>> [000019f5] 68d2190000     push 000019d2
>>> [000019fa] 68d2190000     push 000019d2
>>> [000019ff] e88ef9ffff     call 00001392
>>> [00001a04] 83c408         add esp,+08
>>> [00001a07] 50             push eax
>>> [00001a08] 6893060000     push 00000693
>>> [00001a0d] e8a0ecffff     call 000006b2
>>> [00001a12] 83c408         add esp,+08
>>> [00001a15] 33c0           xor eax,eax
>>> [00001a17] 5d             pop ebp
>>> [00001a18] c3             ret
>>> Size in bytes:(0039) [00001a18]
>>>
>>>   machine   stack     stack     machine    assembly
>>>   address   address   data      code       language
>>>   ========  ========  ========  =========  =============
>>> [000019f2][00102a7c][00000000] 55         push ebp
>>> [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>
>>> H: Begin Simulation   Execution Trace Stored at:112b28
>>> Address_of_H:1392
>>> [000019d2][00112b14][00112b18] 55         push ebp
>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>>> [000019d8][00112b10][000019d2] 50         push eax         // push E
>>> [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
>>> [000019dc][00112b0c][000019d2] 51         push ecx         // push E
>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    // call H
>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>
>>> H correctly reports that E correctly simulated by H cannot possibly
>>> reach its own final state at machine address [000019e6] and terminate
>>> normally in 1 to ∞ steps of correct simulation.
>>>
>>>
>>
>> So you are just admitting you don't understand the Halting Criteria.
>>
>> The fact that H stops its simulation before it gets to the end does
>> NOT prove that the machine being simulated, or a correct and complete
>> simultion of the input would be non-halting.
> We must handle only one point at a time because you are easily
> overwhelmed. You usually cannot even handle one point at a time until
> this point is repeated 20 or more times.
>
> The fact that the line-by-line execution trace of the first seven
> instructions E simulated by H exactly match the behavior specified by
> the first seven instructions of the x86 source-code of E conclusively
> proves that these first seven instructions are simulated correctly.
>


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<SFRbL.11595$o6Z5.1202@fx07.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx07.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.2
Subject: Re: Simulating halt decider applied to a simpler input
Content-Language: en-US
Newsgroups: comp.theory,sci.logic
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
<6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me>
<_9RbL.5611$gBW5.2085@fx06.iad> <20221112181916.000042d0@reddwarf.jmc.corp>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <20221112181916.000042d0@reddwarf.jmc.corp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 335
Message-ID: <SFRbL.11595$o6Z5.1202@fx07.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: Sat, 12 Nov 2022 13:33:18 -0500
X-Received-Bytes: 16830
 by: Richard Damon - Sat, 12 Nov 2022 18:33 UTC

On 11/12/22 1:19 PM, Mr Flibble wrote:
> On Sat, 12 Nov 2022 12:59:18 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 11/12/22 12:00 PM, olcott wrote:
>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>
>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked
>>>>>>>>>>>>>>>>>>>>>> you and I would have thought given your
>>>>>>>>>>>>>>>>>>>>>> intelligence you would also understand that.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>> mostly ignores me.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he
>>>>>>>>>>>>>>>>>>>>> has blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to
>>>>>>>>>>>>>>>>>>>>> point out his errors.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the
>>>>>>>>>>>>>>>>>>>>> Truth.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that
>>>>>>>>>>>>>>>>>>>>> he doesn't actually know what he is talking
>>>>>>>>>>>>>>>>>>>>> about, and reveals his ignorance. If he tries to
>>>>>>>>>>>>>>>>>>>>> put his explanation into explicit words, his
>>>>>>>>>>>>>>>>>>>>> errors become very apparent, I think even to him,
>>>>>>>>>>>>>>>>>>>>> so he just refuses.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet
>>>>>>>>>>>>>>>>>>>> naive readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
>>>>>>>>>>>>>>>>>>> Halting Decider.
>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>> Turing machine (UTM) knows that the behavior of D
>>>>>>>>>>>>>>>>>> correctly simulated by H provides H with a correct
>>>>>>>>>>>>>>>>>> basis for its halt status decision.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>> infinite execution of E is correct to report
>>>>>>>>>>>>>>>> non-halting. No shell game can correctly deny this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
>>>>>>>>>>>>>>> because the CORRECT simulation, as will the diret
>>>>>>>>>>>>>>> exectuion, will halt. Note, such an H doesn't do a
>>>>>>>>>>>>>>> correct simulation, so any arguement based on it doing
>>>>>>>>>>>>>>> so it just WRONG.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>> reference category error present in the proof; what
>>>>>>>>>>>>>> Olcott is getting wrong is the mapping of the need to
>>>>>>>>>>>>>> abort the simulation to a halt decision of non-halting;
>>>>>>>>>>>>>> it needs to instead be mapped to INVALID INPUT.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>
>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding it,
>>>>>>>>>>>>> not a "reference" to it. Turing Machines do not have the
>>>>>>>>>>>>> power to directly express a reference.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
>>>>>>>>>>>> copies all the way down so is the same category error
>>>>>>>>>>>> manifesting in a different way.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> Only if the "decider" makes that happen, in which case it
>>>>>>>>>>> isn't actually a decider.
>>>>>>>>>>>
>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>> "Impossible" program is simple to make from it, and is
>>>>>>>>>>> given one copy of the description of itself, which is also
>>>>>>>>>>> simple to make.
>>>>>>>>>>>
>>>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>>>> calls the decider.
>>>>>>>>>>>
>>>>>>>>>>> After that, it is the deciders job to make the decision in
>>>>>>>>>>> finite time, by whatever method it wants. If it gets stuck
>>>>>>>>>>> in your infinite loop, the decider is just wrong.
>>>>>>>>>>>
>>>>>>>>>>> The proof shows that what ever answer the decider does give
>>>>>>>>>>> (if it gives one) will be wrong, and thus the decider
>>>>>>>>>>> doesn't meet the requirements.
>>>>>>>>>>>
>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>> given a copy of something that just happens to be its own
>>>>>>>>>>> description.
>>>>>>>>>>>
>>>>>>>>>>> The only place we get any form of "Reference", is when we
>>>>>>>>>>> try to ANALYSE or DESIGN the H to try to meet the
>>>>>>>>>>> challenge. There the effect of the Self-Reference just lets
>>>>>>>>>>> us see that the task turns out be be impossible, so no such
>>>>>>>>>>> program exists.
>>>>>>>>>>
>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>> halting problem proofs based on [Strachey 1965] the program
>>>>>>>>>> is impossible not due to self reference or infinite copies
>>>>>>>>>> but because the input tries to do the opposite of what the
>>>>>>>>>> decider decides; the category error that I have identified
>>>>>>>>>> is different: it is an error of self reference and/or
>>>>>>>>>> infinite copies; it is an error related to the fact that the
>>>>>>>>>> input references a decider rather than being related to what
>>>>>>>>>> the input does with the decision result of a decider.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
>>>>>>>>> handle ANY input and answer in finite time, If an input
>>>>>>>>> causes it to make infinite copies, then the decided just
>>>>>>>>> doesn't meet its requirements.
>>>>>>>>>
>>>>>>>>> Turing Machine can ALWAYS be legally built based on another
>>>>>>>>> Turing Machine as a base. The only reason it wouldn't be
>>>>>>>>> allowed is if H isn't actually a Turing Machine, so it CAN'T
>>>>>>>>> be a category error if H is actualy a Turing Machine.
>>>>>>>>>
>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>> admitting that your H can't actually be a Turing Machine, but
>>>>>>>>> must be of a HIGHER order logic system, which means H fails
>>>>>>>>> the requirement to be the needed decider.
>>>>>>>>
>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>> down: yet another manifestation of the category error I have
>>>>>>>> identified.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>> either H or D, and it SIMULATING others, and if we get an
>>>>>>> infinite sequence of simulations we have just shown that H was
>>>>>>> defective because it failed to answer in finite time.
>>>>>>>
>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>
>>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>>> representation on the tape, and two is much smaller than
>>>>>>> infinity.
>>>>>>
>>>>>> Nope, if,
>>>>>>
>>>>>> a) H is a copy, and
>>>>>> b) H is a Turing Machine, and
>>>>>> c) D is an input into H, and
>>>>>> d) D references H, and
>>>>>> e) H references D,
>>>>>>
>>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>>> Machines all the way down: a manifestation of the category error
>>>>>> I have identified.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> void E(void (*x)())
>>>>> {
>>>>>    H(x, x);
>>>>> }
>>>>>
>>>>> The point is
>>>>> that D correctly simulated by H would never reach its own last
>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>> simulation.
>>>>>
>>>>> When H returns 0 to main() it is indicating
>>>>>
>>>>> that D correctly simulated by H would never reach its own last
>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>> simulation.
>>>>>
>>>>
>>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>>> statement. When it is correctly simulated by something other than
>>>> H, it will come to a final state, showing your statement is wrong.
>>>>
>>> In order for the simulation to actually be incorrect the execution
>>> trace of the simulated E must diverge from the behavior that the
>>> line-by-line x86 source-code of E specifies.
>>
>> Right, and since you simulation does NOT continue past the call to H,
>> it is "incorrect" in the sense that the actual code does continue
>> past that point, so it does not actually match the behavior of that
>> machine.
>>
>>>
>>> The first seven lines of the execution trace of the simulated E
>>> exactly match the behavior specified by the first seven lines of
>>> the x86 source code of E. This conclusively proves beyond all
>>> possible doubt that these first seven lines have been simulated
>>> correctly.
>>
>> Right, so H has correctly done a PARTIAL simulation of its input,
>> which does NOT prove the input is non-halting.
>>
>>>
>>> *H correctly determines that E never halts*
>>>
>>> void E(void (*x)())
>>> {
>>>   H(x, x);
>>> }
>>>
>>>
>>> int main()
>>> {
>>>   Output("Input_Halts = ", H(E, E));
>>> }
>>>
>>> _E()
>>> [000019d2] 55             push ebp
>>> [000019d3] 8bec           mov ebp,esp
>>> [000019d5] 8b4508         mov eax,[ebp+08]
>>> [000019d8] 50             push eax
>>> [000019d9] 8b4d08         mov ecx,[ebp+08]
>>> [000019dc] 51             push ecx
>>> [000019dd] e8b0f9ffff     call 00001392
>>> [000019e2] 83c408         add esp,+08
>>> [000019e5] 5d             pop ebp
>>> [000019e6] c3             ret
>>> Size in bytes:(0021) [000019e6]
>>>
>>> _main()
>>> [000019f2] 55             push ebp
>>> [000019f3] 8bec           mov ebp,esp
>>> [000019f5] 68d2190000     push 000019d2
>>> [000019fa] 68d2190000     push 000019d2
>>> [000019ff] e88ef9ffff     call 00001392
>>> [00001a04] 83c408         add esp,+08
>>> [00001a07] 50             push eax
>>> [00001a08] 6893060000     push 00000693
>>> [00001a0d] e8a0ecffff     call 000006b2
>>> [00001a12] 83c408         add esp,+08
>>> [00001a15] 33c0           xor eax,eax
>>> [00001a17] 5d             pop ebp
>>> [00001a18] c3             ret
>>> Size in bytes:(0039) [00001a18]
>>>
>>>  machine   stack     stack     machine    assembly
>>>  address   address   data      code       language
>>>  ========  ========  ========  =========  =============
>>> [000019f2][00102a7c][00000000] 55         push ebp
>>> [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>
>>> H: Begin Simulation   Execution Trace Stored at:112b28
>>> Address_of_H:1392
>>> [000019d2][00112b14][00112b18] 55         push ebp
>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>>> [000019d8][00112b10][000019d2] 50         push eax         // push E
>>> [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
>>> [000019dc][00112b0c][000019d2] 51         push ecx         // push E
>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    // call H
>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>
>>> H correctly reports that E correctly simulated by H cannot possibly
>>> reach its own final state at machine address [000019e6] and
>>> terminate normally in 1 to ∞ steps of correct simulation.
>>>
>>>
>>
>> So you are just admitting you don't understand the Halting Criteria.
>>
>> The fact that H stops its simulation before it gets to the end does
>> NOT prove that the machine being simulated, or a correct and complete
>> simultion of the input would be non-halting.
>>
>> Or, do you claim that you have correctly climbed Mount Everest since
>> ever step of you climb of it were correct?
>>
>> You are just proving you lack of understanding of the meaning of a
>> correct simulation.
>
> Olcott is correct and you are incorrect: you don't seem to understand
> what an (infinitely) recursive function actually entails.
>
> /Flibble
>


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<20221112184207.000004d1@reddwarf.jmc.corp>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Date: Sat, 12 Nov 2022 18:42:07 +0000
From: flib...@reddwarf.jmc.corp (Mr Flibble)
Newsgroups: comp.theory,sci.logic
Subject: Re: Simulating halt decider applied to a simpler input
Message-ID: <20221112184207.000004d1@reddwarf.jmc.corp>
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad> <20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad> <tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad> <tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad> <tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad> <20221111215433.00005425@reddwarf.jmc.corp> <dSAbL.106246$U709.51175@fx16.iad> <20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad> <20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad> <20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad> <20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me> <6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me> <_9RbL.5611$gBW5.2085@fx06.iad> <tkonum$17cpp$1@dont-email.me> <7xRbL.11594$o6Z5.1319@fx07.iad>
Organization: NewsDemon - www.newsdemon.com
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Lines: 388
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder.usenetexpress.com!tr1.eu1.usenetexpress.com!news.newsdemon.com!not-for-mail
NNTP-Posting-Date: Sat, 12 Nov 2022 18:42:07 +0000
X-Received-Bytes: 19509
X-Complaints-To: abuse@newsdemon.com
 by: Mr Flibble - Sat, 12 Nov 2022 18:42 UTC

On Sat, 12 Nov 2022 13:24:00 -0500
Richard Damon <Richard@Damon-Family.org> wrote:

> On 11/12/22 1:16 PM, olcott wrote:
> > On 11/12/2022 11:59 AM, Richard Damon wrote:
> >> On 11/12/22 12:00 PM, olcott wrote:
> >>> On 11/12/2022 10:26 AM, Richard Damon wrote:
> >>>> On 11/12/22 10:50 AM, olcott wrote:
> >>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
> >>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
> >>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>
> >>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
> >>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
> >>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
> >>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
> >>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
> >>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
> >>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
> >>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked
> >>>>>>>>>>>>>>>>>>>>>> you and I would have thought given your
> >>>>>>>>>>>>>>>>>>>>>> intelligence you would also understand that.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
> >>>>>>>>>>>>>>>>>>>>> mostly ignores me.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond
> >>>>>>>>>>>>>>>>>>>>> to what I say, even if not in a direct reply,
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he
> >>>>>>>>>>>>>>>>>>>>> has blocked me, he will still see me.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into
> >>>>>>>>>>>>>>>>>>>>> the archives, I want enough evidence to be
> >>>>>>>>>>>>>>>>>>>>> around to point out his errors.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know
> >>>>>>>>>>>>>>>>>>>>> and provide reasoning behind the claims,
> >>>>>>>>>>>>>>>>>>>>> showing the Truth.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
> >>>>>>>>>>>>>>>>>>>>> that he doesn't actually know what he is
> >>>>>>>>>>>>>>>>>>>>> talking about, and reveals his ignorance. If he
> >>>>>>>>>>>>>>>>>>>>> tries to put his explanation into explicit
> >>>>>>>>>>>>>>>>>>>>> words, his errors become very apparent, I think
> >>>>>>>>>>>>>>>>>>>>> even to him, so he just refuses.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your
> >>>>>>>>>>>>>>>>>>>> only basis. Naive readers will never notice
> >>>>>>>>>>>>>>>>>>>> this, yet naive readers are not in my target
> >>>>>>>>>>>>>>>>>>>> audience.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
> >>>>>>>>>>>>>>>>>>> Halting Decider.
> >>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
> >>>>>>>>>>>>>>>>>> Turing machine (UTM) knows that the behavior of D
> >>>>>>>>>>>>>>>>>> correctly simulated by H provides H with a correct
> >>>>>>>>>>>>>>>>>> basis for its halt status decision.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> void E(void (*x)())
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>         H(x, x);
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
> >>>>>>>>>>>>>>>> infinite
> >>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
> >>>>>>>>>>>>>>>> shell game can correctly deny this.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
> >>>>>>>>>>>>>>> because the CORRECT simulation, as will the diret
> >>>>>>>>>>>>>>> exectuion, will halt. Note, such an H doesn't do a
> >>>>>>>>>>>>>>> correct simulation, so any
> >>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The need to abort the simulation is due to the self
> >>>>>>>>>>>>>> reference category error present in the proof; what
> >>>>>>>>>>>>>> Olcott is getting wrong is the mapping of the need to
> >>>>>>>>>>>>>> abort the simulation to a halt decision of
> >>>>>>>>>>>>>> non-halting; it needs to instead be mapped to
> >>>>>>>>>>>>>> INVALID INPUT.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Nope, no self reference.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
> >>>>>>>>>>>>> it, not a "reference" to it. Turing Machines do not
> >>>>>>>>>>>>> have the power to directly express a reference.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
> >>>>>>>>>>>> copies all the way down so is the same category error
> >>>>>>>>>>>> manifesting in a different way.
> >>>>>>>>>>>>
> >>>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>> Only if the "decider" makes that happen, in which case it
> >>>>>>>>>>> isn't actually a decider.
> >>>>>>>>>>>
> >>>>>>>>>>> If we assume a prospective decider exists, then the
> >>>>>>>>>>> "Impossible" program is simple to make from it, and is
> >>>>>>>>>>> given one copy of the description of itself, which is
> >>>>>>>>>>> also simple to make.
> >>>>>>>>>>>
> >>>>>>>>>>> When run it makes a second copy of its description, and
> >>>>>>>>>>> then calls the decider.
> >>>>>>>>>>>
> >>>>>>>>>>> After that, it is the deciders job to make the decision
> >>>>>>>>>>> in finite
> >>>>>>>>>>> time, by whatever method it wants. If it gets stuck in
> >>>>>>>>>>> your infinite loop, the decider is just wrong.
> >>>>>>>>>>>
> >>>>>>>>>>> The proof shows that what ever answer the decider does
> >>>>>>>>>>> give (if it gives one) will be wrong, and thus the
> >>>>>>>>>>> decider doesn't meet the requirements.
> >>>>>>>>>>>
> >>>>>>>>>>> No "Self Reference" in sight there only a program being
> >>>>>>>>>>> given a copy of something that just happens to be its own
> >>>>>>>>>>> description.
> >>>>>>>>>>>
> >>>>>>>>>>> The only place we get any form of "Reference", is when we
> >>>>>>>>>>> try to ANALYSE or DESIGN the H to try to meet the
> >>>>>>>>>>> challenge. There the effect of the Self-Reference just
> >>>>>>>>>>> lets us see that the task turns
> >>>>>>>>>>> out be be impossible, so no such program exists.
> >>>>>>>>>>
> >>>>>>>>>> You are fractally wrong on all fronts: in the traditional
> >>>>>>>>>> halting problem proofs based on [Strachey 1965] the
> >>>>>>>>>> program is impossible not due to self reference or
> >>>>>>>>>> infinite copies but because the input
> >>>>>>>>>> tries to do the opposite of what the decider decides; the
> >>>>>>>>>> category
> >>>>>>>>>> error that I have identified is different: it is an error
> >>>>>>>>>> of self reference and/or infinite copies; it is an error
> >>>>>>>>>> related to the fact that the input references a decider
> >>>>>>>>>> rather than being related
> >>>>>>>>>> to what the input does with the decision result of a
> >>>>>>>>>> decider.
> >>>>>>>>>>
> >>>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>> But the infinite copies is a error in the Decider, not in
> >>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
> >>>>>>>>> handle ANY input and answer in finite time, If an input
> >>>>>>>>> causes it to make infinite copies, then the decided just
> >>>>>>>>> doesn't meet its requirements.
> >>>>>>>>>
> >>>>>>>>> Turing Machine can ALWAYS be legally built based on another
> >>>>>>>>> Turing Machine as a base. The only reason it wouldn't be
> >>>>>>>>> allowed is if H isn't actually a Turing Machine, so it
> >>>>>>>>> CAN'T be a category error if H is actualy a Turing Machine.
> >>>>>>>>>
> >>>>>>>>> All your declaration of a "Category Error" here is doing is
> >>>>>>>>> admitting that your H can't actually be a Turing Machine,
> >>>>>>>>> but must be of a HIGHER order logic system, which means H
> >>>>>>>>> fails the requirement to be the needed decider.
> >>>>>>>>
> >>>>>>>> In which case we get infinite turning machines all the way
> >>>>>>>> down: yet
> >>>>>>>> another manifestation of the category error I have
> >>>>>>>> identified.
> >>>>>>>>
> >>>>>>>> /Flibble
> >>>>>>>
> >>>>>>> Where are infinite machines? There is ONE machine being run,
> >>>>>>> either H
> >>>>>>> or D, and it SIMULATING others, and if we get an infinite
> >>>>>>> sequence of
> >>>>>>> simulations we have just shown that H was defective because
> >>>>>>> it failed
> >>>>>>> to answer in finite time.
> >>>>>>>
> >>>>>>> This isn't a category error, but a design error in H.
> >>>>>>>
> >>>>>>> Note, when we start H, there is exactly two machines present
> >>>>>>> in representation on the tape, and two is much smaller than
> >>>>>>> infinity.
> >>>>>>
> >>>>>> Nope, if,
> >>>>>>
> >>>>>> a) H is a copy, and
> >>>>>> b) H is a Turing Machine, and
> >>>>>> c) D is an input into H, and
> >>>>>> d) D references H, and
> >>>>>> e) H references D,
> >>>>>>
> >>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
> >>>>>> Machines
> >>>>>> all the way down: a manifestation of the category error I have
> >>>>>> identified.
> >>>>>>
> >>>>>> /Flibble
> >>>>>>
> >>>>>
> >>>>> void E(void (*x)())
> >>>>> {
> >>>>>    H(x, x);
> >>>>> }
> >>>>>
> >>>>> The point is
> >>>>> that D correctly simulated by H would never reach its own last
> >>>>> instruction and terminate normally after 1 to ∞ steps of
> >>>>> correct simulation.
> >>>>>
> >>>>> When H returns 0 to main() it is indicating
> >>>>>
> >>>>> that D correctly simulated by H would never reach its own last
> >>>>> instruction and terminate normally after 1 to ∞ steps of
> >>>>> correct simulation.
> >>>>>
> >>>>
> >>>> Except D is NOT correctly simulated by H, so that is a incorrect
> >>>> statement. When it is correctly simulated by something other
> >>>> than H, it will come to a final state, showing your statement is
> >>>> wrong.
> >>> In order for the simulation to actually be incorrect the
> >>> execution trace of the simulated E must diverge from the behavior
> >>> that the line-by-line x86 source-code of E specifies.
> >>
> >> Right, and since you simulation does NOT continue past the call to
> >> H, it is "incorrect" in the sense that the actual code does
> >> continue past that point, so it does not actually match the
> >> behavior of that machine.
> >>>
> >>> The first seven lines of the execution trace of the simulated E
> >>> exactly match the behavior specified by the first seven lines of
> >>> the x86 source code of E. This conclusively proves beyond all
> >>> possible doubt that these first seven lines have been simulated
> >>> correctly.
> >>
> >> Right, so H has correctly done a PARTIAL simulation of its input,
> >> which does NOT prove the input is non-halting.
> >>
> >>>
> >>> *H correctly determines that E never halts*
> >>>
> >>> void E(void (*x)())
> >>> {
> >>>    H(x, x);
> >>> }
> >>>
> >>>
> >>> int main()
> >>> {
> >>>    Output("Input_Halts = ", H(E, E));
> >>> }
> >>>
> >>> _E()
> >>> [000019d2] 55             push ebp
> >>> [000019d3] 8bec           mov ebp,esp
> >>> [000019d5] 8b4508         mov eax,[ebp+08]
> >>> [000019d8] 50             push eax
> >>> [000019d9] 8b4d08         mov ecx,[ebp+08]
> >>> [000019dc] 51             push ecx
> >>> [000019dd] e8b0f9ffff     call 00001392
> >>> [000019e2] 83c408         add esp,+08
> >>> [000019e5] 5d             pop ebp
> >>> [000019e6] c3             ret
> >>> Size in bytes:(0021) [000019e6]
> >>>
> >>> _main()
> >>> [000019f2] 55             push ebp
> >>> [000019f3] 8bec           mov ebp,esp
> >>> [000019f5] 68d2190000     push 000019d2
> >>> [000019fa] 68d2190000     push 000019d2
> >>> [000019ff] e88ef9ffff     call 00001392
> >>> [00001a04] 83c408         add esp,+08
> >>> [00001a07] 50             push eax
> >>> [00001a08] 6893060000     push 00000693
> >>> [00001a0d] e8a0ecffff     call 000006b2
> >>> [00001a12] 83c408         add esp,+08
> >>> [00001a15] 33c0           xor eax,eax
> >>> [00001a17] 5d             pop ebp
> >>> [00001a18] c3             ret
> >>> Size in bytes:(0039) [00001a18]
> >>>
> >>>   machine   stack     stack     machine    assembly
> >>>   address   address   data      code       language
> >>>   ========  ========  ========  =========  ============> >>> [000019f2][00102a7c][00000000] 55         push ebp
> >>> [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
> >>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
> >>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
> >>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
> >>>
> >>> H: Begin Simulation   Execution Trace Stored at:112b28
> >>> Address_of_H:1392
> >>> [000019d2][00112b14][00112b18] 55         push ebp
> >>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
> >>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
> >>> [000019d8][00112b10][000019d2] 50         push eax         //
> >>> push E [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
> >>> [000019dc][00112b0c][000019d2] 51         push ecx         //
> >>> push E [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392
> >>> // call H H: Infinitely Recursive Simulation Detected Simulation
> >>> Stopped
> >>>
> >>> H correctly reports that E correctly simulated by H cannot
> >>> possibly reach its own final state at machine address [000019e6]
> >>> and terminate normally in 1 to ∞ steps of correct simulation.
> >>>
> >>>
> >>
> >> So you are just admitting you don't understand the Halting
> >> Criteria.
> >>
> >> The fact that H stops its simulation before it gets to the end
> >> does NOT prove that the machine being simulated, or a correct and
> >> complete simultion of the input would be non-halting.
> > We must handle only one point at a time because you are easily
> > overwhelmed. You usually cannot even handle one point at a time
> > until this point is repeated 20 or more times.
> >
> > The fact that the line-by-line execution trace of the first seven
> > instructions E simulated by H exactly match the behavior specified
> > by the first seven instructions of the x86 source-code of E
> > conclusively proves that these first seven instructions are
> > simulated correctly.
>
> No, that says that H did a correct PARTIAL simulation of the input.
> You seem to be INTENTIONALLY using deceptive terminology to spread
> you lies.
>
> So, I suppose you can correctly say that the input doesn't stop
> within its first 7 instructions, but that doesn't mean anything.
>
> Since you make a claim about a COMPLETE simulation (the it will never
> end) you need to establish THAT fact (and you can't change the input
> to do it, which includes the H the E calls).
>
> YOU FAIL
>
> You show that you don't understand what you are talking about and
> seem to actually think that you are proving something by using wrong
> defintions.
>
> You are just showing how stupid you are.


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<tkopjk$fah$1@gioia.aioe.org>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!aioe.org!/maIWMVc/1untnACPzZ7XA.user.46.165.242.91.POSTED!not-for-mail
From: none...@beez-waxes.com (olcott)
Newsgroups: comp.theory,sci.logic
Subject: Re: Simulating halt decider applied to a simpler input
Date: Sat, 12 Nov 2022 12:45:07 -0600
Organization: Aioe.org NNTP Server
Message-ID: <tkopjk$fah$1@gioia.aioe.org>
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
<6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me>
<_9RbL.5611$gBW5.2085@fx06.iad> <tkonum$17cpp$1@dont-email.me>
<7xRbL.11594$o6Z5.1319@fx07.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="15697"; posting-host="/maIWMVc/1untnACPzZ7XA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.4.2
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.9.2
 by: olcott - Sat, 12 Nov 2022 18:45 UTC

On 11/12/2022 12:24 PM, Richard Damon wrote:
> On 11/12/22 1:16 PM, olcott wrote:
>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>> On 11/12/22 12:00 PM, olcott wrote:
>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>
>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to
>>>>>>>>>>>>>>>>>>>>>> point
>>>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the
>>>>>>>>>>>>>>>>>>>>>> Truth.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation,
>>>>>>>>>>>>>>>> so any
>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>>>>>>> wrong is the mapping of the need to abort the simulation
>>>>>>>>>>>>>>> to a
>>>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be
>>>>>>>>>>>>>>> mapped to
>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding it,
>>>>>>>>>>>>>> not a
>>>>>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>>>>>>> all the way down so is the same category error manifesting
>>>>>>>>>>>>> in a
>>>>>>>>>>>>> different way.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>>>>>>> actually a decider.
>>>>>>>>>>>>
>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>> "Impossible"
>>>>>>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>>>
>>>>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>>>>> calls the decider.
>>>>>>>>>>>>
>>>>>>>>>>>> After that, it is the deciders job to make the decision in
>>>>>>>>>>>> finite
>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>
>>>>>>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>>>>>>> copy of something that just happens to be its own description.
>>>>>>>>>>>>
>>>>>>>>>>>> The only place we get any form of "Reference", is when we
>>>>>>>>>>>> try to
>>>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>>>>>>> effect of the Self-Reference just lets us see that the task
>>>>>>>>>>>> turns
>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>
>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>> halting
>>>>>>>>>>> problem proofs based on [Strachey 1965] the program is
>>>>>>>>>>> impossible
>>>>>>>>>>> not due to self reference or infinite copies but because the
>>>>>>>>>>> input
>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>> category
>>>>>>>>>>> error that I have identified is different: it is an error of
>>>>>>>>>>> self
>>>>>>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>>>>>>> fact that the input references a decider rather than being
>>>>>>>>>>> related
>>>>>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>>>>>>> ANY input and answer in finite time, If an input causes it to
>>>>>>>>>> make
>>>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>>>> requirements.
>>>>>>>>>>
>>>>>>>>>> Turing Machine can ALWAYS be legally built based on another
>>>>>>>>>> Turing
>>>>>>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>>>
>>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>>> admitting that your H can't actually be a Turing Machine, but
>>>>>>>>>> must
>>>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>>>> requirement to be the needed decider.
>>>>>>>>>
>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>> down: yet
>>>>>>>>> another manifestation of the category error I have identified.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>> either H
>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>> sequence of
>>>>>>>> simulations we have just shown that H was defective because it
>>>>>>>> failed
>>>>>>>> to answer in finite time.
>>>>>>>>
>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>
>>>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>>>> representation on the tape, and two is much smaller than infinity.
>>>>>>>
>>>>>>> Nope, if,
>>>>>>>
>>>>>>> a) H is a copy, and
>>>>>>> b) H is a Turing Machine, and
>>>>>>> c) D is an input into H, and
>>>>>>> d) D references H, and
>>>>>>> e) H references D,
>>>>>>>
>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>>>> Machines
>>>>>>> all the way down: a manifestation of the category error I have
>>>>>>> identified.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> void E(void (*x)())
>>>>>> {
>>>>>>    H(x, x);
>>>>>> }
>>>>>>
>>>>>> The point is
>>>>>> that D correctly simulated by H would never reach its own last
>>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>>> simulation.
>>>>>>
>>>>>> When H returns 0 to main() it is indicating
>>>>>>
>>>>>> that D correctly simulated by H would never reach its own last
>>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>>> simulation.
>>>>>>
>>>>>
>>>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>>>> statement. When it is correctly simulated by something other than
>>>>> H, it will come to a final state, showing your statement is wrong.
>>>> In order for the simulation to actually be incorrect the execution
>>>> trace of the simulated E must diverge from the behavior that the
>>>> line-by-line x86 source-code of E specifies.
>>>
>>> Right, and since you simulation does NOT continue past the call to H,
>>> it is "incorrect" in the sense that the actual code does continue
>>> past that point, so it does not actually match the behavior of that
>>> machine.
>>>
>>>>
>>>> The first seven lines of the execution trace of the simulated E
>>>> exactly match the behavior specified by the first seven lines of the
>>>> x86 source code of E. This conclusively proves beyond all possible
>>>> doubt that these first seven lines have been simulated correctly.
>>>
>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>> which does NOT prove the input is non-halting.
>>>
>>>>
>>>> *H correctly determines that E never halts*
>>>>
>>>> void E(void (*x)())
>>>> {
>>>>    H(x, x);
>>>> }
>>>>
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H(E, E));
>>>> }
>>>>
>>>> _E()
>>>> [000019d2] 55             push ebp
>>>> [000019d3] 8bec           mov ebp,esp
>>>> [000019d5] 8b4508         mov eax,[ebp+08]
>>>> [000019d8] 50             push eax
>>>> [000019d9] 8b4d08         mov ecx,[ebp+08]
>>>> [000019dc] 51             push ecx
>>>> [000019dd] e8b0f9ffff     call 00001392
>>>> [000019e2] 83c408         add esp,+08
>>>> [000019e5] 5d             pop ebp
>>>> [000019e6] c3             ret
>>>> Size in bytes:(0021) [000019e6]
>>>>
>>>> _main()
>>>> [000019f2] 55             push ebp
>>>> [000019f3] 8bec           mov ebp,esp
>>>> [000019f5] 68d2190000     push 000019d2
>>>> [000019fa] 68d2190000     push 000019d2
>>>> [000019ff] e88ef9ffff     call 00001392
>>>> [00001a04] 83c408         add esp,+08
>>>> [00001a07] 50             push eax
>>>> [00001a08] 6893060000     push 00000693
>>>> [00001a0d] e8a0ecffff     call 000006b2
>>>> [00001a12] 83c408         add esp,+08
>>>> [00001a15] 33c0           xor eax,eax
>>>> [00001a17] 5d             pop ebp
>>>> [00001a18] c3             ret
>>>> Size in bytes:(0039) [00001a18]
>>>>
>>>>   machine   stack     stack     machine    assembly
>>>>   address   address   data      code       language
>>>>   ========  ========  ========  =========  =============
>>>> [000019f2][00102a7c][00000000] 55         push ebp
>>>> [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>>
>>>> H: Begin Simulation   Execution Trace Stored at:112b28
>>>> Address_of_H:1392
>>>> [000019d2][00112b14][00112b18] 55         push ebp
>>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>>>> [000019d8][00112b10][000019d2] 50         push eax         // push E
>>>> [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
>>>> [000019dc][00112b0c][000019d2] 51         push ecx         // push E
>>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    // call H
>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>
>>>> H correctly reports that E correctly simulated by H cannot possibly
>>>> reach its own final state at machine address [000019e6] and
>>>> terminate normally in 1 to ∞ steps of correct simulation.
>>>>
>>>>
>>>
>>> So you are just admitting you don't understand the Halting Criteria.
>>>
>>> The fact that H stops its simulation before it gets to the end does
>>> NOT prove that the machine being simulated, or a correct and complete
>>> simultion of the input would be non-halting.
>> We must handle only one point at a time because you are easily
>> overwhelmed. You usually cannot even handle one point at a time until
>> this point is repeated 20 or more times.
>>
>> The fact that the line-by-line execution trace of the first seven
>> instructions E simulated by H exactly match the behavior specified by
>> the first seven instructions of the x86 source-code of E conclusively
>> proves that these first seven instructions are simulated correctly.
>>
>
> No, that says that H did a correct PARTIAL simulation of the input.


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<90SbL.14321$%VI9.7406@fx34.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx34.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.2
Subject: Re: Simulating halt decider applied to a simpler input
Content-Language: en-US
Newsgroups: comp.theory,sci.logic
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
<6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me>
<_9RbL.5611$gBW5.2085@fx06.iad> <tkonum$17cpp$1@dont-email.me>
<7xRbL.11594$o6Z5.1319@fx07.iad> <tkopjk$fah$1@gioia.aioe.org>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tkopjk$fah$1@gioia.aioe.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 414
Message-ID: <90SbL.14321$%VI9.7406@fx34.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: Sat, 12 Nov 2022 13:57:06 -0500
X-Received-Bytes: 20201
 by: Richard Damon - Sat, 12 Nov 2022 18:57 UTC

On 11/12/22 1:45 PM, olcott wrote:
> On 11/12/2022 12:24 PM, Richard Damon wrote:
>> On 11/12/22 1:16 PM, olcott wrote:
>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>
>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence
>>>>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to
>>>>>>>>>>>>>>>>>>>>>>> point
>>>>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the
>>>>>>>>>>>>>>>>>>>>>>> Truth.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet
>>>>>>>>>>>>>>>>>>>>>> naive
>>>>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation,
>>>>>>>>>>>>>>>>> so any
>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>>>>>>>> wrong is the mapping of the need to abort the simulation
>>>>>>>>>>>>>>>> to a
>>>>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be
>>>>>>>>>>>>>>>> mapped to
>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding it,
>>>>>>>>>>>>>>> not a
>>>>>>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>>>>>>>> all the way down so is the same category error manifesting
>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>> different way.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case it
>>>>>>>>>>>>> isn't
>>>>>>>>>>>>> actually a decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>> "Impossible"
>>>>>>>>>>>>> program is simple to make from it, and is given one copy of
>>>>>>>>>>>>> the
>>>>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>>>>>> calls the decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> After that, it is the deciders job to make the decision in
>>>>>>>>>>>>> finite
>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The proof shows that what ever answer the decider does give
>>>>>>>>>>>>> (if
>>>>>>>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>> given a
>>>>>>>>>>>>> copy of something that just happens to be its own description.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only place we get any form of "Reference", is when we
>>>>>>>>>>>>> try to
>>>>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There
>>>>>>>>>>>>> the
>>>>>>>>>>>>> effect of the Self-Reference just lets us see that the task
>>>>>>>>>>>>> turns
>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>
>>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>>> halting
>>>>>>>>>>>> problem proofs based on [Strachey 1965] the program is
>>>>>>>>>>>> impossible
>>>>>>>>>>>> not due to self reference or infinite copies but because the
>>>>>>>>>>>> input
>>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>>> category
>>>>>>>>>>>> error that I have identified is different: it is an error of
>>>>>>>>>>>> self
>>>>>>>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>>>>>>>> fact that the input references a decider rather than being
>>>>>>>>>>>> related
>>>>>>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>>>>>>>> ANY input and answer in finite time, If an input causes it to
>>>>>>>>>>> make
>>>>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>>>>> requirements.
>>>>>>>>>>>
>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on another
>>>>>>>>>>> Turing
>>>>>>>>>>> Machine as a base. The only reason it wouldn't be allowed is
>>>>>>>>>>> if H
>>>>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>>>>
>>>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>>>> admitting that your H can't actually be a Turing Machine, but
>>>>>>>>>>> must
>>>>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>>>>> requirement to be the needed decider.
>>>>>>>>>>
>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>> down: yet
>>>>>>>>>> another manifestation of the category error I have identified.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>>> either H
>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>> sequence of
>>>>>>>>> simulations we have just shown that H was defective because it
>>>>>>>>> failed
>>>>>>>>> to answer in finite time.
>>>>>>>>>
>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>
>>>>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>>>>> representation on the tape, and two is much smaller than infinity.
>>>>>>>>
>>>>>>>> Nope, if,
>>>>>>>>
>>>>>>>> a) H is a copy, and
>>>>>>>> b) H is a Turing Machine, and
>>>>>>>> c) D is an input into H, and
>>>>>>>> d) D references H, and
>>>>>>>> e) H references D,
>>>>>>>>
>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>>>>> Machines
>>>>>>>> all the way down: a manifestation of the category error I have
>>>>>>>> identified.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> void E(void (*x)())
>>>>>>> {
>>>>>>>    H(x, x);
>>>>>>> }
>>>>>>>
>>>>>>> The point is
>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>>>> simulation.
>>>>>>>
>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>
>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>>>> simulation.
>>>>>>>
>>>>>>
>>>>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>>>>> statement. When it is correctly simulated by something other than
>>>>>> H, it will come to a final state, showing your statement is wrong.
>>>>> In order for the simulation to actually be incorrect the execution
>>>>> trace of the simulated E must diverge from the behavior that the
>>>>> line-by-line x86 source-code of E specifies.
>>>>
>>>> Right, and since you simulation does NOT continue past the call to
>>>> H, it is "incorrect" in the sense that the actual code does continue
>>>> past that point, so it does not actually match the behavior of that
>>>> machine.
>>>>
>>>>>
>>>>> The first seven lines of the execution trace of the simulated E
>>>>> exactly match the behavior specified by the first seven lines of
>>>>> the x86 source code of E. This conclusively proves beyond all
>>>>> possible doubt that these first seven lines have been simulated
>>>>> correctly.
>>>>
>>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>>> which does NOT prove the input is non-halting.
>>>>
>>>>>
>>>>> *H correctly determines that E never halts*
>>>>>
>>>>> void E(void (*x)())
>>>>> {
>>>>>    H(x, x);
>>>>> }
>>>>>
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H(E, E));
>>>>> }
>>>>>
>>>>> _E()
>>>>> [000019d2] 55             push ebp
>>>>> [000019d3] 8bec           mov ebp,esp
>>>>> [000019d5] 8b4508         mov eax,[ebp+08]
>>>>> [000019d8] 50             push eax
>>>>> [000019d9] 8b4d08         mov ecx,[ebp+08]
>>>>> [000019dc] 51             push ecx
>>>>> [000019dd] e8b0f9ffff     call 00001392
>>>>> [000019e2] 83c408         add esp,+08
>>>>> [000019e5] 5d             pop ebp
>>>>> [000019e6] c3             ret
>>>>> Size in bytes:(0021) [000019e6]
>>>>>
>>>>> _main()
>>>>> [000019f2] 55             push ebp
>>>>> [000019f3] 8bec           mov ebp,esp
>>>>> [000019f5] 68d2190000     push 000019d2
>>>>> [000019fa] 68d2190000     push 000019d2
>>>>> [000019ff] e88ef9ffff     call 00001392
>>>>> [00001a04] 83c408         add esp,+08
>>>>> [00001a07] 50             push eax
>>>>> [00001a08] 6893060000     push 00000693
>>>>> [00001a0d] e8a0ecffff     call 000006b2
>>>>> [00001a12] 83c408         add esp,+08
>>>>> [00001a15] 33c0           xor eax,eax
>>>>> [00001a17] 5d             pop ebp
>>>>> [00001a18] c3             ret
>>>>> Size in bytes:(0039) [00001a18]
>>>>>
>>>>>   machine   stack     stack     machine    assembly
>>>>>   address   address   data      code       language
>>>>>   ========  ========  ========  =========  =============
>>>>> [000019f2][00102a7c][00000000] 55         push ebp
>>>>> [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>>>
>>>>> H: Begin Simulation   Execution Trace Stored at:112b28
>>>>> Address_of_H:1392
>>>>> [000019d2][00112b14][00112b18] 55         push ebp
>>>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>>>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>>>>> [000019d8][00112b10][000019d2] 50         push eax         // push E
>>>>> [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
>>>>> [000019dc][00112b0c][000019d2] 51         push ecx         // push E
>>>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    // call H
>>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>
>>>>> H correctly reports that E correctly simulated by H cannot possibly
>>>>> reach its own final state at machine address [000019e6] and
>>>>> terminate normally in 1 to ∞ steps of correct simulation.
>>>>>
>>>>>
>>>>
>>>> So you are just admitting you don't understand the Halting Criteria.
>>>>
>>>> The fact that H stops its simulation before it gets to the end does
>>>> NOT prove that the machine being simulated, or a correct and
>>>> complete simultion of the input would be non-halting.
>>> We must handle only one point at a time because you are easily
>>> overwhelmed. You usually cannot even handle one point at a time until
>>> this point is repeated 20 or more times.
>>>
>>> The fact that the line-by-line execution trace of the first seven
>>> instructions E simulated by H exactly match the behavior specified by
>>> the first seven instructions of the x86 source-code of E conclusively
>>> proves that these first seven instructions are simulated correctly.
>>>
>>
>> No, that says that H did a correct PARTIAL simulation of the input.
>
> Yes that is correct now we can move on to the next point.
>
> void E(void (*x)())
> {
>   H(x, x);
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(E, E));
> }
>
> H: Begin Simulation   Execution Trace Stored at:112b28
> Address_of_H:1392
> [000019d2][00112b14][00112b18] 55         push ebp
> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
> [000019d8][00112b10][000019d2] 50         push eax         // push E
> [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
> [000019dc][00112b0c][000019d2] 51         push ecx         // push E
> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    // call H
> H: Infinitely Recursive Simulation Detected Simulation Stopped
>
> We can see that the seventh instruction of E correctly simulated by H
> would call H to simulate itself again.


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<d3SbL.14322$%VI9.13847@fx34.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx34.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.2
Subject: Re: Simulating halt decider applied to a simpler input
Content-Language: en-US
Newsgroups: comp.theory,sci.logic
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
<6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me>
<_9RbL.5611$gBW5.2085@fx06.iad> <tkonum$17cpp$1@dont-email.me>
<7xRbL.11594$o6Z5.1319@fx07.iad> <20221112184207.000004d1@reddwarf.jmc.corp>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <20221112184207.000004d1@reddwarf.jmc.corp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 369
Message-ID: <d3SbL.14322$%VI9.13847@fx34.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: Sat, 12 Nov 2022 14:00:21 -0500
X-Received-Bytes: 18664
 by: Richard Damon - Sat, 12 Nov 2022 19:00 UTC

On 11/12/22 1:42 PM, Mr Flibble wrote:
> On Sat, 12 Nov 2022 13:24:00 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 11/12/22 1:16 PM, olcott wrote:
>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>
>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked
>>>>>>>>>>>>>>>>>>>>>>>> you and I would have thought given your
>>>>>>>>>>>>>>>>>>>>>>>> intelligence you would also understand that.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>>>> mostly ignores me.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond
>>>>>>>>>>>>>>>>>>>>>>> to what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he
>>>>>>>>>>>>>>>>>>>>>>> has blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into
>>>>>>>>>>>>>>>>>>>>>>> the archives, I want enough evidence to be
>>>>>>>>>>>>>>>>>>>>>>> around to point out his errors.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know
>>>>>>>>>>>>>>>>>>>>>>> and provide reasoning behind the claims,
>>>>>>>>>>>>>>>>>>>>>>> showing the Truth.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
>>>>>>>>>>>>>>>>>>>>>>> that he doesn't actually know what he is
>>>>>>>>>>>>>>>>>>>>>>> talking about, and reveals his ignorance. If he
>>>>>>>>>>>>>>>>>>>>>>> tries to put his explanation into explicit
>>>>>>>>>>>>>>>>>>>>>>> words, his errors become very apparent, I think
>>>>>>>>>>>>>>>>>>>>>>> even to him, so he just refuses.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your
>>>>>>>>>>>>>>>>>>>>>> only basis. Naive readers will never notice
>>>>>>>>>>>>>>>>>>>>>> this, yet naive readers are not in my target
>>>>>>>>>>>>>>>>>>>>>> audience.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
>>>>>>>>>>>>>>>>>>>>> Halting Decider.
>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>>>> Turing machine (UTM) knows that the behavior of D
>>>>>>>>>>>>>>>>>>>> correctly simulated by H provides H with a correct
>>>>>>>>>>>>>>>>>>>> basis for its halt status decision.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
>>>>>>>>>>>>>>>>>> shell game can correctly deny this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
>>>>>>>>>>>>>>>>> because the CORRECT simulation, as will the diret
>>>>>>>>>>>>>>>>> exectuion, will halt. Note, such an H doesn't do a
>>>>>>>>>>>>>>>>> correct simulation, so any
>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>> reference category error present in the proof; what
>>>>>>>>>>>>>>>> Olcott is getting wrong is the mapping of the need to
>>>>>>>>>>>>>>>> abort the simulation to a halt decision of
>>>>>>>>>>>>>>>> non-halting; it needs to instead be mapped to
>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
>>>>>>>>>>>>>>> it, not a "reference" to it. Turing Machines do not
>>>>>>>>>>>>>>> have the power to directly express a reference.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
>>>>>>>>>>>>>> copies all the way down so is the same category error
>>>>>>>>>>>>>> manifesting in a different way.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case it
>>>>>>>>>>>>> isn't actually a decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>> "Impossible" program is simple to make from it, and is
>>>>>>>>>>>>> given one copy of the description of itself, which is
>>>>>>>>>>>>> also simple to make.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When run it makes a second copy of its description, and
>>>>>>>>>>>>> then calls the decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> After that, it is the deciders job to make the decision
>>>>>>>>>>>>> in finite
>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in
>>>>>>>>>>>>> your infinite loop, the decider is just wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The proof shows that what ever answer the decider does
>>>>>>>>>>>>> give (if it gives one) will be wrong, and thus the
>>>>>>>>>>>>> decider doesn't meet the requirements.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>> given a copy of something that just happens to be its own
>>>>>>>>>>>>> description.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only place we get any form of "Reference", is when we
>>>>>>>>>>>>> try to ANALYSE or DESIGN the H to try to meet the
>>>>>>>>>>>>> challenge. There the effect of the Self-Reference just
>>>>>>>>>>>>> lets us see that the task turns
>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>
>>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>>> halting problem proofs based on [Strachey 1965] the
>>>>>>>>>>>> program is impossible not due to self reference or
>>>>>>>>>>>> infinite copies but because the input
>>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>>> category
>>>>>>>>>>>> error that I have identified is different: it is an error
>>>>>>>>>>>> of self reference and/or infinite copies; it is an error
>>>>>>>>>>>> related to the fact that the input references a decider
>>>>>>>>>>>> rather than being related
>>>>>>>>>>>> to what the input does with the decision result of a
>>>>>>>>>>>> decider.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
>>>>>>>>>>> handle ANY input and answer in finite time, If an input
>>>>>>>>>>> causes it to make infinite copies, then the decided just
>>>>>>>>>>> doesn't meet its requirements.
>>>>>>>>>>>
>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on another
>>>>>>>>>>> Turing Machine as a base. The only reason it wouldn't be
>>>>>>>>>>> allowed is if H isn't actually a Turing Machine, so it
>>>>>>>>>>> CAN'T be a category error if H is actualy a Turing Machine.
>>>>>>>>>>>
>>>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>>>> admitting that your H can't actually be a Turing Machine,
>>>>>>>>>>> but must be of a HIGHER order logic system, which means H
>>>>>>>>>>> fails the requirement to be the needed decider.
>>>>>>>>>>
>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>> down: yet
>>>>>>>>>> another manifestation of the category error I have
>>>>>>>>>> identified.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>>> either H
>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>> sequence of
>>>>>>>>> simulations we have just shown that H was defective because
>>>>>>>>> it failed
>>>>>>>>> to answer in finite time.
>>>>>>>>>
>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>
>>>>>>>>> Note, when we start H, there is exactly two machines present
>>>>>>>>> in representation on the tape, and two is much smaller than
>>>>>>>>> infinity.
>>>>>>>>
>>>>>>>> Nope, if,
>>>>>>>>
>>>>>>>> a) H is a copy, and
>>>>>>>> b) H is a Turing Machine, and
>>>>>>>> c) D is an input into H, and
>>>>>>>> d) D references H, and
>>>>>>>> e) H references D,
>>>>>>>>
>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>>>>> Machines
>>>>>>>> all the way down: a manifestation of the category error I have
>>>>>>>> identified.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> void E(void (*x)())
>>>>>>> {
>>>>>>>    H(x, x);
>>>>>>> }
>>>>>>>
>>>>>>> The point is
>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>> correct simulation.
>>>>>>>
>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>
>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>> correct simulation.
>>>>>>>
>>>>>>
>>>>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>>>>> statement. When it is correctly simulated by something other
>>>>>> than H, it will come to a final state, showing your statement is
>>>>>> wrong.
>>>>> In order for the simulation to actually be incorrect the
>>>>> execution trace of the simulated E must diverge from the behavior
>>>>> that the line-by-line x86 source-code of E specifies.
>>>>
>>>> Right, and since you simulation does NOT continue past the call to
>>>> H, it is "incorrect" in the sense that the actual code does
>>>> continue past that point, so it does not actually match the
>>>> behavior of that machine.
>>>>>
>>>>> The first seven lines of the execution trace of the simulated E
>>>>> exactly match the behavior specified by the first seven lines of
>>>>> the x86 source code of E. This conclusively proves beyond all
>>>>> possible doubt that these first seven lines have been simulated
>>>>> correctly.
>>>>
>>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>>> which does NOT prove the input is non-halting.
>>>>
>>>>>
>>>>> *H correctly determines that E never halts*
>>>>>
>>>>> void E(void (*x)())
>>>>> {
>>>>>    H(x, x);
>>>>> }
>>>>>
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H(E, E));
>>>>> }
>>>>>
>>>>> _E()
>>>>> [000019d2] 55             push ebp
>>>>> [000019d3] 8bec           mov ebp,esp
>>>>> [000019d5] 8b4508         mov eax,[ebp+08]
>>>>> [000019d8] 50             push eax
>>>>> [000019d9] 8b4d08         mov ecx,[ebp+08]
>>>>> [000019dc] 51             push ecx
>>>>> [000019dd] e8b0f9ffff     call 00001392
>>>>> [000019e2] 83c408         add esp,+08
>>>>> [000019e5] 5d             pop ebp
>>>>> [000019e6] c3             ret
>>>>> Size in bytes:(0021) [000019e6]
>>>>>
>>>>> _main()
>>>>> [000019f2] 55             push ebp
>>>>> [000019f3] 8bec           mov ebp,esp
>>>>> [000019f5] 68d2190000     push 000019d2
>>>>> [000019fa] 68d2190000     push 000019d2
>>>>> [000019ff] e88ef9ffff     call 00001392
>>>>> [00001a04] 83c408         add esp,+08
>>>>> [00001a07] 50             push eax
>>>>> [00001a08] 6893060000     push 00000693
>>>>> [00001a0d] e8a0ecffff     call 000006b2
>>>>> [00001a12] 83c408         add esp,+08
>>>>> [00001a15] 33c0           xor eax,eax
>>>>> [00001a17] 5d             pop ebp
>>>>> [00001a18] c3             ret
>>>>> Size in bytes:(0039) [00001a18]
>>>>>
>>>>>   machine   stack     stack     machine    assembly
>>>>>   address   address   data      code       language
>>>>>   ========  ========  ========  =========  =============
>>>>> [000019f2][00102a7c][00000000] 55         push ebp
>>>>> [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>>>
>>>>> H: Begin Simulation   Execution Trace Stored at:112b28
>>>>> Address_of_H:1392
>>>>> [000019d2][00112b14][00112b18] 55         push ebp
>>>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>>>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>>>>> [000019d8][00112b10][000019d2] 50         push eax         //
>>>>> push E [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
>>>>> [000019dc][00112b0c][000019d2] 51         push ecx         //
>>>>> push E [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392
>>>>> // call H H: Infinitely Recursive Simulation Detected Simulation
>>>>> Stopped
>>>>>
>>>>> H correctly reports that E correctly simulated by H cannot
>>>>> possibly reach its own final state at machine address [000019e6]
>>>>> and terminate normally in 1 to ∞ steps of correct simulation.
>>>>>
>>>>>
>>>>
>>>> So you are just admitting you don't understand the Halting
>>>> Criteria.
>>>>
>>>> The fact that H stops its simulation before it gets to the end
>>>> does NOT prove that the machine being simulated, or a correct and
>>>> complete simultion of the input would be non-halting.
>>> We must handle only one point at a time because you are easily
>>> overwhelmed. You usually cannot even handle one point at a time
>>> until this point is repeated 20 or more times.
>>>
>>> The fact that the line-by-line execution trace of the first seven
>>> instructions E simulated by H exactly match the behavior specified
>>> by the first seven instructions of the x86 source-code of E
>>> conclusively proves that these first seven instructions are
>>> simulated correctly.
>>
>> No, that says that H did a correct PARTIAL simulation of the input.
>> You seem to be INTENTIONALLY using deceptive terminology to spread
>> you lies.
>>
>> So, I suppose you can correctly say that the input doesn't stop
>> within its first 7 instructions, but that doesn't mean anything.
>>
>> Since you make a claim about a COMPLETE simulation (the it will never
>> end) you need to establish THAT fact (and you can't change the input
>> to do it, which includes the H the E calls).
>>
>> YOU FAIL
>>
>> You show that you don't understand what you are talking about and
>> seem to actually think that you are proving something by using wrong
>> defintions.
>>
>> You are just showing how stupid you are.
>
> Again with the ad hominem attacks: "liar", "stupid" etc. You are not
> very good at his are you, Mr Damon.
>
> /Flibble
>


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<tkoqo1$ta1$1@gioia.aioe.org>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!aioe.org!/maIWMVc/1untnACPzZ7XA.user.46.165.242.91.POSTED!not-for-mail
From: none...@beez-waxes.com (olcott)
Newsgroups: comp.theory,sci.logic
Subject: Re: Simulating halt decider applied to a simpler input
Date: Sat, 12 Nov 2022 13:04:32 -0600
Organization: Aioe.org NNTP Server
Message-ID: <tkoqo1$ta1$1@gioia.aioe.org>
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
<6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me>
<_9RbL.5611$gBW5.2085@fx06.iad> <tkonum$17cpp$1@dont-email.me>
<7xRbL.11594$o6Z5.1319@fx07.iad> <tkopjk$fah$1@gioia.aioe.org>
<90SbL.14321$%VI9.7406@fx34.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="30017"; posting-host="/maIWMVc/1untnACPzZ7XA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.4.2
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.9.2
 by: olcott - Sat, 12 Nov 2022 19:04 UTC

On 11/12/2022 12:57 PM, Richard Damon wrote:
> On 11/12/22 1:45 PM, olcott wrote:
>> On 11/12/2022 12:24 PM, Richard Damon wrote:
>>> On 11/12/22 1:16 PM, olcott wrote:
>>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>
>>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>>>>>>>> and I would have thought given your
>>>>>>>>>>>>>>>>>>>>>>>>> intelligence you
>>>>>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to
>>>>>>>>>>>>>>>>>>>>>>>> point
>>>>>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the
>>>>>>>>>>>>>>>>>>>>>>>> Truth.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
>>>>>>>>>>>>>>>>>>>>>>>> that he
>>>>>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet
>>>>>>>>>>>>>>>>>>>>>>> naive
>>>>>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
>>>>>>>>>>>>>>>>>>>>>> Halting
>>>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
>>>>>>>>>>>>>>>>>>> shell
>>>>>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
>>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation,
>>>>>>>>>>>>>>>>>> so any
>>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>>>> category error present in the proof; what Olcott is
>>>>>>>>>>>>>>>>> getting
>>>>>>>>>>>>>>>>> wrong is the mapping of the need to abort the
>>>>>>>>>>>>>>>>> simulation to a
>>>>>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be
>>>>>>>>>>>>>>>>> mapped to
>>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding it,
>>>>>>>>>>>>>>>> not a
>>>>>>>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
>>>>>>>>>>>>>>> copies
>>>>>>>>>>>>>>> all the way down so is the same category error
>>>>>>>>>>>>>>> manifesting in a
>>>>>>>>>>>>>>> different way.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case it
>>>>>>>>>>>>>> isn't
>>>>>>>>>>>>>> actually a decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>>> "Impossible"
>>>>>>>>>>>>>> program is simple to make from it, and is given one copy
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>>>>>>> calls the decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> After that, it is the deciders job to make the decision in
>>>>>>>>>>>>>> finite
>>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The proof shows that what ever answer the decider does
>>>>>>>>>>>>>> give (if
>>>>>>>>>>>>>> it gives one) will be wrong, and thus the decider doesn't
>>>>>>>>>>>>>> meet
>>>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>>> given a
>>>>>>>>>>>>>> copy of something that just happens to be its own
>>>>>>>>>>>>>> description.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The only place we get any form of "Reference", is when we
>>>>>>>>>>>>>> try to
>>>>>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge.
>>>>>>>>>>>>>> There the
>>>>>>>>>>>>>> effect of the Self-Reference just lets us see that the
>>>>>>>>>>>>>> task turns
>>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>>>> halting
>>>>>>>>>>>>> problem proofs based on [Strachey 1965] the program is
>>>>>>>>>>>>> impossible
>>>>>>>>>>>>> not due to self reference or infinite copies but because
>>>>>>>>>>>>> the input
>>>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>>>> category
>>>>>>>>>>>>> error that I have identified is different: it is an error
>>>>>>>>>>>>> of self
>>>>>>>>>>>>> reference and/or infinite copies; it is an error related to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> fact that the input references a decider rather than being
>>>>>>>>>>>>> related
>>>>>>>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
>>>>>>>>>>>> handle
>>>>>>>>>>>> ANY input and answer in finite time, If an input causes it
>>>>>>>>>>>> to make
>>>>>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>>>>>> requirements.
>>>>>>>>>>>>
>>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on another
>>>>>>>>>>>> Turing
>>>>>>>>>>>> Machine as a base. The only reason it wouldn't be allowed is
>>>>>>>>>>>> if H
>>>>>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category
>>>>>>>>>>>> error
>>>>>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>>>>>
>>>>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>>>>> admitting that your H can't actually be a Turing Machine,
>>>>>>>>>>>> but must
>>>>>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>>>>>> requirement to be the needed decider.
>>>>>>>>>>>
>>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>>> down: yet
>>>>>>>>>>> another manifestation of the category error I have identified.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>>>> either H
>>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>>> sequence of
>>>>>>>>>> simulations we have just shown that H was defective because it
>>>>>>>>>> failed
>>>>>>>>>> to answer in finite time.
>>>>>>>>>>
>>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>>
>>>>>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>>>>>> representation on the tape, and two is much smaller than
>>>>>>>>>> infinity.
>>>>>>>>>
>>>>>>>>> Nope, if,
>>>>>>>>>
>>>>>>>>> a) H is a copy, and
>>>>>>>>> b) H is a Turing Machine, and
>>>>>>>>> c) D is an input into H, and
>>>>>>>>> d) D references H, and
>>>>>>>>> e) H references D,
>>>>>>>>>
>>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>>>>>> Machines
>>>>>>>>> all the way down: a manifestation of the category error I have
>>>>>>>>> identified.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> void E(void (*x)())
>>>>>>>> {
>>>>>>>>    H(x, x);
>>>>>>>> }
>>>>>>>>
>>>>>>>> The point is
>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>>>>> simulation.
>>>>>>>>
>>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>>
>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>>>>> simulation.
>>>>>>>>
>>>>>>>
>>>>>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>>>>>> statement. When it is correctly simulated by something other than
>>>>>>> H, it will come to a final state, showing your statement is wrong.
>>>>>> In order for the simulation to actually be incorrect the execution
>>>>>> trace of the simulated E must diverge from the behavior that the
>>>>>> line-by-line x86 source-code of E specifies.
>>>>>
>>>>> Right, and since you simulation does NOT continue past the call to
>>>>> H, it is "incorrect" in the sense that the actual code does
>>>>> continue past that point, so it does not actually match the
>>>>> behavior of that machine.
>>>>>
>>>>>>
>>>>>> The first seven lines of the execution trace of the simulated E
>>>>>> exactly match the behavior specified by the first seven lines of
>>>>>> the x86 source code of E. This conclusively proves beyond all
>>>>>> possible doubt that these first seven lines have been simulated
>>>>>> correctly.
>>>>>
>>>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>>>> which does NOT prove the input is non-halting.
>>>>>
>>>>>>
>>>>>> *H correctly determines that E never halts*
>>>>>>
>>>>>> void E(void (*x)())
>>>>>> {
>>>>>>    H(x, x);
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>    Output("Input_Halts = ", H(E, E));
>>>>>> }
>>>>>>
>>>>>> _E()
>>>>>> [000019d2] 55             push ebp
>>>>>> [000019d3] 8bec           mov ebp,esp
>>>>>> [000019d5] 8b4508         mov eax,[ebp+08]
>>>>>> [000019d8] 50             push eax
>>>>>> [000019d9] 8b4d08         mov ecx,[ebp+08]
>>>>>> [000019dc] 51             push ecx
>>>>>> [000019dd] e8b0f9ffff     call 00001392
>>>>>> [000019e2] 83c408         add esp,+08
>>>>>> [000019e5] 5d             pop ebp
>>>>>> [000019e6] c3             ret
>>>>>> Size in bytes:(0021) [000019e6]
>>>>>>
>>>>>> _main()
>>>>>> [000019f2] 55             push ebp
>>>>>> [000019f3] 8bec           mov ebp,esp
>>>>>> [000019f5] 68d2190000     push 000019d2
>>>>>> [000019fa] 68d2190000     push 000019d2
>>>>>> [000019ff] e88ef9ffff     call 00001392
>>>>>> [00001a04] 83c408         add esp,+08
>>>>>> [00001a07] 50             push eax
>>>>>> [00001a08] 6893060000     push 00000693
>>>>>> [00001a0d] e8a0ecffff     call 000006b2
>>>>>> [00001a12] 83c408         add esp,+08
>>>>>> [00001a15] 33c0           xor eax,eax
>>>>>> [00001a17] 5d             pop ebp
>>>>>> [00001a18] c3             ret
>>>>>> Size in bytes:(0039) [00001a18]
>>>>>>
>>>>>>   machine   stack     stack     machine    assembly
>>>>>>   address   address   data      code       language
>>>>>>   ========  ========  ========  =========  =============
>>>>>> [000019f2][00102a7c][00000000] 55         push ebp
>>>>>> [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
>>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>>>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>>>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>>>>
>>>>>> H: Begin Simulation   Execution Trace Stored at:112b28
>>>>>> Address_of_H:1392
>>>>>> [000019d2][00112b14][00112b18] 55         push ebp
>>>>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>>>>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>>>>>> [000019d8][00112b10][000019d2] 50         push eax         // push E
>>>>>> [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
>>>>>> [000019dc][00112b0c][000019d2] 51         push ecx         // push E
>>>>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    // call H
>>>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>
>>>>>> H correctly reports that E correctly simulated by H cannot
>>>>>> possibly reach its own final state at machine address [000019e6]
>>>>>> and terminate normally in 1 to ∞ steps of correct simulation.
>>>>>>
>>>>>>
>>>>>
>>>>> So you are just admitting you don't understand the Halting Criteria.
>>>>>
>>>>> The fact that H stops its simulation before it gets to the end does
>>>>> NOT prove that the machine being simulated, or a correct and
>>>>> complete simultion of the input would be non-halting.
>>>> We must handle only one point at a time because you are easily
>>>> overwhelmed. You usually cannot even handle one point at a time
>>>> until this point is repeated 20 or more times.
>>>>
>>>> The fact that the line-by-line execution trace of the first seven
>>>> instructions E simulated by H exactly match the behavior specified
>>>> by the first seven instructions of the x86 source-code of E
>>>> conclusively proves that these first seven instructions are
>>>> simulated correctly.
>>>>
>>>
>>> No, that says that H did a correct PARTIAL simulation of the input.
>>
>> Yes that is correct now we can move on to the next point.
>>
>> void E(void (*x)())
>> {
>>    H(x, x);
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H(E, E));
>> }
>>
>> H: Begin Simulation   Execution Trace Stored at:112b28
>> Address_of_H:1392
>> [000019d2][00112b14][00112b18] 55         push ebp
>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>> [000019d8][00112b10][000019d2] 50         push eax         // push E
>> [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
>> [000019dc][00112b0c][000019d2] 51         push ecx         // push E
>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    // call H
>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>
>> We can see that the seventh instruction of E correctly simulated by H
>> would call H to simulate itself again.
>
> No, E calls H which will HALT DECIDER (by simulation) its input.
Try again this time don't use a noun as a verb gibberish.


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<LmSbL.74300$Jjx8.17367@fx15.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx15.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.2
Subject: Re: Simulating halt decider applied to a simpler input
Content-Language: en-US
Newsgroups: comp.theory,sci.logic
References: <tklpng$shkk$1@dont-email.me> <BhubL.6358$BaF9.3168@fx39.iad>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
<6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me>
<_9RbL.5611$gBW5.2085@fx06.iad> <tkonum$17cpp$1@dont-email.me>
<7xRbL.11594$o6Z5.1319@fx07.iad> <tkopjk$fah$1@gioia.aioe.org>
<90SbL.14321$%VI9.7406@fx34.iad> <tkoqo1$ta1$1@gioia.aioe.org>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tkoqo1$ta1$1@gioia.aioe.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 411
Message-ID: <LmSbL.74300$Jjx8.17367@fx15.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: Sat, 12 Nov 2022 14:21:11 -0500
X-Received-Bytes: 20405
 by: Richard Damon - Sat, 12 Nov 2022 19:21 UTC

On 11/12/22 2:04 PM, olcott wrote:
> On 11/12/2022 12:57 PM, Richard Damon wrote:
>> On 11/12/22 1:45 PM, olcott wrote:
>>> On 11/12/2022 12:24 PM, Richard Damon wrote:
>>>> On 11/12/22 1:16 PM, olcott wrote:
>>>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked
>>>>>>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>>>>>> and I would have thought given your
>>>>>>>>>>>>>>>>>>>>>>>>>> intelligence you
>>>>>>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he
>>>>>>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around
>>>>>>>>>>>>>>>>>>>>>>>>> to point
>>>>>>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing
>>>>>>>>>>>>>>>>>>>>>>>>> the Truth.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
>>>>>>>>>>>>>>>>>>>>>>>>> that he
>>>>>>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about,
>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet
>>>>>>>>>>>>>>>>>>>>>>>> naive
>>>>>>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
>>>>>>>>>>>>>>>>>>>>>>> Halting
>>>>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for
>>>>>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
>>>>>>>>>>>>>>>>>>>> shell
>>>>>>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
>>>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion,
>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct
>>>>>>>>>>>>>>>>>>> simulation, so any
>>>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>>>>> category error present in the proof; what Olcott is
>>>>>>>>>>>>>>>>>> getting
>>>>>>>>>>>>>>>>>> wrong is the mapping of the need to abort the
>>>>>>>>>>>>>>>>>> simulation to a
>>>>>>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be
>>>>>>>>>>>>>>>>>> mapped to
>>>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
>>>>>>>>>>>>>>>>> it, not a
>>>>>>>>>>>>>>>>> "reference" to it. Turing Machines do not have the
>>>>>>>>>>>>>>>>> power to
>>>>>>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
>>>>>>>>>>>>>>>> copies
>>>>>>>>>>>>>>>> all the way down so is the same category error
>>>>>>>>>>>>>>>> manifesting in a
>>>>>>>>>>>>>>>> different way.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case it
>>>>>>>>>>>>>>> isn't
>>>>>>>>>>>>>>> actually a decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>>>> "Impossible"
>>>>>>>>>>>>>>> program is simple to make from it, and is given one copy
>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>>>>>>>> calls the decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> After that, it is the deciders job to make the decision
>>>>>>>>>>>>>>> in finite
>>>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The proof shows that what ever answer the decider does
>>>>>>>>>>>>>>> give (if
>>>>>>>>>>>>>>> it gives one) will be wrong, and thus the decider doesn't
>>>>>>>>>>>>>>> meet
>>>>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>>>> given a
>>>>>>>>>>>>>>> copy of something that just happens to be its own
>>>>>>>>>>>>>>> description.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The only place we get any form of "Reference", is when we
>>>>>>>>>>>>>>> try to
>>>>>>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge.
>>>>>>>>>>>>>>> There the
>>>>>>>>>>>>>>> effect of the Self-Reference just lets us see that the
>>>>>>>>>>>>>>> task turns
>>>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>>>>> halting
>>>>>>>>>>>>>> problem proofs based on [Strachey 1965] the program is
>>>>>>>>>>>>>> impossible
>>>>>>>>>>>>>> not due to self reference or infinite copies but because
>>>>>>>>>>>>>> the input
>>>>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>>>>> category
>>>>>>>>>>>>>> error that I have identified is different: it is an error
>>>>>>>>>>>>>> of self
>>>>>>>>>>>>>> reference and/or infinite copies; it is an error related
>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>> fact that the input references a decider rather than being
>>>>>>>>>>>>>> related
>>>>>>>>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
>>>>>>>>>>>>> handle
>>>>>>>>>>>>> ANY input and answer in finite time, If an input causes it
>>>>>>>>>>>>> to make
>>>>>>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>>>>>>> requirements.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on another
>>>>>>>>>>>>> Turing
>>>>>>>>>>>>> Machine as a base. The only reason it wouldn't be allowed
>>>>>>>>>>>>> is if H
>>>>>>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category
>>>>>>>>>>>>> error
>>>>>>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>>>>>> admitting that your H can't actually be a Turing Machine,
>>>>>>>>>>>>> but must
>>>>>>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>>>>>>> requirement to be the needed decider.
>>>>>>>>>>>>
>>>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>>>> down: yet
>>>>>>>>>>>> another manifestation of the category error I have identified.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>>>>> either H
>>>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>>>> sequence of
>>>>>>>>>>> simulations we have just shown that H was defective because
>>>>>>>>>>> it failed
>>>>>>>>>>> to answer in finite time.
>>>>>>>>>>>
>>>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>>>
>>>>>>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>>>>>>> representation on the tape, and two is much smaller than
>>>>>>>>>>> infinity.
>>>>>>>>>>
>>>>>>>>>> Nope, if,
>>>>>>>>>>
>>>>>>>>>> a) H is a copy, and
>>>>>>>>>> b) H is a Turing Machine, and
>>>>>>>>>> c) D is an input into H, and
>>>>>>>>>> d) D references H, and
>>>>>>>>>> e) H references D,
>>>>>>>>>>
>>>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>>>>>>> Machines
>>>>>>>>>> all the way down: a manifestation of the category error I have
>>>>>>>>>> identified.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> void E(void (*x)())
>>>>>>>>> {
>>>>>>>>>    H(x, x);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The point is
>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>> correct simulation.
>>>>>>>>>
>>>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>>>
>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>> correct simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>>>>>>> statement. When it is correctly simulated by something other
>>>>>>>> than H, it will come to a final state, showing your statement is
>>>>>>>> wrong.
>>>>>>> In order for the simulation to actually be incorrect the
>>>>>>> execution trace of the simulated E must diverge from the behavior
>>>>>>> that the line-by-line x86 source-code of E specifies.
>>>>>>
>>>>>> Right, and since you simulation does NOT continue past the call to
>>>>>> H, it is "incorrect" in the sense that the actual code does
>>>>>> continue past that point, so it does not actually match the
>>>>>> behavior of that machine.
>>>>>>
>>>>>>>
>>>>>>> The first seven lines of the execution trace of the simulated E
>>>>>>> exactly match the behavior specified by the first seven lines of
>>>>>>> the x86 source code of E. This conclusively proves beyond all
>>>>>>> possible doubt that these first seven lines have been simulated
>>>>>>> correctly.
>>>>>>
>>>>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>>>>> which does NOT prove the input is non-halting.
>>>>>>
>>>>>>>
>>>>>>> *H correctly determines that E never halts*
>>>>>>>
>>>>>>> void E(void (*x)())
>>>>>>> {
>>>>>>>    H(x, x);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ", H(E, E));
>>>>>>> }
>>>>>>>
>>>>>>> _E()
>>>>>>> [000019d2] 55             push ebp
>>>>>>> [000019d3] 8bec           mov ebp,esp
>>>>>>> [000019d5] 8b4508         mov eax,[ebp+08]
>>>>>>> [000019d8] 50             push eax
>>>>>>> [000019d9] 8b4d08         mov ecx,[ebp+08]
>>>>>>> [000019dc] 51             push ecx
>>>>>>> [000019dd] e8b0f9ffff     call 00001392
>>>>>>> [000019e2] 83c408         add esp,+08
>>>>>>> [000019e5] 5d             pop ebp
>>>>>>> [000019e6] c3             ret
>>>>>>> Size in bytes:(0021) [000019e6]
>>>>>>>
>>>>>>> _main()
>>>>>>> [000019f2] 55             push ebp
>>>>>>> [000019f3] 8bec           mov ebp,esp
>>>>>>> [000019f5] 68d2190000     push 000019d2
>>>>>>> [000019fa] 68d2190000     push 000019d2
>>>>>>> [000019ff] e88ef9ffff     call 00001392
>>>>>>> [00001a04] 83c408         add esp,+08
>>>>>>> [00001a07] 50             push eax
>>>>>>> [00001a08] 6893060000     push 00000693
>>>>>>> [00001a0d] e8a0ecffff     call 000006b2
>>>>>>> [00001a12] 83c408         add esp,+08
>>>>>>> [00001a15] 33c0           xor eax,eax
>>>>>>> [00001a17] 5d             pop ebp
>>>>>>> [00001a18] c3             ret
>>>>>>> Size in bytes:(0039) [00001a18]
>>>>>>>
>>>>>>>   machine   stack     stack     machine    assembly
>>>>>>>   address   address   data      code       language
>>>>>>>   ========  ========  ========  =========  =============
>>>>>>> [000019f2][00102a7c][00000000] 55         push ebp
>>>>>>> [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
>>>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>>>>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>>>>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>>>>>
>>>>>>> H: Begin Simulation   Execution Trace Stored at:112b28
>>>>>>> Address_of_H:1392
>>>>>>> [000019d2][00112b14][00112b18] 55         push ebp
>>>>>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>>>>>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>>>>>>> [000019d8][00112b10][000019d2] 50         push eax         // push E
>>>>>>> [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
>>>>>>> [000019dc][00112b0c][000019d2] 51         push ecx         // push E
>>>>>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    // call H
>>>>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>
>>>>>>> H correctly reports that E correctly simulated by H cannot
>>>>>>> possibly reach its own final state at machine address [000019e6]
>>>>>>> and terminate normally in 1 to ∞ steps of correct simulation.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> So you are just admitting you don't understand the Halting Criteria.
>>>>>>
>>>>>> The fact that H stops its simulation before it gets to the end
>>>>>> does NOT prove that the machine being simulated, or a correct and
>>>>>> complete simultion of the input would be non-halting.
>>>>> We must handle only one point at a time because you are easily
>>>>> overwhelmed. You usually cannot even handle one point at a time
>>>>> until this point is repeated 20 or more times.
>>>>>
>>>>> The fact that the line-by-line execution trace of the first seven
>>>>> instructions E simulated by H exactly match the behavior specified
>>>>> by the first seven instructions of the x86 source-code of E
>>>>> conclusively proves that these first seven instructions are
>>>>> simulated correctly.
>>>>>
>>>>
>>>> No, that says that H did a correct PARTIAL simulation of the input.
>>>
>>> Yes that is correct now we can move on to the next point.
>>>
>>> void E(void (*x)())
>>> {
>>>    H(x, x);
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H(E, E));
>>> }
>>>
>>> H: Begin Simulation   Execution Trace Stored at:112b28
>>> Address_of_H:1392
>>> [000019d2][00112b14][00112b18] 55         push ebp
>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>>> [000019d8][00112b10][000019d2] 50         push eax         // push E
>>> [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
>>> [000019dc][00112b0c][000019d2] 51         push ecx         // push E
>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    // call H
>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>
>>> We can see that the seventh instruction of E correctly simulated by H
>>> would call H to simulate itself again.
>>
>> No, E calls H which will HALT DECIDER (by simulation) its input.
> Try again this time don't use a noun as a verb gibberish.
>


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<20221112192618.00003dec@reddwarf.jmc.corp>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Date: Sat, 12 Nov 2022 19:26:18 +0000
From: flib...@reddwarf.jmc.corp (Mr Flibble)
Newsgroups: comp.theory,sci.logic
Subject: Re: Simulating halt decider applied to a simpler input
Message-ID: <20221112192618.00003dec@reddwarf.jmc.corp>
References: <tklpng$shkk$1@dont-email.me> <20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad> <tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad> <tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad> <tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad> <20221111215433.00005425@reddwarf.jmc.corp> <dSAbL.106246$U709.51175@fx16.iad> <20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad> <20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad> <20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad> <20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me> <6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me> <_9RbL.5611$gBW5.2085@fx06.iad> <tkonum$17cpp$1@dont-email.me> <7xRbL.11594$o6Z5.1319@fx07.iad> <20221112184207.000004d1@reddwarf.jmc.corp> <d3SbL.14322$%VI9.13847@fx34.iad>
Organization: NewsDemon - www.newsdemon.com
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Lines: 422
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!tr2.eu1.usenetexpress.com!news.newsdemon.com!not-for-mail
NNTP-Posting-Date: Sat, 12 Nov 2022 19:26:18 +0000
X-Received-Bytes: 21576
X-Complaints-To: abuse@newsdemon.com
 by: Mr Flibble - Sat, 12 Nov 2022 19:26 UTC

On Sat, 12 Nov 2022 14:00:21 -0500
Richard Damon <Richard@Damon-Family.org> wrote:

> On 11/12/22 1:42 PM, Mr Flibble wrote:
> > On Sat, 12 Nov 2022 13:24:00 -0500
> > Richard Damon <Richard@Damon-Family.org> wrote:
> >
> >> On 11/12/22 1:16 PM, olcott wrote:
> >>> On 11/12/2022 11:59 AM, Richard Damon wrote:
> >>>> On 11/12/22 12:00 PM, olcott wrote:
> >>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
> >>>>>> On 11/12/22 10:50 AM, olcott wrote:
> >>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
> >>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
> >>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>
> >>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
> >>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
> >>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
> >>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
> >>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
> >>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
> >>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has
> >>>>>>>>>>>>>>>>>>>>>>>> blocked you and I would have thought given
> >>>>>>>>>>>>>>>>>>>>>>>> your intelligence you would also understand
> >>>>>>>>>>>>>>>>>>>>>>>> that.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
> >>>>>>>>>>>>>>>>>>>>>>> mostly ignores me.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to
> >>>>>>>>>>>>>>>>>>>>>>> respond to what I say, even if not in a
> >>>>>>>>>>>>>>>>>>>>>>> direct reply,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if
> >>>>>>>>>>>>>>>>>>>>>>> he has blocked me, he will still see me.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into
> >>>>>>>>>>>>>>>>>>>>>>> the archives, I want enough evidence to be
> >>>>>>>>>>>>>>>>>>>>>>> around to point out his errors.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know
> >>>>>>>>>>>>>>>>>>>>>>> and provide reasoning behind the claims,
> >>>>>>>>>>>>>>>>>>>>>>> showing the Truth.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
> >>>>>>>>>>>>>>>>>>>>>>> that he doesn't actually know what he is
> >>>>>>>>>>>>>>>>>>>>>>> talking about, and reveals his ignorance. If
> >>>>>>>>>>>>>>>>>>>>>>> he tries to put his explanation into explicit
> >>>>>>>>>>>>>>>>>>>>>>> words, his errors become very apparent, I
> >>>>>>>>>>>>>>>>>>>>>>> think even to him, so he just refuses.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your
> >>>>>>>>>>>>>>>>>>>>>> only basis. Naive readers will never notice
> >>>>>>>>>>>>>>>>>>>>>> this, yet naive readers are not in my target
> >>>>>>>>>>>>>>>>>>>>>> audience.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
> >>>>>>>>>>>>>>>>>>>>> Halting Decider.
> >>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
> >>>>>>>>>>>>>>>>>>>> Turing machine (UTM) knows that the behavior of D
> >>>>>>>>>>>>>>>>>>>> correctly simulated by H provides H with a
> >>>>>>>>>>>>>>>>>>>> correct basis for its halt status decision.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> void E(void (*x)())
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>         H(x, x);
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
> >>>>>>>>>>>>>>>>>> infinite
> >>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
> >>>>>>>>>>>>>>>>>> shell game can correctly deny this.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
> >>>>>>>>>>>>>>>>> because the CORRECT simulation, as will the diret
> >>>>>>>>>>>>>>>>> exectuion, will halt. Note, such an H doesn't do a
> >>>>>>>>>>>>>>>>> correct simulation, so any
> >>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
> >>>>>>>>>>>>>>>> reference category error present in the proof; what
> >>>>>>>>>>>>>>>> Olcott is getting wrong is the mapping of the need to
> >>>>>>>>>>>>>>>> abort the simulation to a halt decision of
> >>>>>>>>>>>>>>>> non-halting; it needs to instead be mapped to
> >>>>>>>>>>>>>>>> INVALID INPUT.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Nope, no self reference.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
> >>>>>>>>>>>>>>> it, not a "reference" to it. Turing Machines do not
> >>>>>>>>>>>>>>> have the power to directly express a reference.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
> >>>>>>>>>>>>>> copies all the way down so is the same category error
> >>>>>>>>>>>>>> manifesting in a different way.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Only if the "decider" makes that happen, in which case
> >>>>>>>>>>>>> it isn't actually a decider.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If we assume a prospective decider exists, then the
> >>>>>>>>>>>>> "Impossible" program is simple to make from it, and is
> >>>>>>>>>>>>> given one copy of the description of itself, which is
> >>>>>>>>>>>>> also simple to make.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> When run it makes a second copy of its description, and
> >>>>>>>>>>>>> then calls the decider.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> After that, it is the deciders job to make the decision
> >>>>>>>>>>>>> in finite
> >>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in
> >>>>>>>>>>>>> your infinite loop, the decider is just wrong.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The proof shows that what ever answer the decider does
> >>>>>>>>>>>>> give (if it gives one) will be wrong, and thus the
> >>>>>>>>>>>>> decider doesn't meet the requirements.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> No "Self Reference" in sight there only a program being
> >>>>>>>>>>>>> given a copy of something that just happens to be its
> >>>>>>>>>>>>> own description.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The only place we get any form of "Reference", is when
> >>>>>>>>>>>>> we try to ANALYSE or DESIGN the H to try to meet the
> >>>>>>>>>>>>> challenge. There the effect of the Self-Reference just
> >>>>>>>>>>>>> lets us see that the task turns
> >>>>>>>>>>>>> out be be impossible, so no such program exists.
> >>>>>>>>>>>>
> >>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
> >>>>>>>>>>>> halting problem proofs based on [Strachey 1965] the
> >>>>>>>>>>>> program is impossible not due to self reference or
> >>>>>>>>>>>> infinite copies but because the input
> >>>>>>>>>>>> tries to do the opposite of what the decider decides; the
> >>>>>>>>>>>> category
> >>>>>>>>>>>> error that I have identified is different: it is an error
> >>>>>>>>>>>> of self reference and/or infinite copies; it is an error
> >>>>>>>>>>>> related to the fact that the input references a decider
> >>>>>>>>>>>> rather than being related
> >>>>>>>>>>>> to what the input does with the decision result of a
> >>>>>>>>>>>> decider.
> >>>>>>>>>>>>
> >>>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>> But the infinite copies is a error in the Decider, not in
> >>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
> >>>>>>>>>>> handle ANY input and answer in finite time, If an input
> >>>>>>>>>>> causes it to make infinite copies, then the decided just
> >>>>>>>>>>> doesn't meet its requirements.
> >>>>>>>>>>>
> >>>>>>>>>>> Turing Machine can ALWAYS be legally built based on
> >>>>>>>>>>> another Turing Machine as a base. The only reason it
> >>>>>>>>>>> wouldn't be allowed is if H isn't actually a Turing
> >>>>>>>>>>> Machine, so it CAN'T be a category error if H is actualy
> >>>>>>>>>>> a Turing Machine.
> >>>>>>>>>>>
> >>>>>>>>>>> All your declaration of a "Category Error" here is doing
> >>>>>>>>>>> is admitting that your H can't actually be a Turing
> >>>>>>>>>>> Machine, but must be of a HIGHER order logic system,
> >>>>>>>>>>> which means H fails the requirement to be the needed
> >>>>>>>>>>> decider.
> >>>>>>>>>>
> >>>>>>>>>> In which case we get infinite turning machines all the way
> >>>>>>>>>> down: yet
> >>>>>>>>>> another manifestation of the category error I have
> >>>>>>>>>> identified.
> >>>>>>>>>>
> >>>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>> Where are infinite machines? There is ONE machine being run,
> >>>>>>>>> either H
> >>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
> >>>>>>>>> sequence of
> >>>>>>>>> simulations we have just shown that H was defective because
> >>>>>>>>> it failed
> >>>>>>>>> to answer in finite time.
> >>>>>>>>>
> >>>>>>>>> This isn't a category error, but a design error in H.
> >>>>>>>>>
> >>>>>>>>> Note, when we start H, there is exactly two machines present
> >>>>>>>>> in representation on the tape, and two is much smaller than
> >>>>>>>>> infinity.
> >>>>>>>>
> >>>>>>>> Nope, if,
> >>>>>>>>
> >>>>>>>> a) H is a copy, and
> >>>>>>>> b) H is a Turing Machine, and
> >>>>>>>> c) D is an input into H, and
> >>>>>>>> d) D references H, and
> >>>>>>>> e) H references D,
> >>>>>>>>
> >>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite
> >>>>>>>> Turing Machines
> >>>>>>>> all the way down: a manifestation of the category error I
> >>>>>>>> have identified.
> >>>>>>>>
> >>>>>>>> /Flibble
> >>>>>>>>
> >>>>>>>
> >>>>>>> void E(void (*x)())
> >>>>>>> {
> >>>>>>>    H(x, x);
> >>>>>>> }
> >>>>>>>
> >>>>>>> The point is
> >>>>>>> that D correctly simulated by H would never reach its own last
> >>>>>>> instruction and terminate normally after 1 to ∞ steps of
> >>>>>>> correct simulation.
> >>>>>>>
> >>>>>>> When H returns 0 to main() it is indicating
> >>>>>>>
> >>>>>>> that D correctly simulated by H would never reach its own last
> >>>>>>> instruction and terminate normally after 1 to ∞ steps of
> >>>>>>> correct simulation.
> >>>>>>>
> >>>>>>
> >>>>>> Except D is NOT correctly simulated by H, so that is a
> >>>>>> incorrect statement. When it is correctly simulated by
> >>>>>> something other than H, it will come to a final state, showing
> >>>>>> your statement is wrong.
> >>>>> In order for the simulation to actually be incorrect the
> >>>>> execution trace of the simulated E must diverge from the
> >>>>> behavior that the line-by-line x86 source-code of E specifies.
> >>>>
> >>>> Right, and since you simulation does NOT continue past the call
> >>>> to H, it is "incorrect" in the sense that the actual code does
> >>>> continue past that point, so it does not actually match the
> >>>> behavior of that machine.
> >>>>>
> >>>>> The first seven lines of the execution trace of the simulated E
> >>>>> exactly match the behavior specified by the first seven lines of
> >>>>> the x86 source code of E. This conclusively proves beyond all
> >>>>> possible doubt that these first seven lines have been simulated
> >>>>> correctly.
> >>>>
> >>>> Right, so H has correctly done a PARTIAL simulation of its input,
> >>>> which does NOT prove the input is non-halting.
> >>>>
> >>>>>
> >>>>> *H correctly determines that E never halts*
> >>>>>
> >>>>> void E(void (*x)())
> >>>>> {
> >>>>>    H(x, x);
> >>>>> }
> >>>>>
> >>>>>
> >>>>> int main()
> >>>>> {
> >>>>>    Output("Input_Halts = ", H(E, E));
> >>>>> }
> >>>>>
> >>>>> _E()
> >>>>> [000019d2] 55             push ebp
> >>>>> [000019d3] 8bec           mov ebp,esp
> >>>>> [000019d5] 8b4508         mov eax,[ebp+08]
> >>>>> [000019d8] 50             push eax
> >>>>> [000019d9] 8b4d08         mov ecx,[ebp+08]
> >>>>> [000019dc] 51             push ecx
> >>>>> [000019dd] e8b0f9ffff     call 00001392
> >>>>> [000019e2] 83c408         add esp,+08
> >>>>> [000019e5] 5d             pop ebp
> >>>>> [000019e6] c3             ret
> >>>>> Size in bytes:(0021) [000019e6]
> >>>>>
> >>>>> _main()
> >>>>> [000019f2] 55             push ebp
> >>>>> [000019f3] 8bec           mov ebp,esp
> >>>>> [000019f5] 68d2190000     push 000019d2
> >>>>> [000019fa] 68d2190000     push 000019d2
> >>>>> [000019ff] e88ef9ffff     call 00001392
> >>>>> [00001a04] 83c408         add esp,+08
> >>>>> [00001a07] 50             push eax
> >>>>> [00001a08] 6893060000     push 00000693
> >>>>> [00001a0d] e8a0ecffff     call 000006b2
> >>>>> [00001a12] 83c408         add esp,+08
> >>>>> [00001a15] 33c0           xor eax,eax
> >>>>> [00001a17] 5d             pop ebp
> >>>>> [00001a18] c3             ret
> >>>>> Size in bytes:(0039) [00001a18]
> >>>>>
> >>>>>   machine   stack     stack     machine    assembly
> >>>>>   address   address   data      code       language
> >>>>>   ========  ========  ========  =========  ============> >>>>> [000019f2][00102a7c][00000000] 55         push ebp
> >>>>> [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
> >>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push
> >>>>> E [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 //
> >>>>> push E [000019ff][00102a70][00001a04] e88ef9ffff call 00001392
> >>>>> // call H
> >>>>>
> >>>>> H: Begin Simulation   Execution Trace Stored at:112b28
> >>>>> Address_of_H:1392
> >>>>> [000019d2][00112b14][00112b18] 55         push ebp
> >>>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
> >>>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
> >>>>> [000019d8][00112b10][000019d2] 50         push eax         //
> >>>>> push E [000019d9][00112b10][000019d2] 8b4d08     mov
> >>>>> ecx,[ebp+08] [000019dc][00112b0c][000019d2] 51         push ecx
> >>>>>         // push E [000019dd][00112b08][000019e2] e8b0f9ffff
> >>>>> call 00001392 // call H H: Infinitely Recursive Simulation
> >>>>> Detected Simulation Stopped
> >>>>>
> >>>>> H correctly reports that E correctly simulated by H cannot
> >>>>> possibly reach its own final state at machine address [000019e6]
> >>>>> and terminate normally in 1 to ∞ steps of correct simulation.
> >>>>>
> >>>>>
> >>>>
> >>>> So you are just admitting you don't understand the Halting
> >>>> Criteria.
> >>>>
> >>>> The fact that H stops its simulation before it gets to the end
> >>>> does NOT prove that the machine being simulated, or a correct and
> >>>> complete simultion of the input would be non-halting.
> >>> We must handle only one point at a time because you are easily
> >>> overwhelmed. You usually cannot even handle one point at a time
> >>> until this point is repeated 20 or more times.
> >>>
> >>> The fact that the line-by-line execution trace of the first seven
> >>> instructions E simulated by H exactly match the behavior specified
> >>> by the first seven instructions of the x86 source-code of E
> >>> conclusively proves that these first seven instructions are
> >>> simulated correctly.
> >>
> >> No, that says that H did a correct PARTIAL simulation of the input.
> >> You seem to be INTENTIONALLY using deceptive terminology to spread
> >> you lies.
> >>
> >> So, I suppose you can correctly say that the input doesn't stop
> >> within its first 7 instructions, but that doesn't mean anything.
> >>
> >> Since you make a claim about a COMPLETE simulation (the it will
> >> never end) you need to establish THAT fact (and you can't change
> >> the input to do it, which includes the H the E calls).
> >>
> >> YOU FAIL
> >>
> >> You show that you don't understand what you are talking about and
> >> seem to actually think that you are proving something by using
> >> wrong defintions.
> >>
> >> You are just showing how stupid you are.
> >
> > Again with the ad hominem attacks: "liar", "stupid" etc. You are
> > not very good at his are you, Mr Damon.
> >
> > /Flibble
> >
>
> So, you don't understand the meaning of ad hominem. The fallacy of
> ad-hominem is to say the person must be wrong because they are a "X".
> That is not what my statement is, but that he is wrong for a
> specified logical reason. I then point out that BECAUSE he is stating
> these incorrect statements, he is a liar and stupid. That is a valid
> logical deduction.
>
> YOU are showing you lack of understanding.


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<tkoskf$17pff$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic
Subject: Re: Simulating halt decider applied to a simpler input
Date: Sat, 12 Nov 2022 13:36:46 -0600
Organization: A noiseless patient Spider
Lines: 437
Message-ID: <tkoskf$17pff$1@dont-email.me>
References: <tklpng$shkk$1@dont-email.me>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
<6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me>
<_9RbL.5611$gBW5.2085@fx06.iad> <tkonum$17cpp$1@dont-email.me>
<7xRbL.11594$o6Z5.1319@fx07.iad> <tkopjk$fah$1@gioia.aioe.org>
<90SbL.14321$%VI9.7406@fx34.iad> <tkoqo1$ta1$1@gioia.aioe.org>
<LmSbL.74300$Jjx8.17367@fx15.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 12 Nov 2022 19:36:47 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="d8c82b31b36f6d47fb6bf54a1e329d6a";
logging-data="1304047"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19xCc+JJ7JzcEyqlBUdRcsM"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.4.2
Cancel-Lock: sha1:4YDgZmtvJWA51+efjYGi93nIEYU=
Content-Language: en-US
In-Reply-To: <LmSbL.74300$Jjx8.17367@fx15.iad>
 by: olcott - Sat, 12 Nov 2022 19:36 UTC

On 11/12/2022 1:21 PM, Richard Damon wrote:
> On 11/12/22 2:04 PM, olcott wrote:
>> On 11/12/2022 12:57 PM, Richard Damon wrote:
>>> On 11/12/22 1:45 PM, olcott wrote:
>>>> On 11/12/2022 12:24 PM, Richard Damon wrote:
>>>>> On 11/12/22 1:16 PM, olcott wrote:
>>>>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has
>>>>>>>>>>>>>>>>>>>>>>>>>>> blocked you
>>>>>>>>>>>>>>>>>>>>>>>>>>> and I would have thought given your
>>>>>>>>>>>>>>>>>>>>>>>>>>> intelligence you
>>>>>>>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to
>>>>>>>>>>>>>>>>>>>>>>>>>> respond to
>>>>>>>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if
>>>>>>>>>>>>>>>>>>>>>>>>>> he has
>>>>>>>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into
>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around
>>>>>>>>>>>>>>>>>>>>>>>>>> to point
>>>>>>>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know
>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing
>>>>>>>>>>>>>>>>>>>>>>>>>> the Truth.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
>>>>>>>>>>>>>>>>>>>>>>>>>> that he
>>>>>>>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking
>>>>>>>>>>>>>>>>>>>>>>>>>> about, and
>>>>>>>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors
>>>>>>>>>>>>>>>>>>>>>>>>>> become
>>>>>>>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this,
>>>>>>>>>>>>>>>>>>>>>>>>> yet naive
>>>>>>>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
>>>>>>>>>>>>>>>>>>>>>>>> Halting
>>>>>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis
>>>>>>>>>>>>>>>>>>>>>>> for its
>>>>>>>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
>>>>>>>>>>>>>>>>>>>>> shell
>>>>>>>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
>>>>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion,
>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct
>>>>>>>>>>>>>>>>>>>> simulation, so any
>>>>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>>>>>> category error present in the proof; what Olcott is
>>>>>>>>>>>>>>>>>>> getting
>>>>>>>>>>>>>>>>>>> wrong is the mapping of the need to abort the
>>>>>>>>>>>>>>>>>>> simulation to a
>>>>>>>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be
>>>>>>>>>>>>>>>>>>> mapped to
>>>>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
>>>>>>>>>>>>>>>>>> it, not a
>>>>>>>>>>>>>>>>>> "reference" to it. Turing Machines do not have the
>>>>>>>>>>>>>>>>>> power to
>>>>>>>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
>>>>>>>>>>>>>>>>> copies
>>>>>>>>>>>>>>>>> all the way down so is the same category error
>>>>>>>>>>>>>>>>> manifesting in a
>>>>>>>>>>>>>>>>> different way.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case
>>>>>>>>>>>>>>>> it isn't
>>>>>>>>>>>>>>>> actually a decider.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>>>>> "Impossible"
>>>>>>>>>>>>>>>> program is simple to make from it, and is given one copy
>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When run it makes a second copy of its description, and
>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>> calls the decider.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> After that, it is the deciders job to make the decision
>>>>>>>>>>>>>>>> in finite
>>>>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The proof shows that what ever answer the decider does
>>>>>>>>>>>>>>>> give (if
>>>>>>>>>>>>>>>> it gives one) will be wrong, and thus the decider
>>>>>>>>>>>>>>>> doesn't meet
>>>>>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>>>>> given a
>>>>>>>>>>>>>>>> copy of something that just happens to be its own
>>>>>>>>>>>>>>>> description.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The only place we get any form of "Reference", is when
>>>>>>>>>>>>>>>> we try to
>>>>>>>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge.
>>>>>>>>>>>>>>>> There the
>>>>>>>>>>>>>>>> effect of the Self-Reference just lets us see that the
>>>>>>>>>>>>>>>> task turns
>>>>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>>>>>> halting
>>>>>>>>>>>>>>> problem proofs based on [Strachey 1965] the program is
>>>>>>>>>>>>>>> impossible
>>>>>>>>>>>>>>> not due to self reference or infinite copies but because
>>>>>>>>>>>>>>> the input
>>>>>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>>>>>> category
>>>>>>>>>>>>>>> error that I have identified is different: it is an error
>>>>>>>>>>>>>>> of self
>>>>>>>>>>>>>>> reference and/or infinite copies; it is an error related
>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>> fact that the input references a decider rather than
>>>>>>>>>>>>>>> being related
>>>>>>>>>>>>>>> to what the input does with the decision result of a
>>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
>>>>>>>>>>>>>> handle
>>>>>>>>>>>>>> ANY input and answer in finite time, If an input causes it
>>>>>>>>>>>>>> to make
>>>>>>>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>>>>>>>> requirements.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on
>>>>>>>>>>>>>> another Turing
>>>>>>>>>>>>>> Machine as a base. The only reason it wouldn't be allowed
>>>>>>>>>>>>>> is if H
>>>>>>>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category
>>>>>>>>>>>>>> error
>>>>>>>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>>>>>>> admitting that your H can't actually be a Turing Machine,
>>>>>>>>>>>>>> but must
>>>>>>>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>>>>>>>> requirement to be the needed decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>>>>> down: yet
>>>>>>>>>>>>> another manifestation of the category error I have identified.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>>>>>> either H
>>>>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>>>>> sequence of
>>>>>>>>>>>> simulations we have just shown that H was defective because
>>>>>>>>>>>> it failed
>>>>>>>>>>>> to answer in finite time.
>>>>>>>>>>>>
>>>>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>>>>
>>>>>>>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>>>>>>>> representation on the tape, and two is much smaller than
>>>>>>>>>>>> infinity.
>>>>>>>>>>>
>>>>>>>>>>> Nope, if,
>>>>>>>>>>>
>>>>>>>>>>> a) H is a copy, and
>>>>>>>>>>> b) H is a Turing Machine, and
>>>>>>>>>>> c) D is an input into H, and
>>>>>>>>>>> d) D references H, and
>>>>>>>>>>> e) H references D,
>>>>>>>>>>>
>>>>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite
>>>>>>>>>>> Turing Machines
>>>>>>>>>>> all the way down: a manifestation of the category error I have
>>>>>>>>>>> identified.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> void E(void (*x)())
>>>>>>>>>> {
>>>>>>>>>>    H(x, x);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> The point is
>>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>>> correct simulation.
>>>>>>>>>>
>>>>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>>>>
>>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>>> correct simulation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Except D is NOT correctly simulated by H, so that is a
>>>>>>>>> incorrect statement. When it is correctly simulated by
>>>>>>>>> something other than H, it will come to a final state, showing
>>>>>>>>> your statement is wrong.
>>>>>>>> In order for the simulation to actually be incorrect the
>>>>>>>> execution trace of the simulated E must diverge from the
>>>>>>>> behavior that the line-by-line x86 source-code of E specifies.
>>>>>>>
>>>>>>> Right, and since you simulation does NOT continue past the call
>>>>>>> to H, it is "incorrect" in the sense that the actual code does
>>>>>>> continue past that point, so it does not actually match the
>>>>>>> behavior of that machine.
>>>>>>>
>>>>>>>>
>>>>>>>> The first seven lines of the execution trace of the simulated E
>>>>>>>> exactly match the behavior specified by the first seven lines of
>>>>>>>> the x86 source code of E. This conclusively proves beyond all
>>>>>>>> possible doubt that these first seven lines have been simulated
>>>>>>>> correctly.
>>>>>>>
>>>>>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>>>>>> which does NOT prove the input is non-halting.
>>>>>>>
>>>>>>>>
>>>>>>>> *H correctly determines that E never halts*
>>>>>>>>
>>>>>>>> void E(void (*x)())
>>>>>>>> {
>>>>>>>>    H(x, x);
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>    Output("Input_Halts = ", H(E, E));
>>>>>>>> }
>>>>>>>>
>>>>>>>> _E()
>>>>>>>> [000019d2] 55             push ebp
>>>>>>>> [000019d3] 8bec           mov ebp,esp
>>>>>>>> [000019d5] 8b4508         mov eax,[ebp+08]
>>>>>>>> [000019d8] 50             push eax
>>>>>>>> [000019d9] 8b4d08         mov ecx,[ebp+08]
>>>>>>>> [000019dc] 51             push ecx
>>>>>>>> [000019dd] e8b0f9ffff     call 00001392
>>>>>>>> [000019e2] 83c408         add esp,+08
>>>>>>>> [000019e5] 5d             pop ebp
>>>>>>>> [000019e6] c3             ret
>>>>>>>> Size in bytes:(0021) [000019e6]
>>>>>>>>
>>>>>>>> _main()
>>>>>>>> [000019f2] 55             push ebp
>>>>>>>> [000019f3] 8bec           mov ebp,esp
>>>>>>>> [000019f5] 68d2190000     push 000019d2
>>>>>>>> [000019fa] 68d2190000     push 000019d2
>>>>>>>> [000019ff] e88ef9ffff     call 00001392
>>>>>>>> [00001a04] 83c408         add esp,+08
>>>>>>>> [00001a07] 50             push eax
>>>>>>>> [00001a08] 6893060000     push 00000693
>>>>>>>> [00001a0d] e8a0ecffff     call 000006b2
>>>>>>>> [00001a12] 83c408         add esp,+08
>>>>>>>> [00001a15] 33c0           xor eax,eax
>>>>>>>> [00001a17] 5d             pop ebp
>>>>>>>> [00001a18] c3             ret
>>>>>>>> Size in bytes:(0039) [00001a18]
>>>>>>>>
>>>>>>>>   machine   stack     stack     machine    assembly
>>>>>>>>   address   address   data      code       language
>>>>>>>>   ========  ========  ========  =========  =============
>>>>>>>> [000019f2][00102a7c][00000000] 55         push ebp
>>>>>>>> [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
>>>>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>>>>>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>>>>>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>>>>>>
>>>>>>>> H: Begin Simulation   Execution Trace Stored at:112b28
>>>>>>>> Address_of_H:1392
>>>>>>>> [000019d2][00112b14][00112b18] 55         push ebp
>>>>>>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>>>>>>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>>>>>>>> [000019d8][00112b10][000019d2] 50         push eax         //
>>>>>>>> push E
>>>>>>>> [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
>>>>>>>> [000019dc][00112b0c][000019d2] 51         push ecx         //
>>>>>>>> push E
>>>>>>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    //
>>>>>>>> call H
>>>>>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>
>>>>>>>> H correctly reports that E correctly simulated by H cannot
>>>>>>>> possibly reach its own final state at machine address [000019e6]
>>>>>>>> and terminate normally in 1 to ∞ steps of correct simulation.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> So you are just admitting you don't understand the Halting Criteria.
>>>>>>>
>>>>>>> The fact that H stops its simulation before it gets to the end
>>>>>>> does NOT prove that the machine being simulated, or a correct and
>>>>>>> complete simultion of the input would be non-halting.
>>>>>> We must handle only one point at a time because you are easily
>>>>>> overwhelmed. You usually cannot even handle one point at a time
>>>>>> until this point is repeated 20 or more times.
>>>>>>
>>>>>> The fact that the line-by-line execution trace of the first seven
>>>>>> instructions E simulated by H exactly match the behavior specified
>>>>>> by the first seven instructions of the x86 source-code of E
>>>>>> conclusively proves that these first seven instructions are
>>>>>> simulated correctly.
>>>>>>
>>>>>
>>>>> No, that says that H did a correct PARTIAL simulation of the input.
>>>>
>>>> Yes that is correct now we can move on to the next point.
>>>>
>>>> void E(void (*x)())
>>>> {
>>>>    H(x, x);
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H(E, E));
>>>> }
>>>>
>>>> H: Begin Simulation   Execution Trace Stored at:112b28
>>>> Address_of_H:1392
>>>> [000019d2][00112b14][00112b18] 55         push ebp
>>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>>>> [000019d8][00112b10][000019d2] 50         push eax         // push E
>>>> [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
>>>> [000019dc][00112b0c][000019d2] 51         push ecx         // push E
>>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    // call H
>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>
>>>> We can see that the seventh instruction of E correctly simulated by
>>>> H would call H to simulate itself again.
>>>
>>> No, E calls H which will HALT DECIDER (by simulation) its input.
>> Try again this time don't use a noun as a verb gibberish.
>>
>
> So you can't understand that the call to H is supposed to Halt Decide
> its input?
>
> Minor typo, not gibberish like what you post that might follow correct
> syntax but has a lack of semantics.
>
> Do you agree that H(E,E) does return 0 when called?


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<tkosme$1qpn$1@gioia.aioe.org>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!aioe.org!/maIWMVc/1untnACPzZ7XA.user.46.165.242.91.POSTED!not-for-mail
From: none...@beez-waxes.com (olcott)
Newsgroups: comp.theory,sci.logic
Subject: Re: Simulating halt decider applied to a simpler input
Date: Sat, 12 Nov 2022 13:37:49 -0600
Organization: Aioe.org NNTP Server
Message-ID: <tkosme$1qpn$1@gioia.aioe.org>
References: <tklpng$shkk$1@dont-email.me>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
<6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me>
<_9RbL.5611$gBW5.2085@fx06.iad> <tkonum$17cpp$1@dont-email.me>
<7xRbL.11594$o6Z5.1319@fx07.iad> <20221112184207.000004d1@reddwarf.jmc.corp>
<d3SbL.14322$%VI9.13847@fx34.iad> <20221112192618.00003dec@reddwarf.jmc.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="60215"; posting-host="/maIWMVc/1untnACPzZ7XA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.4.2
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.9.2
 by: olcott - Sat, 12 Nov 2022 19:37 UTC

On 11/12/2022 1:26 PM, Mr Flibble wrote:
> On Sat, 12 Nov 2022 14:00:21 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 11/12/22 1:42 PM, Mr Flibble wrote:
>>> On Sat, 12 Nov 2022 13:24:00 -0500
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 11/12/22 1:16 PM, olcott wrote:
>>>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has
>>>>>>>>>>>>>>>>>>>>>>>>>> blocked you and I would have thought given
>>>>>>>>>>>>>>>>>>>>>>>>>> your intelligence you would also understand
>>>>>>>>>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>>>>>> mostly ignores me.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to
>>>>>>>>>>>>>>>>>>>>>>>>> respond to what I say, even if not in a
>>>>>>>>>>>>>>>>>>>>>>>>> direct reply,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if
>>>>>>>>>>>>>>>>>>>>>>>>> he has blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into
>>>>>>>>>>>>>>>>>>>>>>>>> the archives, I want enough evidence to be
>>>>>>>>>>>>>>>>>>>>>>>>> around to point out his errors.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know
>>>>>>>>>>>>>>>>>>>>>>>>> and provide reasoning behind the claims,
>>>>>>>>>>>>>>>>>>>>>>>>> showing the Truth.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
>>>>>>>>>>>>>>>>>>>>>>>>> that he doesn't actually know what he is
>>>>>>>>>>>>>>>>>>>>>>>>> talking about, and reveals his ignorance. If
>>>>>>>>>>>>>>>>>>>>>>>>> he tries to put his explanation into explicit
>>>>>>>>>>>>>>>>>>>>>>>>> words, his errors become very apparent, I
>>>>>>>>>>>>>>>>>>>>>>>>> think even to him, so he just refuses.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your
>>>>>>>>>>>>>>>>>>>>>>>> only basis. Naive readers will never notice
>>>>>>>>>>>>>>>>>>>>>>>> this, yet naive readers are not in my target
>>>>>>>>>>>>>>>>>>>>>>>> audience.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
>>>>>>>>>>>>>>>>>>>>>>> Halting Decider.
>>>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>>>>>> Turing machine (UTM) knows that the behavior of D
>>>>>>>>>>>>>>>>>>>>>> correctly simulated by H provides H with a
>>>>>>>>>>>>>>>>>>>>>> correct basis for its halt status decision.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
>>>>>>>>>>>>>>>>>>>> shell game can correctly deny this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
>>>>>>>>>>>>>>>>>>> because the CORRECT simulation, as will the diret
>>>>>>>>>>>>>>>>>>> exectuion, will halt. Note, such an H doesn't do a
>>>>>>>>>>>>>>>>>>> correct simulation, so any
>>>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>>>> reference category error present in the proof; what
>>>>>>>>>>>>>>>>>> Olcott is getting wrong is the mapping of the need to
>>>>>>>>>>>>>>>>>> abort the simulation to a halt decision of
>>>>>>>>>>>>>>>>>> non-halting; it needs to instead be mapped to
>>>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
>>>>>>>>>>>>>>>>> it, not a "reference" to it. Turing Machines do not
>>>>>>>>>>>>>>>>> have the power to directly express a reference.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
>>>>>>>>>>>>>>>> copies all the way down so is the same category error
>>>>>>>>>>>>>>>> manifesting in a different way.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case
>>>>>>>>>>>>>>> it isn't actually a decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>>>> "Impossible" program is simple to make from it, and is
>>>>>>>>>>>>>>> given one copy of the description of itself, which is
>>>>>>>>>>>>>>> also simple to make.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When run it makes a second copy of its description, and
>>>>>>>>>>>>>>> then calls the decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> After that, it is the deciders job to make the decision
>>>>>>>>>>>>>>> in finite
>>>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in
>>>>>>>>>>>>>>> your infinite loop, the decider is just wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The proof shows that what ever answer the decider does
>>>>>>>>>>>>>>> give (if it gives one) will be wrong, and thus the
>>>>>>>>>>>>>>> decider doesn't meet the requirements.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>>>> given a copy of something that just happens to be its
>>>>>>>>>>>>>>> own description.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The only place we get any form of "Reference", is when
>>>>>>>>>>>>>>> we try to ANALYSE or DESIGN the H to try to meet the
>>>>>>>>>>>>>>> challenge. There the effect of the Self-Reference just
>>>>>>>>>>>>>>> lets us see that the task turns
>>>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>>>>> halting problem proofs based on [Strachey 1965] the
>>>>>>>>>>>>>> program is impossible not due to self reference or
>>>>>>>>>>>>>> infinite copies but because the input
>>>>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>>>>> category
>>>>>>>>>>>>>> error that I have identified is different: it is an error
>>>>>>>>>>>>>> of self reference and/or infinite copies; it is an error
>>>>>>>>>>>>>> related to the fact that the input references a decider
>>>>>>>>>>>>>> rather than being related
>>>>>>>>>>>>>> to what the input does with the decision result of a
>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
>>>>>>>>>>>>> handle ANY input and answer in finite time, If an input
>>>>>>>>>>>>> causes it to make infinite copies, then the decided just
>>>>>>>>>>>>> doesn't meet its requirements.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on
>>>>>>>>>>>>> another Turing Machine as a base. The only reason it
>>>>>>>>>>>>> wouldn't be allowed is if H isn't actually a Turing
>>>>>>>>>>>>> Machine, so it CAN'T be a category error if H is actualy
>>>>>>>>>>>>> a Turing Machine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> All your declaration of a "Category Error" here is doing
>>>>>>>>>>>>> is admitting that your H can't actually be a Turing
>>>>>>>>>>>>> Machine, but must be of a HIGHER order logic system,
>>>>>>>>>>>>> which means H fails the requirement to be the needed
>>>>>>>>>>>>> decider.
>>>>>>>>>>>>
>>>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>>>> down: yet
>>>>>>>>>>>> another manifestation of the category error I have
>>>>>>>>>>>> identified.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>>>>> either H
>>>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>>>> sequence of
>>>>>>>>>>> simulations we have just shown that H was defective because
>>>>>>>>>>> it failed
>>>>>>>>>>> to answer in finite time.
>>>>>>>>>>>
>>>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>>>
>>>>>>>>>>> Note, when we start H, there is exactly two machines present
>>>>>>>>>>> in representation on the tape, and two is much smaller than
>>>>>>>>>>> infinity.
>>>>>>>>>>
>>>>>>>>>> Nope, if,
>>>>>>>>>>
>>>>>>>>>> a) H is a copy, and
>>>>>>>>>> b) H is a Turing Machine, and
>>>>>>>>>> c) D is an input into H, and
>>>>>>>>>> d) D references H, and
>>>>>>>>>> e) H references D,
>>>>>>>>>>
>>>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite
>>>>>>>>>> Turing Machines
>>>>>>>>>> all the way down: a manifestation of the category error I
>>>>>>>>>> have identified.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> void E(void (*x)())
>>>>>>>>> {
>>>>>>>>>    H(x, x);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The point is
>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>> correct simulation.
>>>>>>>>>
>>>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>>>
>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>> correct simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except D is NOT correctly simulated by H, so that is a
>>>>>>>> incorrect statement. When it is correctly simulated by
>>>>>>>> something other than H, it will come to a final state, showing
>>>>>>>> your statement is wrong.
>>>>>>> In order for the simulation to actually be incorrect the
>>>>>>> execution trace of the simulated E must diverge from the
>>>>>>> behavior that the line-by-line x86 source-code of E specifies.
>>>>>>
>>>>>> Right, and since you simulation does NOT continue past the call
>>>>>> to H, it is "incorrect" in the sense that the actual code does
>>>>>> continue past that point, so it does not actually match the
>>>>>> behavior of that machine.
>>>>>>>
>>>>>>> The first seven lines of the execution trace of the simulated E
>>>>>>> exactly match the behavior specified by the first seven lines of
>>>>>>> the x86 source code of E. This conclusively proves beyond all
>>>>>>> possible doubt that these first seven lines have been simulated
>>>>>>> correctly.
>>>>>>
>>>>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>>>>> which does NOT prove the input is non-halting.
>>>>>>
>>>>>>>
>>>>>>> *H correctly determines that E never halts*
>>>>>>>
>>>>>>> void E(void (*x)())
>>>>>>> {
>>>>>>>    H(x, x);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ", H(E, E));
>>>>>>> }
>>>>>>>
>>>>>>> _E()
>>>>>>> [000019d2] 55             push ebp
>>>>>>> [000019d3] 8bec           mov ebp,esp
>>>>>>> [000019d5] 8b4508         mov eax,[ebp+08]
>>>>>>> [000019d8] 50             push eax
>>>>>>> [000019d9] 8b4d08         mov ecx,[ebp+08]
>>>>>>> [000019dc] 51             push ecx
>>>>>>> [000019dd] e8b0f9ffff     call 00001392
>>>>>>> [000019e2] 83c408         add esp,+08
>>>>>>> [000019e5] 5d             pop ebp
>>>>>>> [000019e6] c3             ret
>>>>>>> Size in bytes:(0021) [000019e6]
>>>>>>>
>>>>>>> _main()
>>>>>>> [000019f2] 55             push ebp
>>>>>>> [000019f3] 8bec           mov ebp,esp
>>>>>>> [000019f5] 68d2190000     push 000019d2
>>>>>>> [000019fa] 68d2190000     push 000019d2
>>>>>>> [000019ff] e88ef9ffff     call 00001392
>>>>>>> [00001a04] 83c408         add esp,+08
>>>>>>> [00001a07] 50             push eax
>>>>>>> [00001a08] 6893060000     push 00000693
>>>>>>> [00001a0d] e8a0ecffff     call 000006b2
>>>>>>> [00001a12] 83c408         add esp,+08
>>>>>>> [00001a15] 33c0           xor eax,eax
>>>>>>> [00001a17] 5d             pop ebp
>>>>>>> [00001a18] c3             ret
>>>>>>> Size in bytes:(0039) [00001a18]
>>>>>>>
>>>>>>>   machine   stack     stack     machine    assembly
>>>>>>>   address   address   data      code       language
>>>>>>>   ========  ========  ========  =========  =============
>>>>>>> [000019f2][00102a7c][00000000] 55         push ebp
>>>>>>> [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
>>>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push
>>>>>>> E [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 //
>>>>>>> push E [000019ff][00102a70][00001a04] e88ef9ffff call 00001392
>>>>>>> // call H
>>>>>>>
>>>>>>> H: Begin Simulation   Execution Trace Stored at:112b28
>>>>>>> Address_of_H:1392
>>>>>>> [000019d2][00112b14][00112b18] 55         push ebp
>>>>>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>>>>>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>>>>>>> [000019d8][00112b10][000019d2] 50         push eax         //
>>>>>>> push E [000019d9][00112b10][000019d2] 8b4d08     mov
>>>>>>> ecx,[ebp+08] [000019dc][00112b0c][000019d2] 51         push ecx
>>>>>>>         // push E [000019dd][00112b08][000019e2] e8b0f9ffff
>>>>>>> call 00001392 // call H H: Infinitely Recursive Simulation
>>>>>>> Detected Simulation Stopped
>>>>>>>
>>>>>>> H correctly reports that E correctly simulated by H cannot
>>>>>>> possibly reach its own final state at machine address [000019e6]
>>>>>>> and terminate normally in 1 to ∞ steps of correct simulation.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> So you are just admitting you don't understand the Halting
>>>>>> Criteria.
>>>>>>
>>>>>> The fact that H stops its simulation before it gets to the end
>>>>>> does NOT prove that the machine being simulated, or a correct and
>>>>>> complete simultion of the input would be non-halting.
>>>>> We must handle only one point at a time because you are easily
>>>>> overwhelmed. You usually cannot even handle one point at a time
>>>>> until this point is repeated 20 or more times.
>>>>>
>>>>> The fact that the line-by-line execution trace of the first seven
>>>>> instructions E simulated by H exactly match the behavior specified
>>>>> by the first seven instructions of the x86 source-code of E
>>>>> conclusively proves that these first seven instructions are
>>>>> simulated correctly.
>>>>
>>>> No, that says that H did a correct PARTIAL simulation of the input.
>>>> You seem to be INTENTIONALLY using deceptive terminology to spread
>>>> you lies.
>>>>
>>>> So, I suppose you can correctly say that the input doesn't stop
>>>> within its first 7 instructions, but that doesn't mean anything.
>>>>
>>>> Since you make a claim about a COMPLETE simulation (the it will
>>>> never end) you need to establish THAT fact (and you can't change
>>>> the input to do it, which includes the H the E calls).
>>>>
>>>> YOU FAIL
>>>>
>>>> You show that you don't understand what you are talking about and
>>>> seem to actually think that you are proving something by using
>>>> wrong defintions.
>>>>
>>>> You are just showing how stupid you are.
>>>
>>> Again with the ad hominem attacks: "liar", "stupid" etc. You are
>>> not very good at his are you, Mr Damon.
>>>
>>> /Flibble
>>>
>>
>> So, you don't understand the meaning of ad hominem. The fallacy of
>> ad-hominem is to say the person must be wrong because they are a "X".
>> That is not what my statement is, but that he is wrong for a
>> specified logical reason. I then point out that BECAUSE he is stating
>> these incorrect statements, he is a liar and stupid. That is a valid
>> logical deduction.
>>
>> YOU are showing you lack of understanding.
>
> I fully understand what constitutes an ad hominem; YOU are using a
> DISGUISED ad hominem by using insults after the fact in an attempt to
> strengthen your argument. A DISGUISED ad hominem is still an ad
> hominem if you use it as part of your argument, which you are.
>
> To be clear, if you called Olcott "big nose" rather than "stupid" then
> that would just be an insult however calling someone "stupid" implies
> you think they have a low IQ which is a characteristic that directly
> relates to their ability to argue/debate (unlike "big nose") and so is
> a logical fallacy, albeit a disguised one.
>
> /Flibble
>


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<xRSbL.52223$NeJ8.19045@fx09.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx09.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.2
Subject: Re: Simulating halt decider applied to a simpler input
Content-Language: en-US
Newsgroups: comp.theory,sci.logic
References: <tklpng$shkk$1@dont-email.me>
<20221111183638.000034b9@reddwarf.jmc.corp> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
<6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me>
<_9RbL.5611$gBW5.2085@fx06.iad> <tkonum$17cpp$1@dont-email.me>
<7xRbL.11594$o6Z5.1319@fx07.iad> <20221112184207.000004d1@reddwarf.jmc.corp>
<d3SbL.14322$%VI9.13847@fx34.iad> <20221112192618.00003dec@reddwarf.jmc.corp>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <20221112192618.00003dec@reddwarf.jmc.corp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 414
Message-ID: <xRSbL.52223$NeJ8.19045@fx09.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: Sat, 12 Nov 2022 14:54:01 -0500
X-Received-Bytes: 21162
 by: Richard Damon - Sat, 12 Nov 2022 19:54 UTC

On 11/12/22 2:26 PM, Mr Flibble wrote:
> On Sat, 12 Nov 2022 14:00:21 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 11/12/22 1:42 PM, Mr Flibble wrote:
>>> On Sat, 12 Nov 2022 13:24:00 -0500
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 11/12/22 1:16 PM, olcott wrote:
>>>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has
>>>>>>>>>>>>>>>>>>>>>>>>>> blocked you and I would have thought given
>>>>>>>>>>>>>>>>>>>>>>>>>> your intelligence you would also understand
>>>>>>>>>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>>>>>> mostly ignores me.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to
>>>>>>>>>>>>>>>>>>>>>>>>> respond to what I say, even if not in a
>>>>>>>>>>>>>>>>>>>>>>>>> direct reply,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if
>>>>>>>>>>>>>>>>>>>>>>>>> he has blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into
>>>>>>>>>>>>>>>>>>>>>>>>> the archives, I want enough evidence to be
>>>>>>>>>>>>>>>>>>>>>>>>> around to point out his errors.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know
>>>>>>>>>>>>>>>>>>>>>>>>> and provide reasoning behind the claims,
>>>>>>>>>>>>>>>>>>>>>>>>> showing the Truth.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
>>>>>>>>>>>>>>>>>>>>>>>>> that he doesn't actually know what he is
>>>>>>>>>>>>>>>>>>>>>>>>> talking about, and reveals his ignorance. If
>>>>>>>>>>>>>>>>>>>>>>>>> he tries to put his explanation into explicit
>>>>>>>>>>>>>>>>>>>>>>>>> words, his errors become very apparent, I
>>>>>>>>>>>>>>>>>>>>>>>>> think even to him, so he just refuses.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your
>>>>>>>>>>>>>>>>>>>>>>>> only basis. Naive readers will never notice
>>>>>>>>>>>>>>>>>>>>>>>> this, yet naive readers are not in my target
>>>>>>>>>>>>>>>>>>>>>>>> audience.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
>>>>>>>>>>>>>>>>>>>>>>> Halting Decider.
>>>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>>>>>> Turing machine (UTM) knows that the behavior of D
>>>>>>>>>>>>>>>>>>>>>> correctly simulated by H provides H with a
>>>>>>>>>>>>>>>>>>>>>> correct basis for its halt status decision.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
>>>>>>>>>>>>>>>>>>>> shell game can correctly deny this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
>>>>>>>>>>>>>>>>>>> because the CORRECT simulation, as will the diret
>>>>>>>>>>>>>>>>>>> exectuion, will halt. Note, such an H doesn't do a
>>>>>>>>>>>>>>>>>>> correct simulation, so any
>>>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>>>> reference category error present in the proof; what
>>>>>>>>>>>>>>>>>> Olcott is getting wrong is the mapping of the need to
>>>>>>>>>>>>>>>>>> abort the simulation to a halt decision of
>>>>>>>>>>>>>>>>>> non-halting; it needs to instead be mapped to
>>>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
>>>>>>>>>>>>>>>>> it, not a "reference" to it. Turing Machines do not
>>>>>>>>>>>>>>>>> have the power to directly express a reference.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
>>>>>>>>>>>>>>>> copies all the way down so is the same category error
>>>>>>>>>>>>>>>> manifesting in a different way.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case
>>>>>>>>>>>>>>> it isn't actually a decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>>>> "Impossible" program is simple to make from it, and is
>>>>>>>>>>>>>>> given one copy of the description of itself, which is
>>>>>>>>>>>>>>> also simple to make.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When run it makes a second copy of its description, and
>>>>>>>>>>>>>>> then calls the decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> After that, it is the deciders job to make the decision
>>>>>>>>>>>>>>> in finite
>>>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in
>>>>>>>>>>>>>>> your infinite loop, the decider is just wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The proof shows that what ever answer the decider does
>>>>>>>>>>>>>>> give (if it gives one) will be wrong, and thus the
>>>>>>>>>>>>>>> decider doesn't meet the requirements.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>>>> given a copy of something that just happens to be its
>>>>>>>>>>>>>>> own description.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The only place we get any form of "Reference", is when
>>>>>>>>>>>>>>> we try to ANALYSE or DESIGN the H to try to meet the
>>>>>>>>>>>>>>> challenge. There the effect of the Self-Reference just
>>>>>>>>>>>>>>> lets us see that the task turns
>>>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>>>>> halting problem proofs based on [Strachey 1965] the
>>>>>>>>>>>>>> program is impossible not due to self reference or
>>>>>>>>>>>>>> infinite copies but because the input
>>>>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>>>>> category
>>>>>>>>>>>>>> error that I have identified is different: it is an error
>>>>>>>>>>>>>> of self reference and/or infinite copies; it is an error
>>>>>>>>>>>>>> related to the fact that the input references a decider
>>>>>>>>>>>>>> rather than being related
>>>>>>>>>>>>>> to what the input does with the decision result of a
>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
>>>>>>>>>>>>> handle ANY input and answer in finite time, If an input
>>>>>>>>>>>>> causes it to make infinite copies, then the decided just
>>>>>>>>>>>>> doesn't meet its requirements.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on
>>>>>>>>>>>>> another Turing Machine as a base. The only reason it
>>>>>>>>>>>>> wouldn't be allowed is if H isn't actually a Turing
>>>>>>>>>>>>> Machine, so it CAN'T be a category error if H is actualy
>>>>>>>>>>>>> a Turing Machine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> All your declaration of a "Category Error" here is doing
>>>>>>>>>>>>> is admitting that your H can't actually be a Turing
>>>>>>>>>>>>> Machine, but must be of a HIGHER order logic system,
>>>>>>>>>>>>> which means H fails the requirement to be the needed
>>>>>>>>>>>>> decider.
>>>>>>>>>>>>
>>>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>>>> down: yet
>>>>>>>>>>>> another manifestation of the category error I have
>>>>>>>>>>>> identified.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>>>>> either H
>>>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>>>> sequence of
>>>>>>>>>>> simulations we have just shown that H was defective because
>>>>>>>>>>> it failed
>>>>>>>>>>> to answer in finite time.
>>>>>>>>>>>
>>>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>>>
>>>>>>>>>>> Note, when we start H, there is exactly two machines present
>>>>>>>>>>> in representation on the tape, and two is much smaller than
>>>>>>>>>>> infinity.
>>>>>>>>>>
>>>>>>>>>> Nope, if,
>>>>>>>>>>
>>>>>>>>>> a) H is a copy, and
>>>>>>>>>> b) H is a Turing Machine, and
>>>>>>>>>> c) D is an input into H, and
>>>>>>>>>> d) D references H, and
>>>>>>>>>> e) H references D,
>>>>>>>>>>
>>>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite
>>>>>>>>>> Turing Machines
>>>>>>>>>> all the way down: a manifestation of the category error I
>>>>>>>>>> have identified.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> void E(void (*x)())
>>>>>>>>> {
>>>>>>>>>    H(x, x);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The point is
>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>> correct simulation.
>>>>>>>>>
>>>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>>>
>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>> correct simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except D is NOT correctly simulated by H, so that is a
>>>>>>>> incorrect statement. When it is correctly simulated by
>>>>>>>> something other than H, it will come to a final state, showing
>>>>>>>> your statement is wrong.
>>>>>>> In order for the simulation to actually be incorrect the
>>>>>>> execution trace of the simulated E must diverge from the
>>>>>>> behavior that the line-by-line x86 source-code of E specifies.
>>>>>>
>>>>>> Right, and since you simulation does NOT continue past the call
>>>>>> to H, it is "incorrect" in the sense that the actual code does
>>>>>> continue past that point, so it does not actually match the
>>>>>> behavior of that machine.
>>>>>>>
>>>>>>> The first seven lines of the execution trace of the simulated E
>>>>>>> exactly match the behavior specified by the first seven lines of
>>>>>>> the x86 source code of E. This conclusively proves beyond all
>>>>>>> possible doubt that these first seven lines have been simulated
>>>>>>> correctly.
>>>>>>
>>>>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>>>>> which does NOT prove the input is non-halting.
>>>>>>
>>>>>>>
>>>>>>> *H correctly determines that E never halts*
>>>>>>>
>>>>>>> void E(void (*x)())
>>>>>>> {
>>>>>>>    H(x, x);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ", H(E, E));
>>>>>>> }
>>>>>>>
>>>>>>> _E()
>>>>>>> [000019d2] 55             push ebp
>>>>>>> [000019d3] 8bec           mov ebp,esp
>>>>>>> [000019d5] 8b4508         mov eax,[ebp+08]
>>>>>>> [000019d8] 50             push eax
>>>>>>> [000019d9] 8b4d08         mov ecx,[ebp+08]
>>>>>>> [000019dc] 51             push ecx
>>>>>>> [000019dd] e8b0f9ffff     call 00001392
>>>>>>> [000019e2] 83c408         add esp,+08
>>>>>>> [000019e5] 5d             pop ebp
>>>>>>> [000019e6] c3             ret
>>>>>>> Size in bytes:(0021) [000019e6]
>>>>>>>
>>>>>>> _main()
>>>>>>> [000019f2] 55             push ebp
>>>>>>> [000019f3] 8bec           mov ebp,esp
>>>>>>> [000019f5] 68d2190000     push 000019d2
>>>>>>> [000019fa] 68d2190000     push 000019d2
>>>>>>> [000019ff] e88ef9ffff     call 00001392
>>>>>>> [00001a04] 83c408         add esp,+08
>>>>>>> [00001a07] 50             push eax
>>>>>>> [00001a08] 6893060000     push 00000693
>>>>>>> [00001a0d] e8a0ecffff     call 000006b2
>>>>>>> [00001a12] 83c408         add esp,+08
>>>>>>> [00001a15] 33c0           xor eax,eax
>>>>>>> [00001a17] 5d             pop ebp
>>>>>>> [00001a18] c3             ret
>>>>>>> Size in bytes:(0039) [00001a18]
>>>>>>>
>>>>>>>   machine   stack     stack     machine    assembly
>>>>>>>   address   address   data      code       language
>>>>>>>   ========  ========  ========  =========  =============
>>>>>>> [000019f2][00102a7c][00000000] 55         push ebp
>>>>>>> [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
>>>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push
>>>>>>> E [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 //
>>>>>>> push E [000019ff][00102a70][00001a04] e88ef9ffff call 00001392
>>>>>>> // call H
>>>>>>>
>>>>>>> H: Begin Simulation   Execution Trace Stored at:112b28
>>>>>>> Address_of_H:1392
>>>>>>> [000019d2][00112b14][00112b18] 55         push ebp
>>>>>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>>>>>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>>>>>>> [000019d8][00112b10][000019d2] 50         push eax         //
>>>>>>> push E [000019d9][00112b10][000019d2] 8b4d08     mov
>>>>>>> ecx,[ebp+08] [000019dc][00112b0c][000019d2] 51         push ecx
>>>>>>>         // push E [000019dd][00112b08][000019e2] e8b0f9ffff
>>>>>>> call 00001392 // call H H: Infinitely Recursive Simulation
>>>>>>> Detected Simulation Stopped
>>>>>>>
>>>>>>> H correctly reports that E correctly simulated by H cannot
>>>>>>> possibly reach its own final state at machine address [000019e6]
>>>>>>> and terminate normally in 1 to ∞ steps of correct simulation.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> So you are just admitting you don't understand the Halting
>>>>>> Criteria.
>>>>>>
>>>>>> The fact that H stops its simulation before it gets to the end
>>>>>> does NOT prove that the machine being simulated, or a correct and
>>>>>> complete simultion of the input would be non-halting.
>>>>> We must handle only one point at a time because you are easily
>>>>> overwhelmed. You usually cannot even handle one point at a time
>>>>> until this point is repeated 20 or more times.
>>>>>
>>>>> The fact that the line-by-line execution trace of the first seven
>>>>> instructions E simulated by H exactly match the behavior specified
>>>>> by the first seven instructions of the x86 source-code of E
>>>>> conclusively proves that these first seven instructions are
>>>>> simulated correctly.
>>>>
>>>> No, that says that H did a correct PARTIAL simulation of the input.
>>>> You seem to be INTENTIONALLY using deceptive terminology to spread
>>>> you lies.
>>>>
>>>> So, I suppose you can correctly say that the input doesn't stop
>>>> within its first 7 instructions, but that doesn't mean anything.
>>>>
>>>> Since you make a claim about a COMPLETE simulation (the it will
>>>> never end) you need to establish THAT fact (and you can't change
>>>> the input to do it, which includes the H the E calls).
>>>>
>>>> YOU FAIL
>>>>
>>>> You show that you don't understand what you are talking about and
>>>> seem to actually think that you are proving something by using
>>>> wrong defintions.
>>>>
>>>> You are just showing how stupid you are.
>>>
>>> Again with the ad hominem attacks: "liar", "stupid" etc. You are
>>> not very good at his are you, Mr Damon.
>>>
>>> /Flibble
>>>
>>
>> So, you don't understand the meaning of ad hominem. The fallacy of
>> ad-hominem is to say the person must be wrong because they are a "X".
>> That is not what my statement is, but that he is wrong for a
>> specified logical reason. I then point out that BECAUSE he is stating
>> these incorrect statements, he is a liar and stupid. That is a valid
>> logical deduction.
>>
>> YOU are showing you lack of understanding.
>
> I fully understand what constitutes an ad hominem; YOU are using a
> DISGUISED ad hominem by using insults after the fact in an attempt to
> strengthen your argument. A DISGUISED ad hominem is still an ad
> hominem if you use it as part of your argument, which you are.
>
> To be clear, if you called Olcott "big nose" rather than "stupid" then
> that would just be an insult however calling someone "stupid" implies
> you think they have a low IQ which is a characteristic that directly
> relates to their ability to argue/debate (unlike "big nose") and so is
> a logical fallacy, albeit a disguised one.
>
> /Flibble
>


Click here to read the complete article
Re: Simulating halt decider applied to a simpler input

<uYSbL.52225$NeJ8.20254@fx09.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx09.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.2
Subject: Re: Simulating halt decider applied to a simpler input
Content-Language: en-US
Newsgroups: comp.theory,sci.logic
References: <tklpng$shkk$1@dont-email.me> <qJwbL.64266$TUR8.24023@fx17.iad>
<tkm72m$tqg4$1@dont-email.me> <bpxbL.51553$Iwb3.1322@fx13.iad>
<tkm8da$tqg4$2@dont-email.me> <RQybL.5598$JSV9.869@fx35.iad>
<tkme1v$uio5$1@dont-email.me> <onzbL.5599$JSV9.2692@fx35.iad>
<20221111215433.00005425@reddwarf.jmc.corp>
<dSAbL.106246$U709.51175@fx16.iad>
<20221111235547.00006dba@reddwarf.jmc.corp> <sJBbL.13982$%VI9.876@fx34.iad>
<20221112140952.00005458@reddwarf.jmc.corp> <%7ObL.90222$2Rs3.40998@fx12.iad>
<20221112144113.00003674@reddwarf.jmc.corp> <AqObL.90223$2Rs3.77670@fx12.iad>
<20221112150316.000017ea@reddwarf.jmc.corp> <tkofba$16k3v$2@dont-email.me>
<6PPbL.71121$Jjx8.38057@fx15.iad> <tkojg4$172nl$2@dont-email.me>
<_9RbL.5611$gBW5.2085@fx06.iad> <tkonum$17cpp$1@dont-email.me>
<7xRbL.11594$o6Z5.1319@fx07.iad> <tkopjk$fah$1@gioia.aioe.org>
<90SbL.14321$%VI9.7406@fx34.iad> <tkoqo1$ta1$1@gioia.aioe.org>
<LmSbL.74300$Jjx8.17367@fx15.iad> <tkoskf$17pff$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tkoskf$17pff$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 470
Message-ID: <uYSbL.52225$NeJ8.20254@fx09.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: Sat, 12 Nov 2022 15:01:26 -0500
X-Received-Bytes: 23201
 by: Richard Damon - Sat, 12 Nov 2022 20:01 UTC

On 11/12/22 2:36 PM, olcott wrote:
> On 11/12/2022 1:21 PM, Richard Damon wrote:
>> On 11/12/22 2:04 PM, olcott wrote:
>>> On 11/12/2022 12:57 PM, Richard Damon wrote:
>>>> On 11/12/22 1:45 PM, olcott wrote:
>>>>> On 11/12/2022 12:24 PM, Richard Damon wrote:
>>>>>> On 11/12/22 1:16 PM, olcott wrote:
>>>>>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>>>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has
>>>>>>>>>>>>>>>>>>>>>>>>>>>> blocked you
>>>>>>>>>>>>>>>>>>>>>>>>>>>> and I would have thought given your
>>>>>>>>>>>>>>>>>>>>>>>>>>>> intelligence you
>>>>>>>>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me,
>>>>>>>>>>>>>>>>>>>>>>>>>>> just mostly
>>>>>>>>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to
>>>>>>>>>>>>>>>>>>>>>>>>>>> respond to
>>>>>>>>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if
>>>>>>>>>>>>>>>>>>>>>>>>>>> he has
>>>>>>>>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders
>>>>>>>>>>>>>>>>>>>>>>>>>>> into the
>>>>>>>>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around
>>>>>>>>>>>>>>>>>>>>>>>>>>> to point
>>>>>>>>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I
>>>>>>>>>>>>>>>>>>>>>>>>>>> know and
>>>>>>>>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing
>>>>>>>>>>>>>>>>>>>>>>>>>>> the Truth.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
>>>>>>>>>>>>>>>>>>>>>>>>>>> that he
>>>>>>>>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking
>>>>>>>>>>>>>>>>>>>>>>>>>>> about, and
>>>>>>>>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors
>>>>>>>>>>>>>>>>>>>>>>>>>>> become
>>>>>>>>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your
>>>>>>>>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this,
>>>>>>>>>>>>>>>>>>>>>>>>>> yet naive
>>>>>>>>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
>>>>>>>>>>>>>>>>>>>>>>>>> Halting
>>>>>>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a
>>>>>>>>>>>>>>>>>>>>>>>> universal Turing
>>>>>>>>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D
>>>>>>>>>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis
>>>>>>>>>>>>>>>>>>>>>>>> for its
>>>>>>>>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent
>>>>>>>>>>>>>>>>>>>>>> the infinite
>>>>>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting.
>>>>>>>>>>>>>>>>>>>>>> No shell
>>>>>>>>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
>>>>>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>>>>> the CORRECT simulation, as will the diret
>>>>>>>>>>>>>>>>>>>>> exectuion, will
>>>>>>>>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct
>>>>>>>>>>>>>>>>>>>>> simulation, so any
>>>>>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>>>>>>> category error present in the proof; what Olcott is
>>>>>>>>>>>>>>>>>>>> getting
>>>>>>>>>>>>>>>>>>>> wrong is the mapping of the need to abort the
>>>>>>>>>>>>>>>>>>>> simulation to a
>>>>>>>>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be
>>>>>>>>>>>>>>>>>>>> mapped to
>>>>>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
>>>>>>>>>>>>>>>>>>> it, not a
>>>>>>>>>>>>>>>>>>> "reference" to it. Turing Machines do not have the
>>>>>>>>>>>>>>>>>>> power to
>>>>>>>>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
>>>>>>>>>>>>>>>>>> copies
>>>>>>>>>>>>>>>>>> all the way down so is the same category error
>>>>>>>>>>>>>>>>>> manifesting in a
>>>>>>>>>>>>>>>>>> different way.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case
>>>>>>>>>>>>>>>>> it isn't
>>>>>>>>>>>>>>>>> actually a decider.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>>>>>> "Impossible"
>>>>>>>>>>>>>>>>> program is simple to make from it, and is given one
>>>>>>>>>>>>>>>>> copy of the
>>>>>>>>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When run it makes a second copy of its description, and
>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>> calls the decider.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> After that, it is the deciders job to make the decision
>>>>>>>>>>>>>>>>> in finite
>>>>>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in
>>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The proof shows that what ever answer the decider does
>>>>>>>>>>>>>>>>> give (if
>>>>>>>>>>>>>>>>> it gives one) will be wrong, and thus the decider
>>>>>>>>>>>>>>>>> doesn't meet
>>>>>>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>>>>>> given a
>>>>>>>>>>>>>>>>> copy of something that just happens to be its own
>>>>>>>>>>>>>>>>> description.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The only place we get any form of "Reference", is when
>>>>>>>>>>>>>>>>> we try to
>>>>>>>>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge.
>>>>>>>>>>>>>>>>> There the
>>>>>>>>>>>>>>>>> effect of the Self-Reference just lets us see that the
>>>>>>>>>>>>>>>>> task turns
>>>>>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You are fractally wrong on all fronts: in the
>>>>>>>>>>>>>>>> traditional halting
>>>>>>>>>>>>>>>> problem proofs based on [Strachey 1965] the program is
>>>>>>>>>>>>>>>> impossible
>>>>>>>>>>>>>>>> not due to self reference or infinite copies but because
>>>>>>>>>>>>>>>> the input
>>>>>>>>>>>>>>>> tries to do the opposite of what the decider decides;
>>>>>>>>>>>>>>>> the category
>>>>>>>>>>>>>>>> error that I have identified is different: it is an
>>>>>>>>>>>>>>>> error of self
>>>>>>>>>>>>>>>> reference and/or infinite copies; it is an error related
>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>> fact that the input references a decider rather than
>>>>>>>>>>>>>>>> being related
>>>>>>>>>>>>>>>> to what the input does with the decision result of a
>>>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
>>>>>>>>>>>>>>> handle
>>>>>>>>>>>>>>> ANY input and answer in finite time, If an input causes
>>>>>>>>>>>>>>> it to make
>>>>>>>>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>>>>>>>>> requirements.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on
>>>>>>>>>>>>>>> another Turing
>>>>>>>>>>>>>>> Machine as a base. The only reason it wouldn't be allowed
>>>>>>>>>>>>>>> is if H
>>>>>>>>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a
>>>>>>>>>>>>>>> category error
>>>>>>>>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>>>>>>>> admitting that your H can't actually be a Turing Machine,
>>>>>>>>>>>>>>> but must
>>>>>>>>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>>>>>>>>> requirement to be the needed decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>>>>>> down: yet
>>>>>>>>>>>>>> another manifestation of the category error I have
>>>>>>>>>>>>>> identified.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> Where are infinite machines? There is ONE machine being
>>>>>>>>>>>>> run, either H
>>>>>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>>>>>> sequence of
>>>>>>>>>>>>> simulations we have just shown that H was defective because
>>>>>>>>>>>>> it failed
>>>>>>>>>>>>> to answer in finite time.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Note, when we start H, there is exactly two machines
>>>>>>>>>>>>> present in
>>>>>>>>>>>>> representation on the tape, and two is much smaller than
>>>>>>>>>>>>> infinity.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, if,
>>>>>>>>>>>>
>>>>>>>>>>>> a) H is a copy, and
>>>>>>>>>>>> b) H is a Turing Machine, and
>>>>>>>>>>>> c) D is an input into H, and
>>>>>>>>>>>> d) D references H, and
>>>>>>>>>>>> e) H references D,
>>>>>>>>>>>>
>>>>>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite
>>>>>>>>>>>> Turing Machines
>>>>>>>>>>>> all the way down: a manifestation of the category error I have
>>>>>>>>>>>> identified.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>> {
>>>>>>>>>>>    H(x, x);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> The point is
>>>>>>>>>>> that D correctly simulated by H would never reach its own
>>>>>>>>>>> last instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>>>> correct simulation.
>>>>>>>>>>>
>>>>>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>>>>>
>>>>>>>>>>> that D correctly simulated by H would never reach its own
>>>>>>>>>>> last instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>>>> correct simulation.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Except D is NOT correctly simulated by H, so that is a
>>>>>>>>>> incorrect statement. When it is correctly simulated by
>>>>>>>>>> something other than H, it will come to a final state, showing
>>>>>>>>>> your statement is wrong.
>>>>>>>>> In order for the simulation to actually be incorrect the
>>>>>>>>> execution trace of the simulated E must diverge from the
>>>>>>>>> behavior that the line-by-line x86 source-code of E specifies.
>>>>>>>>
>>>>>>>> Right, and since you simulation does NOT continue past the call
>>>>>>>> to H, it is "incorrect" in the sense that the actual code does
>>>>>>>> continue past that point, so it does not actually match the
>>>>>>>> behavior of that machine.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The first seven lines of the execution trace of the simulated E
>>>>>>>>> exactly match the behavior specified by the first seven lines
>>>>>>>>> of the x86 source code of E. This conclusively proves beyond
>>>>>>>>> all possible doubt that these first seven lines have been
>>>>>>>>> simulated correctly.
>>>>>>>>
>>>>>>>> Right, so H has correctly done a PARTIAL simulation of its
>>>>>>>> input, which does NOT prove the input is non-halting.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> *H correctly determines that E never halts*
>>>>>>>>>
>>>>>>>>> void E(void (*x)())
>>>>>>>>> {
>>>>>>>>>    H(x, x);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>    Output("Input_Halts = ", H(E, E));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _E()
>>>>>>>>> [000019d2] 55             push ebp
>>>>>>>>> [000019d3] 8bec           mov ebp,esp
>>>>>>>>> [000019d5] 8b4508         mov eax,[ebp+08]
>>>>>>>>> [000019d8] 50             push eax
>>>>>>>>> [000019d9] 8b4d08         mov ecx,[ebp+08]
>>>>>>>>> [000019dc] 51             push ecx
>>>>>>>>> [000019dd] e8b0f9ffff     call 00001392
>>>>>>>>> [000019e2] 83c408         add esp,+08
>>>>>>>>> [000019e5] 5d             pop ebp
>>>>>>>>> [000019e6] c3             ret
>>>>>>>>> Size in bytes:(0021) [000019e6]
>>>>>>>>>
>>>>>>>>> _main()
>>>>>>>>> [000019f2] 55             push ebp
>>>>>>>>> [000019f3] 8bec           mov ebp,esp
>>>>>>>>> [000019f5] 68d2190000     push 000019d2
>>>>>>>>> [000019fa] 68d2190000     push 000019d2
>>>>>>>>> [000019ff] e88ef9ffff     call 00001392
>>>>>>>>> [00001a04] 83c408         add esp,+08
>>>>>>>>> [00001a07] 50             push eax
>>>>>>>>> [00001a08] 6893060000     push 00000693
>>>>>>>>> [00001a0d] e8a0ecffff     call 000006b2
>>>>>>>>> [00001a12] 83c408         add esp,+08
>>>>>>>>> [00001a15] 33c0           xor eax,eax
>>>>>>>>> [00001a17] 5d             pop ebp
>>>>>>>>> [00001a18] c3             ret
>>>>>>>>> Size in bytes:(0039) [00001a18]
>>>>>>>>>
>>>>>>>>>   machine   stack     stack     machine    assembly
>>>>>>>>>   address   address   data      code       language
>>>>>>>>>   ========  ========  ========  =========  =============
>>>>>>>>> [000019f2][00102a7c][00000000] 55         push ebp
>>>>>>>>> [000019f3][00102a7c][00000000] 8bec       mov ebp,esp
>>>>>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>>>>>>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>>>>>>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>>>>>>>
>>>>>>>>> H: Begin Simulation   Execution Trace Stored at:112b28
>>>>>>>>> Address_of_H:1392
>>>>>>>>> [000019d2][00112b14][00112b18] 55         push ebp
>>>>>>>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>>>>>>>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>>>>>>>>> [000019d8][00112b10][000019d2] 50         push eax         //
>>>>>>>>> push E
>>>>>>>>> [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
>>>>>>>>> [000019dc][00112b0c][000019d2] 51         push ecx         //
>>>>>>>>> push E
>>>>>>>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    //
>>>>>>>>> call H
>>>>>>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>
>>>>>>>>> H correctly reports that E correctly simulated by H cannot
>>>>>>>>> possibly reach its own final state at machine address
>>>>>>>>> [000019e6] and terminate normally in 1 to ∞ steps of correct
>>>>>>>>> simulation.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> So you are just admitting you don't understand the Halting
>>>>>>>> Criteria.
>>>>>>>>
>>>>>>>> The fact that H stops its simulation before it gets to the end
>>>>>>>> does NOT prove that the machine being simulated, or a correct
>>>>>>>> and complete simultion of the input would be non-halting.
>>>>>>> We must handle only one point at a time because you are easily
>>>>>>> overwhelmed. You usually cannot even handle one point at a time
>>>>>>> until this point is repeated 20 or more times.
>>>>>>>
>>>>>>> The fact that the line-by-line execution trace of the first seven
>>>>>>> instructions E simulated by H exactly match the behavior
>>>>>>> specified by the first seven instructions of the x86 source-code
>>>>>>> of E conclusively proves that these first seven instructions are
>>>>>>> simulated correctly.
>>>>>>>
>>>>>>
>>>>>> No, that says that H did a correct PARTIAL simulation of the input.
>>>>>
>>>>> Yes that is correct now we can move on to the next point.
>>>>>
>>>>> void E(void (*x)())
>>>>> {
>>>>>    H(x, x);
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H(E, E));
>>>>> }
>>>>>
>>>>> H: Begin Simulation   Execution Trace Stored at:112b28
>>>>> Address_of_H:1392
>>>>> [000019d2][00112b14][00112b18] 55         push ebp
>>>>> [000019d3][00112b14][00112b18] 8bec       mov ebp,esp
>>>>> [000019d5][00112b14][00112b18] 8b4508     mov eax,[ebp+08]
>>>>> [000019d8][00112b10][000019d2] 50         push eax         // push E
>>>>> [000019d9][00112b10][000019d2] 8b4d08     mov ecx,[ebp+08]
>>>>> [000019dc][00112b0c][000019d2] 51         push ecx         // push E
>>>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392    // call H
>>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>
>>>>> We can see that the seventh instruction of E correctly simulated by
>>>>> H would call H to simulate itself again.
>>>>
>>>> No, E calls H which will HALT DECIDER (by simulation) its input.
>>> Try again this time don't use a noun as a verb gibberish.
>>>
>>
>> So you can't understand that the call to H is supposed to Halt Decide
>> its input?
>>
>> Minor typo, not gibberish like what you post that might follow correct
>> syntax but has a lack of semantics.
>>
>> Do you agree that H(E,E) does return 0 when called?
>
> Again you leap ahead past the point at hand. Doing this makes sure that
> the point at hand is never addressed and you false assumptions continue.
>
> It is agreed that H does correctly simulate the first seven instructions
> of E.
>
> The first seven instructions of E correctly simulated by H show that E
> would call H to simulate itself again and that no instructions from the
> beginning of E to its call to H can possibly prevent this from repeating
> an unlimited number of times.
>


Click here to read the complete article

devel / comp.theory / Re: Simulating halt decider applied to a simpler input

Pages:1234567
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor