Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

A programming language is low level when its programs require attention to the irrelevant.


devel / comp.theory / Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

SubjectAuthor
* Concise refutation of halting problem proofs V52 [ Linz Proof ]olcott
+* Concise refutation of halting problem proofs V52 [ Linz Proof ]Richard Damon
|`* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
| `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|  `* Concise refutation of halting problem proofs V52 [ Ignorant or Dishonest ]olcott
|   `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    +* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |`* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    | `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |  `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |   `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |    `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |     `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |      `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |       `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |        `* Concise refutation of halting problem proofs V52 [ Ignorant or Dishonest ]Richard Damon
|    |         `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |          `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |           +* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |           |`* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |           | `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |           |  `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |           |   `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |           |    `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |           |     `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |           |      `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |           |       `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |           |        `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |           |         `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |           |          `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |           |           `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |           |            `* Concise refutation of halting problem proofs V52 [ Ignorant or Dishonest ]Richard Damon
|    |           |             `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |           |              `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |           |               `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |           |                `- Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |           `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |            `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |             `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |              `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |               +* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |               |`- Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |               `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |                `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |                 `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |                  `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |                   `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |                    `* Concise refutation of halting problem proofs V52 [ Ignorant or Dishonest ](typo)Richard Damon
|    |                     `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |                      `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |                       `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |                        `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |                         `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |                          `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |                           `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |                            `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |                             `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |                              `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |                               `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |                                `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |                                 `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |                                  `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |                                   `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|    |                                    `* Concise refutation of halting problem proofs V52 [ Ignorant orRichard Damon
|    |                                     `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                      `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                       `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                        `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                         `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                          `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                           `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                            `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                             `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                              `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                               `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                                `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                                 `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                                  `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                                   `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                                    `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                                     `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                                      `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                                       `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                                        `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                                         `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                                          `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                                           `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                                            `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                                             `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                                              `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                                               `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                                                `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                                                 `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                                                  `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                                                   `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                                                    `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                                                     `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                                                      `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                                                       `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    |                                                                        `* Concise refutation of halting problem proofs V52 [ HonestRichard Damon
|    |                                                                         `* Concise refutation of halting problem proofs V52 [ Honestolcott
|    `* Concise refutation of halting problem proofs V52 [ Ignorant orolcott
`- Concise refutation of halting problem proofs V52 [ Linz Proof ]Steve

Pages:123456789101112
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<_2IIJ.42013$i%.2716@fx04.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx04.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me>
<8eydnSpcWIVSUm38nZ2dnUU7-XvNnZ2d@giganews.com>
<9k4IJ.15452$jb4.2046@fx24.iad>
<SNudnYZfaZX6Tm38nZ2dnUU7-I3NnZ2d@giganews.com> <LMaIJ.8332$V31.330@fx47.iad>
<hsCdneOV_eybwGz8nZ2dnUU7-KPNnZ2d@giganews.com> <xalIJ.8632$rQ.8159@fx18.iad>
<r8OdnZwzO4tUf2z8nZ2dnUU7-SnNnZ2d@giganews.com> <eXlIJ.16438$2W.334@fx36.iad>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 270
Message-ID: <_2IIJ.42013$i%.2716@fx04.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: Thu, 27 Jan 2022 20:56:10 -0500
X-Received-Bytes: 14777
 by: Richard Damon - Fri, 28 Jan 2022 01:56 UTC

On 1/27/22 7:47 PM, olcott wrote:
> On 1/27/2022 6:23 PM, Richard Damon wrote:
>> On 1/27/22 7:14 PM, olcott wrote:
>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that only an
>>>>>>>>>>>>>>>>>>>>>> infinite simulation of an infinite sequence of
>>>>>>>>>>>>>>>>>>>>>> configurations can recognize an infinite sequence
>>>>>>>>>>>>>>>>>>>>>> of configurations.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite execution in
>>>>>>>>>>>>>>>>>>>>> finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^ based on an H
>>>>>>>>>>>>>>>>>>>>> that at some point goest to H.Qn that correctly
>>>>>>>>>>>>>>>>>>>>> detects the infinite behavior.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME infinite patterns
>>>>>>>>>>>>>>>>>>>>> are only really infinite when you work them out to
>>>>>>>>>>>>>>>>>>>>> infinitity.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces you look at
>>>>>>>>>>>>>>>>>>>>> are wrong. When H simulates H^, it needs to trace
>>>>>>>>>>>>>>>>>>>>> out the actual execution path of the H that part of
>>>>>>>>>>>>>>>>>>>>> H^, not switch to tracing what it was tracing.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual capacity to
>>>>>>>>>>>>>>>>>>>> understand that when embedded_H simulates ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ this is the pattern:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its simulation
>>>>>>>>>>>>>>>>>>> and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY point, then the
>>>>>>>>>>>>>>>>>>> above is NOT the accurate trace of the behavior of
>>>>>>>>>>>>>>>>>>> the input.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You exactly same jackass point equally applies to this
>>>>>>>>>>>>>>>>>> case:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop infinitely it is
>>>>>>>>>>>>>>>>>> not an accurate simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The key point you miss is that if H does abort its
>>>>>>>>>>>>>>>>> simulation, then it needs to take into account that the
>>>>>>>>>>>>>>>>> machine it is simulating will do so too.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As long as H correctly determines that its simulated
>>>>>>>>>>>>>>>> input cannot possibly reach its final state in any
>>>>>>>>>>>>>>>> finite number of steps it has conclusively proved that
>>>>>>>>>>>>>>>> this input never halts according to the Linz definition:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But it needs to prove that the UTM of its input never
>>>>>>>>>>>>>>> halts, and for H^, that means even if the H insisde H^
>>>>>>>>>>>>>>> goes to H.Qn which means that H^ goes to H^.Qn, which of
>>>>>>>>>>>>>>> course Halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that its
>>>>>>>>>>>>>> simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly reach
>>>>>>>>>>>>>> its final state in any finite number of steps it
>>>>>>>>>>>>>> terminates this simulation immediately stopping every
>>>>>>>>>>>>>> element of the entire chain of nested simulations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you are claiming that embedded_H and H behave
>>>>>>>>>>>>> differently then you have been lying that you built H^ by
>>>>>>>>>>>>> the instruction of Linz, as the copy of H inside H^ is
>>>>>>>>>>>>> IDENTICAL (except what happens AFTER getting to H.Qy)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now, IF H could make that proof, then it would be correct
>>>>>>>>>>>>> to go to H.Qn, but it would need to take into account that
>>>>>>>>>>>>> H^ halts if its copy of H goes to H.Qn, so this is NEVER
>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which causes the
>>>>>>>>>>>>>> original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>>>>> is not an input to embedded_H and a decider is only
>>>>>>>>>>>>>> accountable for computing the mapping from its actual
>>>>>>>>>>>>>> inputs to an accept or reject state it makes no difference
>>>>>>>>>>>>>> that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thus you have admitted to LYING about working on the
>>>>>>>>>>>>> Halting problem as if you were the embedded_H would be the
>>>>>>>>>>>>> same algorithm as H, and the requirement on H was that is
>>>>>>>>>>>>> IS accoutable for the machine its input represents,
>>>>>>>>>>>>
>>>>>>>>>>>> You are simply too freaking stupid to understand that
>>>>>>>>>>>> deciders thus halt deciders are only accountable for
>>>>>>>>>>>> computing the mapping from their actual inputs (nothing else
>>>>>>>>>>>> in the whole freaking universe besides their actual inputs)
>>>>>>>>>>>> to an accept or reject state.
>>>>>>>>>>>>
>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It seems you don't understand the difference between
>>>>>>>>>>> capabilities and requirements.
>>>>>>>>>>>
>>>>>>>>>>> H is only CAPABLE of deciding based on what it can do. It can
>>>>>>>>>>> only computate a mapping based on what it actually can do.
>>>>>>>>>>>
>>>>>>>>>>> It is REQUIRED to meet its requirements, which is to decide
>>>>>>>>>>> on the behavior of what its input would do if given to a UTM.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> embedded_H must only determine whether or not is simulated
>>>>>>>>>> input can ever reach its final state in any finite number of
>>>>>>>>>> steps.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Again, you seem to be lying about working on the Halting
>>>>>>>>> Problem and Linz proof.
>>>>>>>>>
>>>>>>>>> If you were working on the Halting Problem and Linz proof then
>>>>>>>>> embedded_H would be identical to H, as required by Linz, and
>>>>>>>>> the correct answer for the 'behavior' of the input to
>>>>>>>>> embedded_H <H^> <H^> would be the behavior of UTM(<H^>,<H^>)
>>>>>>>>> which if embedded_H goes to H.Qn then we know that H^ will go
>>>>>>>>> to H^.Qn and Halt, and thus H/embedded_H going to H.Qn is
>>>>>>>>> incorrect.
>>>>>>>>>
>>>>>>>>> So, you are just admitting that you are lying or are too stupid
>>>>>>>>> to understan what you are talking about.
>>>>>>>>>
>>>>>>>>> Which is it?
>>>>>>>>>
>>>>>>>>
>>>>>>>> I will not tolerate any digression from the point at hand until
>>>>>>>> we have mutual agreement. This is verified as completely true
>>>>>>>> entirely on the basis of the meaning of its words:
>>>>>>>>
>>>>>>>> embedded_H must only determine whether or not its simulated
>>>>>>>> input can
>>>>>>>> ever reach its final state in any finite number of steps.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Translation: You will ignroe any disagreement with your incorrect
>>>>>>> statement because you need to get people to accept your falso
>>>>>>> premise for your unsound argument to work.
>>>>>>>
>>>>>>> The problem with your statement is that you are showing that you
>>>>>>> atually mean something different than the true meaning of the words.
>>>>>>>
>>>>>>> H (and thus embedded_H) need to determine whether or not its
>>>>>>> simuleted input will ever reach its final state for EVERY
>>>>>>> POSSIBLE finite number of steps, i.e. as determine by a UTM.
>>>>>>>
>>>>>>
>>>>>> ∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩
>>>>>> ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>
>>>>
>>>> Except that it does unless you are lying about H^ being built right,
>>>> at least if H(<H^>,<H^>) -> H.Qn, and it doesn't matter what H^ does
>>>> if H doesn't go to H.Qn, as H is then wrong because it didn't answer.
>>>>
>>>
>>> ∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>> specifies a sequence of configurations that do not halt
>>>
>>> even if they stop running because the simulation has been aborted.
>>>
>>> I said that incorrectly only the above way of saying it is accurate,
>>> the second way of saying it can be misinterpreted.
>>>
>>
>> Except the pure simulation of the inputs to H/embeddd_H don't stop
>> when H/embedded_H abrot their simulation
>
> That is a ridiculously stupid thing to say.


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 27 Jan 2022 20:04:33 -0600
Date: Thu, 27 Jan 2022 20:04:32 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me> <9k4IJ.15452$jb4.2046@fx24.iad>
<SNudnYZfaZX6Tm38nZ2dnUU7-I3NnZ2d@giganews.com> <LMaIJ.8332$V31.330@fx47.iad>
<hsCdneOV_eybwGz8nZ2dnUU7-KPNnZ2d@giganews.com> <xalIJ.8632$rQ.8159@fx18.iad>
<r8OdnZwzO4tUf2z8nZ2dnUU7-SnNnZ2d@giganews.com> <eXlIJ.16438$2W.334@fx36.iad>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <_2IIJ.42013$i%.2716@fx04.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com>
Lines: 289
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-NW5PzL7ncE2sPuTalJ1s3FKWyT97eM02Fh/Wk/dDxoTu5Ojp2LCjmZNXMkq5btsK1r+fWoEyXUDKfBm!5HO9WPreZahVlV+OFUX/J/1uWyWTnpnmHMzg+YRgTTWYFWed4qDAum9WP4fKC6X+7Q+0T/Un9HiN
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 15640
 by: olcott - Fri, 28 Jan 2022 02:04 UTC

On 1/27/2022 7:56 PM, Richard Damon wrote:
> On 1/27/22 7:47 PM, olcott wrote:
>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>> On 1/27/22 7:14 PM, olcott wrote:
>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that only an
>>>>>>>>>>>>>>>>>>>>>>> infinite simulation of an infinite sequence of
>>>>>>>>>>>>>>>>>>>>>>> configurations can recognize an infinite sequence
>>>>>>>>>>>>>>>>>>>>>>> of configurations.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite execution
>>>>>>>>>>>>>>>>>>>>>> in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^ based on an H
>>>>>>>>>>>>>>>>>>>>>> that at some point goest to H.Qn that correctly
>>>>>>>>>>>>>>>>>>>>>> detects the infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME infinite patterns
>>>>>>>>>>>>>>>>>>>>>> are only really infinite when you work them out to
>>>>>>>>>>>>>>>>>>>>>> infinitity.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces you look
>>>>>>>>>>>>>>>>>>>>>> at are wrong. When H simulates H^, it needs to
>>>>>>>>>>>>>>>>>>>>>> trace out the actual execution path of the H that
>>>>>>>>>>>>>>>>>>>>>> part of H^, not switch to tracing what it was
>>>>>>>>>>>>>>>>>>>>>> tracing.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual capacity to
>>>>>>>>>>>>>>>>>>>>> understand that when embedded_H simulates ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ this is the pattern:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its simulation
>>>>>>>>>>>>>>>>>>>> and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY point, then
>>>>>>>>>>>>>>>>>>>> the above is NOT the accurate trace of the behavior
>>>>>>>>>>>>>>>>>>>> of the input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally applies to
>>>>>>>>>>>>>>>>>>> this case:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop infinitely it is
>>>>>>>>>>>>>>>>>>> not an accurate simulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The key point you miss is that if H does abort its
>>>>>>>>>>>>>>>>>> simulation, then it needs to take into account that
>>>>>>>>>>>>>>>>>> the machine it is simulating will do so too.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As long as H correctly determines that its simulated
>>>>>>>>>>>>>>>>> input cannot possibly reach its final state in any
>>>>>>>>>>>>>>>>> finite number of steps it has conclusively proved that
>>>>>>>>>>>>>>>>> this input never halts according to the Linz definition:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its input never
>>>>>>>>>>>>>>>> halts, and for H^, that means even if the H insisde H^
>>>>>>>>>>>>>>>> goes to H.Qn which means that H^ goes to H^.Qn, which of
>>>>>>>>>>>>>>>> course Halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that its
>>>>>>>>>>>>>>> simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly reach
>>>>>>>>>>>>>>> its final state in any finite number of steps it
>>>>>>>>>>>>>>> terminates this simulation immediately stopping every
>>>>>>>>>>>>>>> element of the entire chain of nested simulations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you are claiming that embedded_H and H behave
>>>>>>>>>>>>>> differently then you have been lying that you built H^ by
>>>>>>>>>>>>>> the instruction of Linz, as the copy of H inside H^ is
>>>>>>>>>>>>>> IDENTICAL (except what happens AFTER getting to H.Qy)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now, IF H could make that proof, then it would be correct
>>>>>>>>>>>>>> to go to H.Qn, but it would need to take into account that
>>>>>>>>>>>>>> H^ halts if its copy of H goes to H.Qn, so this is NEVER
>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which causes the
>>>>>>>>>>>>>>> original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>> is not an input to embedded_H and a decider is only
>>>>>>>>>>>>>>> accountable for computing the mapping from its actual
>>>>>>>>>>>>>>> inputs to an accept or reject state it makes no
>>>>>>>>>>>>>>> difference that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thus you have admitted to LYING about working on the
>>>>>>>>>>>>>> Halting problem as if you were the embedded_H would be the
>>>>>>>>>>>>>> same algorithm as H, and the requirement on H was that is
>>>>>>>>>>>>>> IS accoutable for the machine its input represents,
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are simply too freaking stupid to understand that
>>>>>>>>>>>>> deciders thus halt deciders are only accountable for
>>>>>>>>>>>>> computing the mapping from their actual inputs (nothing
>>>>>>>>>>>>> else in the whole freaking universe besides their actual
>>>>>>>>>>>>> inputs) to an accept or reject state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It seems you don't understand the difference between
>>>>>>>>>>>> capabilities and requirements.
>>>>>>>>>>>>
>>>>>>>>>>>> H is only CAPABLE of deciding based on what it can do. It
>>>>>>>>>>>> can only computate a mapping based on what it actually can do.
>>>>>>>>>>>>
>>>>>>>>>>>> It is REQUIRED to meet its requirements, which is to decide
>>>>>>>>>>>> on the behavior of what its input would do if given to a UTM.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> embedded_H must only determine whether or not is simulated
>>>>>>>>>>> input can ever reach its final state in any finite number of
>>>>>>>>>>> steps.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Again, you seem to be lying about working on the Halting
>>>>>>>>>> Problem and Linz proof.
>>>>>>>>>>
>>>>>>>>>> If you were working on the Halting Problem and Linz proof then
>>>>>>>>>> embedded_H would be identical to H, as required by Linz, and
>>>>>>>>>> the correct answer for the 'behavior' of the input to
>>>>>>>>>> embedded_H <H^> <H^> would be the behavior of UTM(<H^>,<H^>)
>>>>>>>>>> which if embedded_H goes to H.Qn then we know that H^ will go
>>>>>>>>>> to H^.Qn and Halt, and thus H/embedded_H going to H.Qn is
>>>>>>>>>> incorrect.
>>>>>>>>>>
>>>>>>>>>> So, you are just admitting that you are lying or are too
>>>>>>>>>> stupid to understan what you are talking about.
>>>>>>>>>>
>>>>>>>>>> Which is it?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I will not tolerate any digression from the point at hand until
>>>>>>>>> we have mutual agreement. This is verified as completely true
>>>>>>>>> entirely on the basis of the meaning of its words:
>>>>>>>>>
>>>>>>>>> embedded_H must only determine whether or not its simulated
>>>>>>>>> input can
>>>>>>>>> ever reach its final state in any finite number of steps.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Translation: You will ignroe any disagreement with your
>>>>>>>> incorrect statement because you need to get people to accept
>>>>>>>> your falso premise for your unsound argument to work.
>>>>>>>>
>>>>>>>> The problem with your statement is that you are showing that you
>>>>>>>> atually mean something different than the true meaning of the
>>>>>>>> words.
>>>>>>>>
>>>>>>>> H (and thus embedded_H) need to determine whether or not its
>>>>>>>> simuleted input will ever reach its final state for EVERY
>>>>>>>> POSSIBLE finite number of steps, i.e. as determine by a UTM.
>>>>>>>>
>>>>>>>
>>>>>>> ∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩
>>>>>>> ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>
>>>>>
>>>>> Except that it does unless you are lying about H^ being built
>>>>> right, at least if H(<H^>,<H^>) -> H.Qn, and it doesn't matter what
>>>>> H^ does if H doesn't go to H.Qn, as H is then wrong because it
>>>>> didn't answer.
>>>>>
>>>>
>>>> ∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>> specifies a sequence of configurations that do not halt
>>>>
>>>> even if they stop running because the simulation has been aborted.
>>>>
>>>> I said that incorrectly only the above way of saying it is accurate,
>>>> the second way of saying it can be misinterpreted.
>>>>
>>>
>>> Except the pure simulation of the inputs to H/embeddd_H don't stop
>>> when H/embedded_H abrot their simulation
>>
>> That is a ridiculously stupid thing to say.
>
> Why,


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<dsIIJ.28249$XU.692@fx38.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!50.7.236.10.MISMATCH!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx38.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me> <SNudnYZfaZX6Tm38nZ2dnUU7-I3NnZ2d@giganews.com> <LMaIJ.8332$V31.330@fx47.iad> <hsCdneOV_eybwGz8nZ2dnUU7-KPNnZ2d@giganews.com> <xalIJ.8632$rQ.8159@fx18.iad> <r8OdnZwzO4tUf2z8nZ2dnUU7-SnNnZ2d@giganews.com> <eXlIJ.16438$2W.334@fx36.iad> <zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad> <37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com> <csnIJ.19295$OU.5598@fx22.iad> <vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad> <PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com> <JToIJ.296644$1d1.101887@fx99.iad> <QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com> <7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me> <ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad> <sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com> <UHGIJ.15876$mS1.15729@fx10.iad> <Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com> <_2IIJ.42013$i%.2716@fx04.iad> <j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 302
Message-ID: <dsIIJ.28249$XU.692@fx38.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: Thu, 27 Jan 2022 21:23:05 -0500
X-Received-Bytes: 16253
 by: Richard Damon - Fri, 28 Jan 2022 02:23 UTC

On 1/27/22 9:04 PM, olcott wrote:
> On 1/27/2022 7:56 PM, Richard Damon wrote:
>> On 1/27/22 7:47 PM, olcott wrote:
>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that only an
>>>>>>>>>>>>>>>>>>>>>>>> infinite simulation of an infinite sequence of
>>>>>>>>>>>>>>>>>>>>>>>> configurations can recognize an infinite
>>>>>>>>>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite execution
>>>>>>>>>>>>>>>>>>>>>>> in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^ based on an
>>>>>>>>>>>>>>>>>>>>>>> H that at some point goest to H.Qn that correctly
>>>>>>>>>>>>>>>>>>>>>>> detects the infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME infinite
>>>>>>>>>>>>>>>>>>>>>>> patterns are only really infinite when you work
>>>>>>>>>>>>>>>>>>>>>>> them out to infinitity.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces you look
>>>>>>>>>>>>>>>>>>>>>>> at are wrong. When H simulates H^, it needs to
>>>>>>>>>>>>>>>>>>>>>>> trace out the actual execution path of the H that
>>>>>>>>>>>>>>>>>>>>>>> part of H^, not switch to tracing what it was
>>>>>>>>>>>>>>>>>>>>>>> tracing.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual capacity to
>>>>>>>>>>>>>>>>>>>>>> understand that when embedded_H simulates ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ this is the pattern:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its simulation
>>>>>>>>>>>>>>>>>>>>> and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY point, then
>>>>>>>>>>>>>>>>>>>>> the above is NOT the accurate trace of the behavior
>>>>>>>>>>>>>>>>>>>>> of the input.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally applies to
>>>>>>>>>>>>>>>>>>>> this case:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop infinitely it
>>>>>>>>>>>>>>>>>>>> is not an accurate simulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does abort its
>>>>>>>>>>>>>>>>>>> simulation, then it needs to take into account that
>>>>>>>>>>>>>>>>>>> the machine it is simulating will do so too.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As long as H correctly determines that its simulated
>>>>>>>>>>>>>>>>>> input cannot possibly reach its final state in any
>>>>>>>>>>>>>>>>>> finite number of steps it has conclusively proved that
>>>>>>>>>>>>>>>>>> this input never halts according to the Linz definition:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its input never
>>>>>>>>>>>>>>>>> halts, and for H^, that means even if the H insisde H^
>>>>>>>>>>>>>>>>> goes to H.Qn which means that H^ goes to H^.Qn, which
>>>>>>>>>>>>>>>>> of course Halts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that its
>>>>>>>>>>>>>>>> simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly reach
>>>>>>>>>>>>>>>> its final state in any finite number of steps it
>>>>>>>>>>>>>>>> terminates this simulation immediately stopping every
>>>>>>>>>>>>>>>> element of the entire chain of nested simulations.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you are claiming that embedded_H and H behave
>>>>>>>>>>>>>>> differently then you have been lying that you built H^ by
>>>>>>>>>>>>>>> the instruction of Linz, as the copy of H inside H^ is
>>>>>>>>>>>>>>> IDENTICAL (except what happens AFTER getting to H.Qy)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Now, IF H could make that proof, then it would be correct
>>>>>>>>>>>>>>> to go to H.Qn, but it would need to take into account
>>>>>>>>>>>>>>> that H^ halts if its copy of H goes to H.Qn, so this is
>>>>>>>>>>>>>>> NEVER possible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which causes the
>>>>>>>>>>>>>>>> original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ applied to
>>>>>>>>>>>>>>>> ⟨Ĥ⟩ is not an input to embedded_H and a decider is only
>>>>>>>>>>>>>>>> accountable for computing the mapping from its actual
>>>>>>>>>>>>>>>> inputs to an accept or reject state it makes no
>>>>>>>>>>>>>>>> difference that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thus you have admitted to LYING about working on the
>>>>>>>>>>>>>>> Halting problem as if you were the embedded_H would be
>>>>>>>>>>>>>>> the same algorithm as H, and the requirement on H was
>>>>>>>>>>>>>>> that is IS accoutable for the machine its input represents,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are simply too freaking stupid to understand that
>>>>>>>>>>>>>> deciders thus halt deciders are only accountable for
>>>>>>>>>>>>>> computing the mapping from their actual inputs (nothing
>>>>>>>>>>>>>> else in the whole freaking universe besides their actual
>>>>>>>>>>>>>> inputs) to an accept or reject state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It seems you don't understand the difference between
>>>>>>>>>>>>> capabilities and requirements.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it can do. It
>>>>>>>>>>>>> can only computate a mapping based on what it actually can do.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which is to decide
>>>>>>>>>>>>> on the behavior of what its input would do if given to a UTM.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> embedded_H must only determine whether or not is simulated
>>>>>>>>>>>> input can ever reach its final state in any finite number of
>>>>>>>>>>>> steps.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Again, you seem to be lying about working on the Halting
>>>>>>>>>>> Problem and Linz proof.
>>>>>>>>>>>
>>>>>>>>>>> If you were working on the Halting Problem and Linz proof
>>>>>>>>>>> then embedded_H would be identical to H, as required by Linz,
>>>>>>>>>>> and the correct answer for the 'behavior' of the input to
>>>>>>>>>>> embedded_H <H^> <H^> would be the behavior of UTM(<H^>,<H^>)
>>>>>>>>>>> which if embedded_H goes to H.Qn then we know that H^ will go
>>>>>>>>>>> to H^.Qn and Halt, and thus H/embedded_H going to H.Qn is
>>>>>>>>>>> incorrect.
>>>>>>>>>>>
>>>>>>>>>>> So, you are just admitting that you are lying or are too
>>>>>>>>>>> stupid to understan what you are talking about.
>>>>>>>>>>>
>>>>>>>>>>> Which is it?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I will not tolerate any digression from the point at hand
>>>>>>>>>> until we have mutual agreement. This is verified as completely
>>>>>>>>>> true entirely on the basis of the meaning of its words:
>>>>>>>>>>
>>>>>>>>>> embedded_H must only determine whether or not its simulated
>>>>>>>>>> input can
>>>>>>>>>> ever reach its final state in any finite number of steps.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Translation: You will ignroe any disagreement with your
>>>>>>>>> incorrect statement because you need to get people to accept
>>>>>>>>> your falso premise for your unsound argument to work.
>>>>>>>>>
>>>>>>>>> The problem with your statement is that you are showing that
>>>>>>>>> you atually mean something different than the true meaning of
>>>>>>>>> the words.
>>>>>>>>>
>>>>>>>>> H (and thus embedded_H) need to determine whether or not its
>>>>>>>>> simuleted input will ever reach its final state for EVERY
>>>>>>>>> POSSIBLE finite number of steps, i.e. as determine by a UTM.
>>>>>>>>>
>>>>>>>>
>>>>>>>> ∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩
>>>>>>>> ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>
>>>>>>
>>>>>> Except that it does unless you are lying about H^ being built
>>>>>> right, at least if H(<H^>,<H^>) -> H.Qn, and it doesn't matter
>>>>>> what H^ does if H doesn't go to H.Qn, as H is then wrong because
>>>>>> it didn't answer.
>>>>>>
>>>>>
>>>>> ∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>> specifies a sequence of configurations that do not halt
>>>>>
>>>>> even if they stop running because the simulation has been aborted.
>>>>>
>>>>> I said that incorrectly only the above way of saying it is
>>>>> accurate, the second way of saying it can be misinterpreted.
>>>>>
>>>>
>>>> Except the pure simulation of the inputs to H/embeddd_H don't stop
>>>> when H/embedded_H abrot their simulation
>>>
>>> That is a ridiculously stupid thing to say.
>>
>> Why,
>
>
> You said that a simulation does not stop when it stops.
> That is a ridiculously stupid thing to say.


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 27 Jan 2022 20:51:49 -0600
Date: Thu, 27 Jan 2022 20:51:48 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me>
<SNudnYZfaZX6Tm38nZ2dnUU7-I3NnZ2d@giganews.com> <LMaIJ.8332$V31.330@fx47.iad>
<hsCdneOV_eybwGz8nZ2dnUU7-KPNnZ2d@giganews.com> <xalIJ.8632$rQ.8159@fx18.iad>
<r8OdnZwzO4tUf2z8nZ2dnUU7-SnNnZ2d@giganews.com> <eXlIJ.16438$2W.334@fx36.iad>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <dsIIJ.28249$XU.692@fx38.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
Lines: 251
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-xQm2FgvDDp9onraR+VoJzMSaZuoN4DfJ2q+ReCjilllfrukube5yOin8z2V2HhKZLqtYfwl2TSO2Jw9!X0JrbJxSV4prIJtJwycueXO/li4k/4w80LNYSBbWNVAdSGcJuQcaqK6Tuh4MEGg+/SISFCwExZfq
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 14812
 by: olcott - Fri, 28 Jan 2022 02:51 UTC

On 1/27/2022 8:23 PM, Richard Damon wrote:
> On 1/27/22 9:04 PM, olcott wrote:
>> On 1/27/2022 7:56 PM, Richard Damon wrote:
>>> On 1/27/22 7:47 PM, olcott wrote:
>>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that only an
>>>>>>>>>>>>>>>>>>>>>>>>> infinite simulation of an infinite sequence of
>>>>>>>>>>>>>>>>>>>>>>>>> configurations can recognize an infinite
>>>>>>>>>>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite execution
>>>>>>>>>>>>>>>>>>>>>>>> in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^ based on an
>>>>>>>>>>>>>>>>>>>>>>>> H that at some point goest to H.Qn that
>>>>>>>>>>>>>>>>>>>>>>>> correctly detects the infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME infinite
>>>>>>>>>>>>>>>>>>>>>>>> patterns are only really infinite when you work
>>>>>>>>>>>>>>>>>>>>>>>> them out to infinitity.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces you look
>>>>>>>>>>>>>>>>>>>>>>>> at are wrong. When H simulates H^, it needs to
>>>>>>>>>>>>>>>>>>>>>>>> trace out the actual execution path of the H
>>>>>>>>>>>>>>>>>>>>>>>> that part of H^, not switch to tracing what it
>>>>>>>>>>>>>>>>>>>>>>>> was tracing.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual capacity to
>>>>>>>>>>>>>>>>>>>>>>> understand that when embedded_H simulates ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ this is the pattern:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its
>>>>>>>>>>>>>>>>>>>>>> simulation and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY point, then
>>>>>>>>>>>>>>>>>>>>>> the above is NOT the accurate trace of the
>>>>>>>>>>>>>>>>>>>>>> behavior of the input.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally applies to
>>>>>>>>>>>>>>>>>>>>> this case:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop infinitely it
>>>>>>>>>>>>>>>>>>>>> is not an accurate simulation.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does abort its
>>>>>>>>>>>>>>>>>>>> simulation, then it needs to take into account that
>>>>>>>>>>>>>>>>>>>> the machine it is simulating will do so too.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As long as H correctly determines that its simulated
>>>>>>>>>>>>>>>>>>> input cannot possibly reach its final state in any
>>>>>>>>>>>>>>>>>>> finite number of steps it has conclusively proved
>>>>>>>>>>>>>>>>>>> that this input never halts according to the Linz
>>>>>>>>>>>>>>>>>>> definition:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its input never
>>>>>>>>>>>>>>>>>> halts, and for H^, that means even if the H insisde H^
>>>>>>>>>>>>>>>>>> goes to H.Qn which means that H^ goes to H^.Qn, which
>>>>>>>>>>>>>>>>>> of course Halts.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that its
>>>>>>>>>>>>>>>>> simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly
>>>>>>>>>>>>>>>>> reach its final state in any finite number of steps it
>>>>>>>>>>>>>>>>> terminates this simulation immediately stopping every
>>>>>>>>>>>>>>>>> element of the entire chain of nested simulations.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If you are claiming that embedded_H and H behave
>>>>>>>>>>>>>>>> differently then you have been lying that you built H^
>>>>>>>>>>>>>>>> by the instruction of Linz, as the copy of H inside H^
>>>>>>>>>>>>>>>> is IDENTICAL (except what happens AFTER getting to H.Qy)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Now, IF H could make that proof, then it would be
>>>>>>>>>>>>>>>> correct to go to H.Qn, but it would need to take into
>>>>>>>>>>>>>>>> account that H^ halts if its copy of H goes to H.Qn, so
>>>>>>>>>>>>>>>> this is NEVER possible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which causes the
>>>>>>>>>>>>>>>>> original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ applied to
>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ is not an input to embedded_H and a decider is only
>>>>>>>>>>>>>>>>> accountable for computing the mapping from its actual
>>>>>>>>>>>>>>>>> inputs to an accept or reject state it makes no
>>>>>>>>>>>>>>>>> difference that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thus you have admitted to LYING about working on the
>>>>>>>>>>>>>>>> Halting problem as if you were the embedded_H would be
>>>>>>>>>>>>>>>> the same algorithm as H, and the requirement on H was
>>>>>>>>>>>>>>>> that is IS accoutable for the machine its input represents,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are simply too freaking stupid to understand that
>>>>>>>>>>>>>>> deciders thus halt deciders are only accountable for
>>>>>>>>>>>>>>> computing the mapping from their actual inputs (nothing
>>>>>>>>>>>>>>> else in the whole freaking universe besides their actual
>>>>>>>>>>>>>>> inputs) to an accept or reject state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It seems you don't understand the difference between
>>>>>>>>>>>>>> capabilities and requirements.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it can do. It
>>>>>>>>>>>>>> can only computate a mapping based on what it actually can
>>>>>>>>>>>>>> do.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which is to
>>>>>>>>>>>>>> decide on the behavior of what its input would do if given
>>>>>>>>>>>>>> to a UTM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> embedded_H must only determine whether or not is simulated
>>>>>>>>>>>>> input can ever reach its final state in any finite number
>>>>>>>>>>>>> of steps.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Again, you seem to be lying about working on the Halting
>>>>>>>>>>>> Problem and Linz proof.
>>>>>>>>>>>>
>>>>>>>>>>>> If you were working on the Halting Problem and Linz proof
>>>>>>>>>>>> then embedded_H would be identical to H, as required by
>>>>>>>>>>>> Linz, and the correct answer for the 'behavior' of the input
>>>>>>>>>>>> to embedded_H <H^> <H^> would be the behavior of
>>>>>>>>>>>> UTM(<H^>,<H^>) which if embedded_H goes to H.Qn then we know
>>>>>>>>>>>> that H^ will go to H^.Qn and Halt, and thus H/embedded_H
>>>>>>>>>>>> going to H.Qn is incorrect.
>>>>>>>>>>>>
>>>>>>>>>>>> So, you are just admitting that you are lying or are too
>>>>>>>>>>>> stupid to understan what you are talking about.
>>>>>>>>>>>>
>>>>>>>>>>>> Which is it?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I will not tolerate any digression from the point at hand
>>>>>>>>>>> until we have mutual agreement. This is verified as
>>>>>>>>>>> completely true entirely on the basis of the meaning of its
>>>>>>>>>>> words:
>>>>>>>>>>>
>>>>>>>>>>> embedded_H must only determine whether or not its simulated
>>>>>>>>>>> input can
>>>>>>>>>>> ever reach its final state in any finite number of steps.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Translation: You will ignroe any disagreement with your
>>>>>>>>>> incorrect statement because you need to get people to accept
>>>>>>>>>> your falso premise for your unsound argument to work.
>>>>>>>>>>
>>>>>>>>>> The problem with your statement is that you are showing that
>>>>>>>>>> you atually mean something different than the true meaning of
>>>>>>>>>> the words.
>>>>>>>>>>
>>>>>>>>>> H (and thus embedded_H) need to determine whether or not its
>>>>>>>>>> simuleted input will ever reach its final state for EVERY
>>>>>>>>>> POSSIBLE finite number of steps, i.e. as determine by a UTM.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩
>>>>>>>>> ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>>
>>>>>>>
>>>>>>> Except that it does unless you are lying about H^ being built
>>>>>>> right, at least if H(<H^>,<H^>) -> H.Qn, and it doesn't matter
>>>>>>> what H^ does if H doesn't go to H.Qn, as H is then wrong because
>>>>>>> it didn't answer.
>>>>>>>
>>>>>>
>>>>>> ∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>> specifies a sequence of configurations that do not halt
>>>>>>
>>>>>> even if they stop running because the simulation has been aborted.
>>>>>>
>>>>>> I said that incorrectly only the above way of saying it is
>>>>>> accurate, the second way of saying it can be misinterpreted.
>>>>>>
>>>>>
>>>>> Except the pure simulation of the inputs to H/embeddd_H don't stop
>>>>> when H/embedded_H abrot their simulation


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<g%IIJ.21397$1_.9729@fx37.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx37.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me> <LMaIJ.8332$V31.330@fx47.iad>
<hsCdneOV_eybwGz8nZ2dnUU7-KPNnZ2d@giganews.com> <xalIJ.8632$rQ.8159@fx18.iad>
<r8OdnZwzO4tUf2z8nZ2dnUU7-SnNnZ2d@giganews.com> <eXlIJ.16438$2W.334@fx36.iad>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 268
Message-ID: <g%IIJ.21397$1_.9729@fx37.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: Thu, 27 Jan 2022 22:00:27 -0500
X-Received-Bytes: 15338
 by: Richard Damon - Fri, 28 Jan 2022 03:00 UTC

On 1/27/22 9:51 PM, olcott wrote:
> On 1/27/2022 8:23 PM, Richard Damon wrote:
>> On 1/27/22 9:04 PM, olcott wrote:
>>> On 1/27/2022 7:56 PM, Richard Damon wrote:
>>>> On 1/27/22 7:47 PM, olcott wrote:
>>>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that only an
>>>>>>>>>>>>>>>>>>>>>>>>>> infinite simulation of an infinite sequence of
>>>>>>>>>>>>>>>>>>>>>>>>>> configurations can recognize an infinite
>>>>>>>>>>>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite
>>>>>>>>>>>>>>>>>>>>>>>>> execution in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^ based on
>>>>>>>>>>>>>>>>>>>>>>>>> an H that at some point goest to H.Qn that
>>>>>>>>>>>>>>>>>>>>>>>>> correctly detects the infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME infinite
>>>>>>>>>>>>>>>>>>>>>>>>> patterns are only really infinite when you work
>>>>>>>>>>>>>>>>>>>>>>>>> them out to infinitity.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces you
>>>>>>>>>>>>>>>>>>>>>>>>> look at are wrong. When H simulates H^, it
>>>>>>>>>>>>>>>>>>>>>>>>> needs to trace out the actual execution path of
>>>>>>>>>>>>>>>>>>>>>>>>> the H that part of H^, not switch to tracing
>>>>>>>>>>>>>>>>>>>>>>>>> what it was tracing.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual capacity to
>>>>>>>>>>>>>>>>>>>>>>>> understand that when embedded_H simulates ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ this is the pattern:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its
>>>>>>>>>>>>>>>>>>>>>>> simulation and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY point, then
>>>>>>>>>>>>>>>>>>>>>>> the above is NOT the accurate trace of the
>>>>>>>>>>>>>>>>>>>>>>> behavior of the input.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally applies to
>>>>>>>>>>>>>>>>>>>>>> this case:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop infinitely it
>>>>>>>>>>>>>>>>>>>>>> is not an accurate simulation.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does abort its
>>>>>>>>>>>>>>>>>>>>> simulation, then it needs to take into account that
>>>>>>>>>>>>>>>>>>>>> the machine it is simulating will do so too.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> As long as H correctly determines that its simulated
>>>>>>>>>>>>>>>>>>>> input cannot possibly reach its final state in any
>>>>>>>>>>>>>>>>>>>> finite number of steps it has conclusively proved
>>>>>>>>>>>>>>>>>>>> that this input never halts according to the Linz
>>>>>>>>>>>>>>>>>>>> definition:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its input never
>>>>>>>>>>>>>>>>>>> halts, and for H^, that means even if the H insisde
>>>>>>>>>>>>>>>>>>> H^ goes to H.Qn which means that H^ goes to H^.Qn,
>>>>>>>>>>>>>>>>>>> which of course Halts.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that its
>>>>>>>>>>>>>>>>>> simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly
>>>>>>>>>>>>>>>>>> reach its final state in any finite number of steps it
>>>>>>>>>>>>>>>>>> terminates this simulation immediately stopping every
>>>>>>>>>>>>>>>>>> element of the entire chain of nested simulations.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If you are claiming that embedded_H and H behave
>>>>>>>>>>>>>>>>> differently then you have been lying that you built H^
>>>>>>>>>>>>>>>>> by the instruction of Linz, as the copy of H inside H^
>>>>>>>>>>>>>>>>> is IDENTICAL (except what happens AFTER getting to H.Qy)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Now, IF H could make that proof, then it would be
>>>>>>>>>>>>>>>>> correct to go to H.Qn, but it would need to take into
>>>>>>>>>>>>>>>>> account that H^ halts if its copy of H goes to H.Qn, so
>>>>>>>>>>>>>>>>> this is NEVER possible.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which causes the
>>>>>>>>>>>>>>>>>> original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ applied to
>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ is not an input to embedded_H and a decider is
>>>>>>>>>>>>>>>>>> only accountable for computing the mapping from its
>>>>>>>>>>>>>>>>>> actual inputs to an accept or reject state it makes no
>>>>>>>>>>>>>>>>>> difference that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thus you have admitted to LYING about working on the
>>>>>>>>>>>>>>>>> Halting problem as if you were the embedded_H would be
>>>>>>>>>>>>>>>>> the same algorithm as H, and the requirement on H was
>>>>>>>>>>>>>>>>> that is IS accoutable for the machine its input
>>>>>>>>>>>>>>>>> represents,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You are simply too freaking stupid to understand that
>>>>>>>>>>>>>>>> deciders thus halt deciders are only accountable for
>>>>>>>>>>>>>>>> computing the mapping from their actual inputs (nothing
>>>>>>>>>>>>>>>> else in the whole freaking universe besides their actual
>>>>>>>>>>>>>>>> inputs) to an accept or reject state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It seems you don't understand the difference between
>>>>>>>>>>>>>>> capabilities and requirements.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it can do. It
>>>>>>>>>>>>>>> can only computate a mapping based on what it actually
>>>>>>>>>>>>>>> can do.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which is to
>>>>>>>>>>>>>>> decide on the behavior of what its input would do if
>>>>>>>>>>>>>>> given to a UTM.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> embedded_H must only determine whether or not is simulated
>>>>>>>>>>>>>> input can ever reach its final state in any finite number
>>>>>>>>>>>>>> of steps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Again, you seem to be lying about working on the Halting
>>>>>>>>>>>>> Problem and Linz proof.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you were working on the Halting Problem and Linz proof
>>>>>>>>>>>>> then embedded_H would be identical to H, as required by
>>>>>>>>>>>>> Linz, and the correct answer for the 'behavior' of the
>>>>>>>>>>>>> input to embedded_H <H^> <H^> would be the behavior of
>>>>>>>>>>>>> UTM(<H^>,<H^>) which if embedded_H goes to H.Qn then we
>>>>>>>>>>>>> know that H^ will go to H^.Qn and Halt, and thus
>>>>>>>>>>>>> H/embedded_H going to H.Qn is incorrect.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, you are just admitting that you are lying or are too
>>>>>>>>>>>>> stupid to understan what you are talking about.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Which is it?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I will not tolerate any digression from the point at hand
>>>>>>>>>>>> until we have mutual agreement. This is verified as
>>>>>>>>>>>> completely true entirely on the basis of the meaning of its
>>>>>>>>>>>> words:
>>>>>>>>>>>>
>>>>>>>>>>>> embedded_H must only determine whether or not its simulated
>>>>>>>>>>>> input can
>>>>>>>>>>>> ever reach its final state in any finite number of steps.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Translation: You will ignroe any disagreement with your
>>>>>>>>>>> incorrect statement because you need to get people to accept
>>>>>>>>>>> your falso premise for your unsound argument to work.
>>>>>>>>>>>
>>>>>>>>>>> The problem with your statement is that you are showing that
>>>>>>>>>>> you atually mean something different than the true meaning of
>>>>>>>>>>> the words.
>>>>>>>>>>>
>>>>>>>>>>> H (and thus embedded_H) need to determine whether or not its
>>>>>>>>>>> simuleted input will ever reach its final state for EVERY
>>>>>>>>>>> POSSIBLE finite number of steps, i.e. as determine by a UTM.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ∃N such that the pure simulation of the input to embedded_H
>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except that it does unless you are lying about H^ being built
>>>>>>>> right, at least if H(<H^>,<H^>) -> H.Qn, and it doesn't matter
>>>>>>>> what H^ does if H doesn't go to H.Qn, as H is then wrong because
>>>>>>>> it didn't answer.
>>>>>>>>
>>>>>>>
>>>>>>> ∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>> specifies a sequence of configurations that do not halt
>>>>>>>
>>>>>>> even if they stop running because the simulation has been aborted.
>>>>>>>
>>>>>>> I said that incorrectly only the above way of saying it is
>>>>>>> accurate, the second way of saying it can be misinterpreted.
>>>>>>>
>>>>>>
>>>>>> Except the pure simulation of the inputs to H/embeddd_H don't stop
>>>>>> when H/embedded_H abrot their simulation
>
> Only a complete moron would say this.


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<ssvncs$4lt$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Date: Thu, 27 Jan 2022 21:19:55 -0600
Organization: A noiseless patient Spider
Lines: 259
Message-ID: <ssvncs$4lt$1@dont-email.me>
References: <ssh8vu$4c0$1@dont-email.me>
<hsCdneOV_eybwGz8nZ2dnUU7-KPNnZ2d@giganews.com> <xalIJ.8632$rQ.8159@fx18.iad>
<r8OdnZwzO4tUf2z8nZ2dnUU7-SnNnZ2d@giganews.com> <eXlIJ.16438$2W.334@fx36.iad>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Jan 2022 03:19:57 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8cc80508c38d31cba6d12d67d4bda447";
logging-data="4797"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/bbTfSldBhzTDjCdyL7jtY"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Cancel-Lock: sha1:fsFdZepfli+puK7lbCaVNEnXtZE=
In-Reply-To: <g%IIJ.21397$1_.9729@fx37.iad>
Content-Language: en-US
 by: olcott - Fri, 28 Jan 2022 03:19 UTC

On 1/27/2022 9:00 PM, Richard Damon wrote:
> On 1/27/22 9:51 PM, olcott wrote:
>> On 1/27/2022 8:23 PM, Richard Damon wrote:
>>> On 1/27/22 9:04 PM, olcott wrote:
>>>> On 1/27/2022 7:56 PM, Richard Damon wrote:
>>>>> On 1/27/22 7:47 PM, olcott wrote:
>>>>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that only an
>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite simulation of an infinite sequence
>>>>>>>>>>>>>>>>>>>>>>>>>>> of configurations can recognize an infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite
>>>>>>>>>>>>>>>>>>>>>>>>>> execution in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^ based on
>>>>>>>>>>>>>>>>>>>>>>>>>> an H that at some point goest to H.Qn that
>>>>>>>>>>>>>>>>>>>>>>>>>> correctly detects the infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME infinite
>>>>>>>>>>>>>>>>>>>>>>>>>> patterns are only really infinite when you
>>>>>>>>>>>>>>>>>>>>>>>>>> work them out to infinitity.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces you
>>>>>>>>>>>>>>>>>>>>>>>>>> look at are wrong. When H simulates H^, it
>>>>>>>>>>>>>>>>>>>>>>>>>> needs to trace out the actual execution path
>>>>>>>>>>>>>>>>>>>>>>>>>> of the H that part of H^, not switch to
>>>>>>>>>>>>>>>>>>>>>>>>>> tracing what it was tracing.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual capacity to
>>>>>>>>>>>>>>>>>>>>>>>>> understand that when embedded_H simulates ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ this is the pattern:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its
>>>>>>>>>>>>>>>>>>>>>>>> simulation and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY point,
>>>>>>>>>>>>>>>>>>>>>>>> then the above is NOT the accurate trace of the
>>>>>>>>>>>>>>>>>>>>>>>> behavior of the input.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally applies to
>>>>>>>>>>>>>>>>>>>>>>> this case:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop infinitely
>>>>>>>>>>>>>>>>>>>>>>> it is not an accurate simulation.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does abort its
>>>>>>>>>>>>>>>>>>>>>> simulation, then it needs to take into account
>>>>>>>>>>>>>>>>>>>>>> that the machine it is simulating will do so too.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> As long as H correctly determines that its
>>>>>>>>>>>>>>>>>>>>> simulated input cannot possibly reach its final
>>>>>>>>>>>>>>>>>>>>> state in any finite number of steps it has
>>>>>>>>>>>>>>>>>>>>> conclusively proved that this input never halts
>>>>>>>>>>>>>>>>>>>>> according to the Linz definition:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its input
>>>>>>>>>>>>>>>>>>>> never halts, and for H^, that means even if the H
>>>>>>>>>>>>>>>>>>>> insisde H^ goes to H.Qn which means that H^ goes to
>>>>>>>>>>>>>>>>>>>> H^.Qn, which of course Halts.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that its
>>>>>>>>>>>>>>>>>>> simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly
>>>>>>>>>>>>>>>>>>> reach its final state in any finite number of steps
>>>>>>>>>>>>>>>>>>> it terminates this simulation immediately stopping
>>>>>>>>>>>>>>>>>>> every element of the entire chain of nested simulations.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If you are claiming that embedded_H and H behave
>>>>>>>>>>>>>>>>>> differently then you have been lying that you built H^
>>>>>>>>>>>>>>>>>> by the instruction of Linz, as the copy of H inside H^
>>>>>>>>>>>>>>>>>> is IDENTICAL (except what happens AFTER getting to H.Qy)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Now, IF H could make that proof, then it would be
>>>>>>>>>>>>>>>>>> correct to go to H.Qn, but it would need to take into
>>>>>>>>>>>>>>>>>> account that H^ halts if its copy of H goes to H.Qn,
>>>>>>>>>>>>>>>>>> so this is NEVER possible.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which causes the
>>>>>>>>>>>>>>>>>>> original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ applied to
>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ is not an input to embedded_H and a decider is
>>>>>>>>>>>>>>>>>>> only accountable for computing the mapping from its
>>>>>>>>>>>>>>>>>>> actual inputs to an accept or reject state it makes
>>>>>>>>>>>>>>>>>>> no difference that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thus you have admitted to LYING about working on the
>>>>>>>>>>>>>>>>>> Halting problem as if you were the embedded_H would be
>>>>>>>>>>>>>>>>>> the same algorithm as H, and the requirement on H was
>>>>>>>>>>>>>>>>>> that is IS accoutable for the machine its input
>>>>>>>>>>>>>>>>>> represents,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You are simply too freaking stupid to understand that
>>>>>>>>>>>>>>>>> deciders thus halt deciders are only accountable for
>>>>>>>>>>>>>>>>> computing the mapping from their actual inputs (nothing
>>>>>>>>>>>>>>>>> else in the whole freaking universe besides their
>>>>>>>>>>>>>>>>> actual inputs) to an accept or reject state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It seems you don't understand the difference between
>>>>>>>>>>>>>>>> capabilities and requirements.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it can do.
>>>>>>>>>>>>>>>> It can only computate a mapping based on what it
>>>>>>>>>>>>>>>> actually can do.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which is to
>>>>>>>>>>>>>>>> decide on the behavior of what its input would do if
>>>>>>>>>>>>>>>> given to a UTM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> embedded_H must only determine whether or not is
>>>>>>>>>>>>>>> simulated input can ever reach its final state in any
>>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Again, you seem to be lying about working on the Halting
>>>>>>>>>>>>>> Problem and Linz proof.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you were working on the Halting Problem and Linz proof
>>>>>>>>>>>>>> then embedded_H would be identical to H, as required by
>>>>>>>>>>>>>> Linz, and the correct answer for the 'behavior' of the
>>>>>>>>>>>>>> input to embedded_H <H^> <H^> would be the behavior of
>>>>>>>>>>>>>> UTM(<H^>,<H^>) which if embedded_H goes to H.Qn then we
>>>>>>>>>>>>>> know that H^ will go to H^.Qn and Halt, and thus
>>>>>>>>>>>>>> H/embedded_H going to H.Qn is incorrect.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, you are just admitting that you are lying or are too
>>>>>>>>>>>>>> stupid to understan what you are talking about.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Which is it?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will not tolerate any digression from the point at hand
>>>>>>>>>>>>> until we have mutual agreement. This is verified as
>>>>>>>>>>>>> completely true entirely on the basis of the meaning of its
>>>>>>>>>>>>> words:
>>>>>>>>>>>>>
>>>>>>>>>>>>> embedded_H must only determine whether or not its simulated
>>>>>>>>>>>>> input can
>>>>>>>>>>>>> ever reach its final state in any finite number of steps.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Translation: You will ignroe any disagreement with your
>>>>>>>>>>>> incorrect statement because you need to get people to accept
>>>>>>>>>>>> your falso premise for your unsound argument to work.
>>>>>>>>>>>>
>>>>>>>>>>>> The problem with your statement is that you are showing that
>>>>>>>>>>>> you atually mean something different than the true meaning
>>>>>>>>>>>> of the words.
>>>>>>>>>>>>
>>>>>>>>>>>> H (and thus embedded_H) need to determine whether or not its
>>>>>>>>>>>> simuleted input will ever reach its final state for EVERY
>>>>>>>>>>>> POSSIBLE finite number of steps, i.e. as determine by a UTM.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ∃N such that the pure simulation of the input to embedded_H
>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Except that it does unless you are lying about H^ being built
>>>>>>>>> right, at least if H(<H^>,<H^>) -> H.Qn, and it doesn't matter
>>>>>>>>> what H^ does if H doesn't go to H.Qn, as H is then wrong
>>>>>>>>> because it didn't answer.
>>>>>>>>>
>>>>>>>>
>>>>>>>> ∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩ applied to
>>>>>>>> ⟨Ĥ⟩ specifies a sequence of configurations that do not halt
>>>>>>>>
>>>>>>>> even if they stop running because the simulation has been aborted.
>>>>>>>>
>>>>>>>> I said that incorrectly only the above way of saying it is
>>>>>>>> accurate, the second way of saying it can be misinterpreted.
>>>>>>>>
>>>>>>>
>>>>>>> Except the pure simulation of the inputs to H/embeddd_H don't
>>>>>>> stop when H/embedded_H abrot their simulation
>>
>> Only a complete moron would say this.
>
> Why do you say that, since it is TRUE?
>
> The pure simulation/execution of the machine doesn't stop because the
> impure one does.
>


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<ssvnfc$4lt$2@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Date: Thu, 27 Jan 2022 21:21:14 -0600
Organization: A noiseless patient Spider
Lines: 256
Message-ID: <ssvnfc$4lt$2@dont-email.me>
References: <ssh8vu$4c0$1@dont-email.me>
<hsCdneOV_eybwGz8nZ2dnUU7-KPNnZ2d@giganews.com> <xalIJ.8632$rQ.8159@fx18.iad>
<r8OdnZwzO4tUf2z8nZ2dnUU7-SnNnZ2d@giganews.com> <eXlIJ.16438$2W.334@fx36.iad>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Jan 2022 03:21:16 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8cc80508c38d31cba6d12d67d4bda447";
logging-data="4797"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ZfdY87UL7icvwH0drPK+m"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Cancel-Lock: sha1:vEY3O6/yqjvvrfmkIQw/qArS1bk=
In-Reply-To: <g%IIJ.21397$1_.9729@fx37.iad>
Content-Language: en-US
 by: olcott - Fri, 28 Jan 2022 03:21 UTC

On 1/27/2022 9:00 PM, Richard Damon wrote:
> On 1/27/22 9:51 PM, olcott wrote:
>> On 1/27/2022 8:23 PM, Richard Damon wrote:
>>> On 1/27/22 9:04 PM, olcott wrote:
>>>> On 1/27/2022 7:56 PM, Richard Damon wrote:
>>>>> On 1/27/22 7:47 PM, olcott wrote:
>>>>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that only an
>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite simulation of an infinite sequence
>>>>>>>>>>>>>>>>>>>>>>>>>>> of configurations can recognize an infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite
>>>>>>>>>>>>>>>>>>>>>>>>>> execution in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^ based on
>>>>>>>>>>>>>>>>>>>>>>>>>> an H that at some point goest to H.Qn that
>>>>>>>>>>>>>>>>>>>>>>>>>> correctly detects the infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME infinite
>>>>>>>>>>>>>>>>>>>>>>>>>> patterns are only really infinite when you
>>>>>>>>>>>>>>>>>>>>>>>>>> work them out to infinitity.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces you
>>>>>>>>>>>>>>>>>>>>>>>>>> look at are wrong. When H simulates H^, it
>>>>>>>>>>>>>>>>>>>>>>>>>> needs to trace out the actual execution path
>>>>>>>>>>>>>>>>>>>>>>>>>> of the H that part of H^, not switch to
>>>>>>>>>>>>>>>>>>>>>>>>>> tracing what it was tracing.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual capacity to
>>>>>>>>>>>>>>>>>>>>>>>>> understand that when embedded_H simulates ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ this is the pattern:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its
>>>>>>>>>>>>>>>>>>>>>>>> simulation and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY point,
>>>>>>>>>>>>>>>>>>>>>>>> then the above is NOT the accurate trace of the
>>>>>>>>>>>>>>>>>>>>>>>> behavior of the input.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally applies to
>>>>>>>>>>>>>>>>>>>>>>> this case:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop infinitely
>>>>>>>>>>>>>>>>>>>>>>> it is not an accurate simulation.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does abort its
>>>>>>>>>>>>>>>>>>>>>> simulation, then it needs to take into account
>>>>>>>>>>>>>>>>>>>>>> that the machine it is simulating will do so too.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> As long as H correctly determines that its
>>>>>>>>>>>>>>>>>>>>> simulated input cannot possibly reach its final
>>>>>>>>>>>>>>>>>>>>> state in any finite number of steps it has
>>>>>>>>>>>>>>>>>>>>> conclusively proved that this input never halts
>>>>>>>>>>>>>>>>>>>>> according to the Linz definition:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its input
>>>>>>>>>>>>>>>>>>>> never halts, and for H^, that means even if the H
>>>>>>>>>>>>>>>>>>>> insisde H^ goes to H.Qn which means that H^ goes to
>>>>>>>>>>>>>>>>>>>> H^.Qn, which of course Halts.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that its
>>>>>>>>>>>>>>>>>>> simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly
>>>>>>>>>>>>>>>>>>> reach its final state in any finite number of steps
>>>>>>>>>>>>>>>>>>> it terminates this simulation immediately stopping
>>>>>>>>>>>>>>>>>>> every element of the entire chain of nested simulations.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If you are claiming that embedded_H and H behave
>>>>>>>>>>>>>>>>>> differently then you have been lying that you built H^
>>>>>>>>>>>>>>>>>> by the instruction of Linz, as the copy of H inside H^
>>>>>>>>>>>>>>>>>> is IDENTICAL (except what happens AFTER getting to H.Qy)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Now, IF H could make that proof, then it would be
>>>>>>>>>>>>>>>>>> correct to go to H.Qn, but it would need to take into
>>>>>>>>>>>>>>>>>> account that H^ halts if its copy of H goes to H.Qn,
>>>>>>>>>>>>>>>>>> so this is NEVER possible.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which causes the
>>>>>>>>>>>>>>>>>>> original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ applied to
>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ is not an input to embedded_H and a decider is
>>>>>>>>>>>>>>>>>>> only accountable for computing the mapping from its
>>>>>>>>>>>>>>>>>>> actual inputs to an accept or reject state it makes
>>>>>>>>>>>>>>>>>>> no difference that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thus you have admitted to LYING about working on the
>>>>>>>>>>>>>>>>>> Halting problem as if you were the embedded_H would be
>>>>>>>>>>>>>>>>>> the same algorithm as H, and the requirement on H was
>>>>>>>>>>>>>>>>>> that is IS accoutable for the machine its input
>>>>>>>>>>>>>>>>>> represents,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You are simply too freaking stupid to understand that
>>>>>>>>>>>>>>>>> deciders thus halt deciders are only accountable for
>>>>>>>>>>>>>>>>> computing the mapping from their actual inputs (nothing
>>>>>>>>>>>>>>>>> else in the whole freaking universe besides their
>>>>>>>>>>>>>>>>> actual inputs) to an accept or reject state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It seems you don't understand the difference between
>>>>>>>>>>>>>>>> capabilities and requirements.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it can do.
>>>>>>>>>>>>>>>> It can only computate a mapping based on what it
>>>>>>>>>>>>>>>> actually can do.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which is to
>>>>>>>>>>>>>>>> decide on the behavior of what its input would do if
>>>>>>>>>>>>>>>> given to a UTM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> embedded_H must only determine whether or not is
>>>>>>>>>>>>>>> simulated input can ever reach its final state in any
>>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Again, you seem to be lying about working on the Halting
>>>>>>>>>>>>>> Problem and Linz proof.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you were working on the Halting Problem and Linz proof
>>>>>>>>>>>>>> then embedded_H would be identical to H, as required by
>>>>>>>>>>>>>> Linz, and the correct answer for the 'behavior' of the
>>>>>>>>>>>>>> input to embedded_H <H^> <H^> would be the behavior of
>>>>>>>>>>>>>> UTM(<H^>,<H^>) which if embedded_H goes to H.Qn then we
>>>>>>>>>>>>>> know that H^ will go to H^.Qn and Halt, and thus
>>>>>>>>>>>>>> H/embedded_H going to H.Qn is incorrect.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, you are just admitting that you are lying or are too
>>>>>>>>>>>>>> stupid to understan what you are talking about.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Which is it?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will not tolerate any digression from the point at hand
>>>>>>>>>>>>> until we have mutual agreement. This is verified as
>>>>>>>>>>>>> completely true entirely on the basis of the meaning of its
>>>>>>>>>>>>> words:
>>>>>>>>>>>>>
>>>>>>>>>>>>> embedded_H must only determine whether or not its simulated
>>>>>>>>>>>>> input can
>>>>>>>>>>>>> ever reach its final state in any finite number of steps.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Translation: You will ignroe any disagreement with your
>>>>>>>>>>>> incorrect statement because you need to get people to accept
>>>>>>>>>>>> your falso premise for your unsound argument to work.
>>>>>>>>>>>>
>>>>>>>>>>>> The problem with your statement is that you are showing that
>>>>>>>>>>>> you atually mean something different than the true meaning
>>>>>>>>>>>> of the words.
>>>>>>>>>>>>
>>>>>>>>>>>> H (and thus embedded_H) need to determine whether or not its
>>>>>>>>>>>> simuleted input will ever reach its final state for EVERY
>>>>>>>>>>>> POSSIBLE finite number of steps, i.e. as determine by a UTM.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ∃N such that the pure simulation of the input to embedded_H
>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Except that it does unless you are lying about H^ being built
>>>>>>>>> right, at least if H(<H^>,<H^>) -> H.Qn, and it doesn't matter
>>>>>>>>> what H^ does if H doesn't go to H.Qn, as H is then wrong
>>>>>>>>> because it didn't answer.
>>>>>>>>>
>>>>>>>>
>>>>>>>> ∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩ applied to
>>>>>>>> ⟨Ĥ⟩ specifies a sequence of configurations that do not halt
>>>>>>>>
>>>>>>>> even if they stop running because the simulation has been aborted.
>>>>>>>>
>>>>>>>> I said that incorrectly only the above way of saying it is
>>>>>>>> accurate, the second way of saying it can be misinterpreted.
>>>>>>>>
>>>>>>>
>>>>>>> Except the pure simulation of the inputs to H/embeddd_H don't
>>>>>>> stop when H/embedded_H abrot their simulation
>>
>> Only a complete moron would say this.
>
> Why do you say that, since it is TRUE?
>
You total jackass know that there is only a single pure simulation of N
steps of the input.


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<vEJIJ.5949$rU.2844@fx34.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!peer03.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:91.0)
Gecko/20100101 Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me> <xalIJ.8632$rQ.8159@fx18.iad>
<r8OdnZwzO4tUf2z8nZ2dnUU7-SnNnZ2d@giganews.com> <eXlIJ.16438$2W.334@fx36.iad>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <ssvnfc$4lt$2@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 272
Message-ID: <vEJIJ.5949$rU.2844@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: Thu, 27 Jan 2022 22:44:26 -0500
X-Received-Bytes: 15866
X-Original-Bytes: 15732
 by: Richard Damon - Fri, 28 Jan 2022 03:44 UTC

On 1/27/22 10:21 PM, olcott wrote:
> On 1/27/2022 9:00 PM, Richard Damon wrote:
>> On 1/27/22 9:51 PM, olcott wrote:
>>> On 1/27/2022 8:23 PM, Richard Damon wrote:
>>>> On 1/27/22 9:04 PM, olcott wrote:
>>>>> On 1/27/2022 7:56 PM, Richard Damon wrote:
>>>>>> On 1/27/22 7:47 PM, olcott wrote:
>>>>>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>>>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that only
>>>>>>>>>>>>>>>>>>>>>>>>>>>> an infinite simulation of an infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence of configurations can recognize an
>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite sequence of configurations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>> execution in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^ based on
>>>>>>>>>>>>>>>>>>>>>>>>>>> an H that at some point goest to H.Qn that
>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly detects the infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>> patterns are only really infinite when you
>>>>>>>>>>>>>>>>>>>>>>>>>>> work them out to infinitity.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces you
>>>>>>>>>>>>>>>>>>>>>>>>>>> look at are wrong. When H simulates H^, it
>>>>>>>>>>>>>>>>>>>>>>>>>>> needs to trace out the actual execution path
>>>>>>>>>>>>>>>>>>>>>>>>>>> of the H that part of H^, not switch to
>>>>>>>>>>>>>>>>>>>>>>>>>>> tracing what it was tracing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual capacity to
>>>>>>>>>>>>>>>>>>>>>>>>>> understand that when embedded_H simulates ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ this is the pattern:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its
>>>>>>>>>>>>>>>>>>>>>>>>> simulation and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY point,
>>>>>>>>>>>>>>>>>>>>>>>>> then the above is NOT the accurate trace of the
>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally applies
>>>>>>>>>>>>>>>>>>>>>>>> to this case:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop infinitely
>>>>>>>>>>>>>>>>>>>>>>>> it is not an accurate simulation.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does abort
>>>>>>>>>>>>>>>>>>>>>>> its simulation, then it needs to take into
>>>>>>>>>>>>>>>>>>>>>>> account that the machine it is simulating will do
>>>>>>>>>>>>>>>>>>>>>>> so too.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> As long as H correctly determines that its
>>>>>>>>>>>>>>>>>>>>>> simulated input cannot possibly reach its final
>>>>>>>>>>>>>>>>>>>>>> state in any finite number of steps it has
>>>>>>>>>>>>>>>>>>>>>> conclusively proved that this input never halts
>>>>>>>>>>>>>>>>>>>>>> according to the Linz definition:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its input
>>>>>>>>>>>>>>>>>>>>> never halts, and for H^, that means even if the H
>>>>>>>>>>>>>>>>>>>>> insisde H^ goes to H.Qn which means that H^ goes to
>>>>>>>>>>>>>>>>>>>>> H^.Qn, which of course Halts.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that its
>>>>>>>>>>>>>>>>>>>> simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly
>>>>>>>>>>>>>>>>>>>> reach its final state in any finite number of steps
>>>>>>>>>>>>>>>>>>>> it terminates this simulation immediately stopping
>>>>>>>>>>>>>>>>>>>> every element of the entire chain of nested
>>>>>>>>>>>>>>>>>>>> simulations.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If you are claiming that embedded_H and H behave
>>>>>>>>>>>>>>>>>>> differently then you have been lying that you built
>>>>>>>>>>>>>>>>>>> H^ by the instruction of Linz, as the copy of H
>>>>>>>>>>>>>>>>>>> inside H^ is IDENTICAL (except what happens AFTER
>>>>>>>>>>>>>>>>>>> getting to H.Qy)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Now, IF H could make that proof, then it would be
>>>>>>>>>>>>>>>>>>> correct to go to H.Qn, but it would need to take into
>>>>>>>>>>>>>>>>>>> account that H^ halts if its copy of H goes to H.Qn,
>>>>>>>>>>>>>>>>>>> so this is NEVER possible.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which causes the
>>>>>>>>>>>>>>>>>>>> original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ applied
>>>>>>>>>>>>>>>>>>>> to ⟨Ĥ⟩ is not an input to embedded_H and a decider
>>>>>>>>>>>>>>>>>>>> is only accountable for computing the mapping from
>>>>>>>>>>>>>>>>>>>> its actual inputs to an accept or reject state it
>>>>>>>>>>>>>>>>>>>> makes no difference that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thus you have admitted to LYING about working on the
>>>>>>>>>>>>>>>>>>> Halting problem as if you were the embedded_H would
>>>>>>>>>>>>>>>>>>> be the same algorithm as H, and the requirement on H
>>>>>>>>>>>>>>>>>>> was that is IS accoutable for the machine its input
>>>>>>>>>>>>>>>>>>> represents,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You are simply too freaking stupid to understand that
>>>>>>>>>>>>>>>>>> deciders thus halt deciders are only accountable for
>>>>>>>>>>>>>>>>>> computing the mapping from their actual inputs
>>>>>>>>>>>>>>>>>> (nothing else in the whole freaking universe besides
>>>>>>>>>>>>>>>>>> their actual inputs) to an accept or reject state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It seems you don't understand the difference between
>>>>>>>>>>>>>>>>> capabilities and requirements.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it can do.
>>>>>>>>>>>>>>>>> It can only computate a mapping based on what it
>>>>>>>>>>>>>>>>> actually can do.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which is to
>>>>>>>>>>>>>>>>> decide on the behavior of what its input would do if
>>>>>>>>>>>>>>>>> given to a UTM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> embedded_H must only determine whether or not is
>>>>>>>>>>>>>>>> simulated input can ever reach its final state in any
>>>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Again, you seem to be lying about working on the Halting
>>>>>>>>>>>>>>> Problem and Linz proof.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you were working on the Halting Problem and Linz proof
>>>>>>>>>>>>>>> then embedded_H would be identical to H, as required by
>>>>>>>>>>>>>>> Linz, and the correct answer for the 'behavior' of the
>>>>>>>>>>>>>>> input to embedded_H <H^> <H^> would be the behavior of
>>>>>>>>>>>>>>> UTM(<H^>,<H^>) which if embedded_H goes to H.Qn then we
>>>>>>>>>>>>>>> know that H^ will go to H^.Qn and Halt, and thus
>>>>>>>>>>>>>>> H/embedded_H going to H.Qn is incorrect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, you are just admitting that you are lying or are too
>>>>>>>>>>>>>>> stupid to understan what you are talking about.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Which is it?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I will not tolerate any digression from the point at hand
>>>>>>>>>>>>>> until we have mutual agreement. This is verified as
>>>>>>>>>>>>>> completely true entirely on the basis of the meaning of
>>>>>>>>>>>>>> its words:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> embedded_H must only determine whether or not its
>>>>>>>>>>>>>> simulated input can
>>>>>>>>>>>>>> ever reach its final state in any finite number of steps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Translation: You will ignroe any disagreement with your
>>>>>>>>>>>>> incorrect statement because you need to get people to
>>>>>>>>>>>>> accept your falso premise for your unsound argument to work.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The problem with your statement is that you are showing
>>>>>>>>>>>>> that you atually mean something different than the true
>>>>>>>>>>>>> meaning of the words.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H (and thus embedded_H) need to determine whether or not
>>>>>>>>>>>>> its simuleted input will ever reach its final state for
>>>>>>>>>>>>> EVERY POSSIBLE finite number of steps, i.e. as determine by
>>>>>>>>>>>>> a UTM.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ∃N such that the pure simulation of the input to embedded_H
>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Except that it does unless you are lying about H^ being built
>>>>>>>>>> right, at least if H(<H^>,<H^>) -> H.Qn, and it doesn't matter
>>>>>>>>>> what H^ does if H doesn't go to H.Qn, as H is then wrong
>>>>>>>>>> because it didn't answer.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩
>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩ applied to
>>>>>>>>> ⟨Ĥ⟩ specifies a sequence of configurations that do not halt
>>>>>>>>>
>>>>>>>>> even if they stop running because the simulation has been aborted.
>>>>>>>>>
>>>>>>>>> I said that incorrectly only the above way of saying it is
>>>>>>>>> accurate, the second way of saying it can be misinterpreted.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except the pure simulation of the inputs to H/embeddd_H don't
>>>>>>>> stop when H/embedded_H abrot their simulation
>>>
>>> Only a complete moron would say this.
>>
>> Why do you say that, since it is TRUE?
>>
> You total jackass know that there is only a single pure simulation of N
> steps of the input.
>


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<cGJIJ.5950$rU.5253@fx34.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!peer03.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:91.0)
Gecko/20100101 Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me> <xalIJ.8632$rQ.8159@fx18.iad>
<r8OdnZwzO4tUf2z8nZ2dnUU7-SnNnZ2d@giganews.com> <eXlIJ.16438$2W.334@fx36.iad>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvncs$4lt$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <ssvncs$4lt$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 270
Message-ID: <cGJIJ.5950$rU.5253@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: Thu, 27 Jan 2022 22:46:16 -0500
X-Received-Bytes: 15696
X-Original-Bytes: 15562
 by: Richard Damon - Fri, 28 Jan 2022 03:46 UTC

On 1/27/22 10:19 PM, olcott wrote:
> On 1/27/2022 9:00 PM, Richard Damon wrote:
>> On 1/27/22 9:51 PM, olcott wrote:
>>> On 1/27/2022 8:23 PM, Richard Damon wrote:
>>>> On 1/27/22 9:04 PM, olcott wrote:
>>>>> On 1/27/2022 7:56 PM, Richard Damon wrote:
>>>>>> On 1/27/22 7:47 PM, olcott wrote:
>>>>>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>>>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that only
>>>>>>>>>>>>>>>>>>>>>>>>>>>> an infinite simulation of an infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence of configurations can recognize an
>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite sequence of configurations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>> execution in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^ based on
>>>>>>>>>>>>>>>>>>>>>>>>>>> an H that at some point goest to H.Qn that
>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly detects the infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>> patterns are only really infinite when you
>>>>>>>>>>>>>>>>>>>>>>>>>>> work them out to infinitity.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces you
>>>>>>>>>>>>>>>>>>>>>>>>>>> look at are wrong. When H simulates H^, it
>>>>>>>>>>>>>>>>>>>>>>>>>>> needs to trace out the actual execution path
>>>>>>>>>>>>>>>>>>>>>>>>>>> of the H that part of H^, not switch to
>>>>>>>>>>>>>>>>>>>>>>>>>>> tracing what it was tracing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual capacity to
>>>>>>>>>>>>>>>>>>>>>>>>>> understand that when embedded_H simulates ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ this is the pattern:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its
>>>>>>>>>>>>>>>>>>>>>>>>> simulation and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY point,
>>>>>>>>>>>>>>>>>>>>>>>>> then the above is NOT the accurate trace of the
>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally applies
>>>>>>>>>>>>>>>>>>>>>>>> to this case:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop infinitely
>>>>>>>>>>>>>>>>>>>>>>>> it is not an accurate simulation.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does abort
>>>>>>>>>>>>>>>>>>>>>>> its simulation, then it needs to take into
>>>>>>>>>>>>>>>>>>>>>>> account that the machine it is simulating will do
>>>>>>>>>>>>>>>>>>>>>>> so too.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> As long as H correctly determines that its
>>>>>>>>>>>>>>>>>>>>>> simulated input cannot possibly reach its final
>>>>>>>>>>>>>>>>>>>>>> state in any finite number of steps it has
>>>>>>>>>>>>>>>>>>>>>> conclusively proved that this input never halts
>>>>>>>>>>>>>>>>>>>>>> according to the Linz definition:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its input
>>>>>>>>>>>>>>>>>>>>> never halts, and for H^, that means even if the H
>>>>>>>>>>>>>>>>>>>>> insisde H^ goes to H.Qn which means that H^ goes to
>>>>>>>>>>>>>>>>>>>>> H^.Qn, which of course Halts.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that its
>>>>>>>>>>>>>>>>>>>> simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly
>>>>>>>>>>>>>>>>>>>> reach its final state in any finite number of steps
>>>>>>>>>>>>>>>>>>>> it terminates this simulation immediately stopping
>>>>>>>>>>>>>>>>>>>> every element of the entire chain of nested
>>>>>>>>>>>>>>>>>>>> simulations.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If you are claiming that embedded_H and H behave
>>>>>>>>>>>>>>>>>>> differently then you have been lying that you built
>>>>>>>>>>>>>>>>>>> H^ by the instruction of Linz, as the copy of H
>>>>>>>>>>>>>>>>>>> inside H^ is IDENTICAL (except what happens AFTER
>>>>>>>>>>>>>>>>>>> getting to H.Qy)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Now, IF H could make that proof, then it would be
>>>>>>>>>>>>>>>>>>> correct to go to H.Qn, but it would need to take into
>>>>>>>>>>>>>>>>>>> account that H^ halts if its copy of H goes to H.Qn,
>>>>>>>>>>>>>>>>>>> so this is NEVER possible.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which causes the
>>>>>>>>>>>>>>>>>>>> original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ applied
>>>>>>>>>>>>>>>>>>>> to ⟨Ĥ⟩ is not an input to embedded_H and a decider
>>>>>>>>>>>>>>>>>>>> is only accountable for computing the mapping from
>>>>>>>>>>>>>>>>>>>> its actual inputs to an accept or reject state it
>>>>>>>>>>>>>>>>>>>> makes no difference that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thus you have admitted to LYING about working on the
>>>>>>>>>>>>>>>>>>> Halting problem as if you were the embedded_H would
>>>>>>>>>>>>>>>>>>> be the same algorithm as H, and the requirement on H
>>>>>>>>>>>>>>>>>>> was that is IS accoutable for the machine its input
>>>>>>>>>>>>>>>>>>> represents,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You are simply too freaking stupid to understand that
>>>>>>>>>>>>>>>>>> deciders thus halt deciders are only accountable for
>>>>>>>>>>>>>>>>>> computing the mapping from their actual inputs
>>>>>>>>>>>>>>>>>> (nothing else in the whole freaking universe besides
>>>>>>>>>>>>>>>>>> their actual inputs) to an accept or reject state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It seems you don't understand the difference between
>>>>>>>>>>>>>>>>> capabilities and requirements.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it can do.
>>>>>>>>>>>>>>>>> It can only computate a mapping based on what it
>>>>>>>>>>>>>>>>> actually can do.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which is to
>>>>>>>>>>>>>>>>> decide on the behavior of what its input would do if
>>>>>>>>>>>>>>>>> given to a UTM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> embedded_H must only determine whether or not is
>>>>>>>>>>>>>>>> simulated input can ever reach its final state in any
>>>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Again, you seem to be lying about working on the Halting
>>>>>>>>>>>>>>> Problem and Linz proof.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you were working on the Halting Problem and Linz proof
>>>>>>>>>>>>>>> then embedded_H would be identical to H, as required by
>>>>>>>>>>>>>>> Linz, and the correct answer for the 'behavior' of the
>>>>>>>>>>>>>>> input to embedded_H <H^> <H^> would be the behavior of
>>>>>>>>>>>>>>> UTM(<H^>,<H^>) which if embedded_H goes to H.Qn then we
>>>>>>>>>>>>>>> know that H^ will go to H^.Qn and Halt, and thus
>>>>>>>>>>>>>>> H/embedded_H going to H.Qn is incorrect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, you are just admitting that you are lying or are too
>>>>>>>>>>>>>>> stupid to understan what you are talking about.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Which is it?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I will not tolerate any digression from the point at hand
>>>>>>>>>>>>>> until we have mutual agreement. This is verified as
>>>>>>>>>>>>>> completely true entirely on the basis of the meaning of
>>>>>>>>>>>>>> its words:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> embedded_H must only determine whether or not its
>>>>>>>>>>>>>> simulated input can
>>>>>>>>>>>>>> ever reach its final state in any finite number of steps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Translation: You will ignroe any disagreement with your
>>>>>>>>>>>>> incorrect statement because you need to get people to
>>>>>>>>>>>>> accept your falso premise for your unsound argument to work.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The problem with your statement is that you are showing
>>>>>>>>>>>>> that you atually mean something different than the true
>>>>>>>>>>>>> meaning of the words.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H (and thus embedded_H) need to determine whether or not
>>>>>>>>>>>>> its simuleted input will ever reach its final state for
>>>>>>>>>>>>> EVERY POSSIBLE finite number of steps, i.e. as determine by
>>>>>>>>>>>>> a UTM.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ∃N such that the pure simulation of the input to embedded_H
>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Except that it does unless you are lying about H^ being built
>>>>>>>>>> right, at least if H(<H^>,<H^>) -> H.Qn, and it doesn't matter
>>>>>>>>>> what H^ does if H doesn't go to H.Qn, as H is then wrong
>>>>>>>>>> because it didn't answer.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩
>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩ applied to
>>>>>>>>> ⟨Ĥ⟩ specifies a sequence of configurations that do not halt
>>>>>>>>>
>>>>>>>>> even if they stop running because the simulation has been aborted.
>>>>>>>>>
>>>>>>>>> I said that incorrectly only the above way of saying it is
>>>>>>>>> accurate, the second way of saying it can be misinterpreted.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except the pure simulation of the inputs to H/embeddd_H don't
>>>>>>>> stop when H/embedded_H abrot their simulation
>>>
>>> Only a complete moron would say this.
>>
>> Why do you say that, since it is TRUE?
>>
>> The pure simulation/execution of the machine doesn't stop because the
>> impure one does.
>>
>
> You total jackass know that there is only a single pure simulation.
>


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 27 Jan 2022 21:50:42 -0600
Date: Thu, 27 Jan 2022 21:50:41 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me>
<r8OdnZwzO4tUf2z8nZ2dnUU7-SnNnZ2d@giganews.com> <eXlIJ.16438$2W.334@fx36.iad>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <vEJIJ.5949$rU.2844@fx34.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
Lines: 284
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-c6UKH/1bL13qc6i1IParHcPkmUHENuteecuPFJOzmoE648lMJaIqj8od8dfE7ZXSjeFhEeTbQjoimqR!F/v0yCdomDXPnMZSGwT+2qh6I1wXjz950IzwSwnPhKnmJzaVrn9EaY+m1smuvA3K6U95mMqVCyON
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 16901
 by: olcott - Fri, 28 Jan 2022 03:50 UTC

On 1/27/2022 9:44 PM, Richard Damon wrote:
> On 1/27/22 10:21 PM, olcott wrote:
>> On 1/27/2022 9:00 PM, Richard Damon wrote:
>>> On 1/27/22 9:51 PM, olcott wrote:
>>>> On 1/27/2022 8:23 PM, Richard Damon wrote:
>>>>> On 1/27/22 9:04 PM, olcott wrote:
>>>>>> On 1/27/2022 7:56 PM, Richard Damon wrote:
>>>>>>> On 1/27/22 7:47 PM, olcott wrote:
>>>>>>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>>>>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>>>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that only
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an infinite simulation of an infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence of configurations can recognize an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite sequence of configurations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^ based
>>>>>>>>>>>>>>>>>>>>>>>>>>>> on an H that at some point goest to H.Qn
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that correctly detects the infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>> patterns are only really infinite when you
>>>>>>>>>>>>>>>>>>>>>>>>>>>> work them out to infinitity.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces you
>>>>>>>>>>>>>>>>>>>>>>>>>>>> look at are wrong. When H simulates H^, it
>>>>>>>>>>>>>>>>>>>>>>>>>>>> needs to trace out the actual execution path
>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the H that part of H^, not switch to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> tracing what it was tracing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual capacity to
>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that when embedded_H simulates ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ this is the pattern:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY point,
>>>>>>>>>>>>>>>>>>>>>>>>>> then the above is NOT the accurate trace of
>>>>>>>>>>>>>>>>>>>>>>>>>> the behavior of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally applies
>>>>>>>>>>>>>>>>>>>>>>>>> to this case:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop infinitely
>>>>>>>>>>>>>>>>>>>>>>>>> it is not an accurate simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does abort
>>>>>>>>>>>>>>>>>>>>>>>> its simulation, then it needs to take into
>>>>>>>>>>>>>>>>>>>>>>>> account that the machine it is simulating will
>>>>>>>>>>>>>>>>>>>>>>>> do so too.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> As long as H correctly determines that its
>>>>>>>>>>>>>>>>>>>>>>> simulated input cannot possibly reach its final
>>>>>>>>>>>>>>>>>>>>>>> state in any finite number of steps it has
>>>>>>>>>>>>>>>>>>>>>>> conclusively proved that this input never halts
>>>>>>>>>>>>>>>>>>>>>>> according to the Linz definition:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its input
>>>>>>>>>>>>>>>>>>>>>> never halts, and for H^, that means even if the H
>>>>>>>>>>>>>>>>>>>>>> insisde H^ goes to H.Qn which means that H^ goes
>>>>>>>>>>>>>>>>>>>>>> to H^.Qn, which of course Halts.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that its
>>>>>>>>>>>>>>>>>>>>> simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly
>>>>>>>>>>>>>>>>>>>>> reach its final state in any finite number of steps
>>>>>>>>>>>>>>>>>>>>> it terminates this simulation immediately stopping
>>>>>>>>>>>>>>>>>>>>> every element of the entire chain of nested
>>>>>>>>>>>>>>>>>>>>> simulations.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If you are claiming that embedded_H and H behave
>>>>>>>>>>>>>>>>>>>> differently then you have been lying that you built
>>>>>>>>>>>>>>>>>>>> H^ by the instruction of Linz, as the copy of H
>>>>>>>>>>>>>>>>>>>> inside H^ is IDENTICAL (except what happens AFTER
>>>>>>>>>>>>>>>>>>>> getting to H.Qy)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Now, IF H could make that proof, then it would be
>>>>>>>>>>>>>>>>>>>> correct to go to H.Qn, but it would need to take
>>>>>>>>>>>>>>>>>>>> into account that H^ halts if its copy of H goes to
>>>>>>>>>>>>>>>>>>>> H.Qn, so this is NEVER possible.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which causes
>>>>>>>>>>>>>>>>>>>>> the original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ
>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ is not an input to embedded_H and a
>>>>>>>>>>>>>>>>>>>>> decider is only accountable for computing the
>>>>>>>>>>>>>>>>>>>>> mapping from its actual inputs to an accept or
>>>>>>>>>>>>>>>>>>>>> reject state it makes no difference that Ĥ applied
>>>>>>>>>>>>>>>>>>>>> to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thus you have admitted to LYING about working on the
>>>>>>>>>>>>>>>>>>>> Halting problem as if you were the embedded_H would
>>>>>>>>>>>>>>>>>>>> be the same algorithm as H, and the requirement on H
>>>>>>>>>>>>>>>>>>>> was that is IS accoutable for the machine its input
>>>>>>>>>>>>>>>>>>>> represents,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You are simply too freaking stupid to understand that
>>>>>>>>>>>>>>>>>>> deciders thus halt deciders are only accountable for
>>>>>>>>>>>>>>>>>>> computing the mapping from their actual inputs
>>>>>>>>>>>>>>>>>>> (nothing else in the whole freaking universe besides
>>>>>>>>>>>>>>>>>>> their actual inputs) to an accept or reject state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It seems you don't understand the difference between
>>>>>>>>>>>>>>>>>> capabilities and requirements.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it can do.
>>>>>>>>>>>>>>>>>> It can only computate a mapping based on what it
>>>>>>>>>>>>>>>>>> actually can do.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which is to
>>>>>>>>>>>>>>>>>> decide on the behavior of what its input would do if
>>>>>>>>>>>>>>>>>> given to a UTM.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> embedded_H must only determine whether or not is
>>>>>>>>>>>>>>>>> simulated input can ever reach its final state in any
>>>>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Again, you seem to be lying about working on the Halting
>>>>>>>>>>>>>>>> Problem and Linz proof.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If you were working on the Halting Problem and Linz
>>>>>>>>>>>>>>>> proof then embedded_H would be identical to H, as
>>>>>>>>>>>>>>>> required by Linz, and the correct answer for the
>>>>>>>>>>>>>>>> 'behavior' of the input to embedded_H <H^> <H^> would be
>>>>>>>>>>>>>>>> the behavior of UTM(<H^>,<H^>) which if embedded_H goes
>>>>>>>>>>>>>>>> to H.Qn then we know that H^ will go to H^.Qn and Halt,
>>>>>>>>>>>>>>>> and thus H/embedded_H going to H.Qn is incorrect.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So, you are just admitting that you are lying or are too
>>>>>>>>>>>>>>>> stupid to understan what you are talking about.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Which is it?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I will not tolerate any digression from the point at hand
>>>>>>>>>>>>>>> until we have mutual agreement. This is verified as
>>>>>>>>>>>>>>> completely true entirely on the basis of the meaning of
>>>>>>>>>>>>>>> its words:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> embedded_H must only determine whether or not its
>>>>>>>>>>>>>>> simulated input can
>>>>>>>>>>>>>>> ever reach its final state in any finite number of steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Translation: You will ignroe any disagreement with your
>>>>>>>>>>>>>> incorrect statement because you need to get people to
>>>>>>>>>>>>>> accept your falso premise for your unsound argument to work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The problem with your statement is that you are showing
>>>>>>>>>>>>>> that you atually mean something different than the true
>>>>>>>>>>>>>> meaning of the words.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H (and thus embedded_H) need to determine whether or not
>>>>>>>>>>>>>> its simuleted input will ever reach its final state for
>>>>>>>>>>>>>> EVERY POSSIBLE finite number of steps, i.e. as determine
>>>>>>>>>>>>>> by a UTM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ∃N such that the pure simulation of the input to embedded_H
>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Except that it does unless you are lying about H^ being built
>>>>>>>>>>> right, at least if H(<H^>,<H^>) -> H.Qn, and it doesn't
>>>>>>>>>>> matter what H^ does if H doesn't go to H.Qn, as H is then
>>>>>>>>>>> wrong because it didn't answer.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ∃N such that the pure simulation of the input to embedded_H
>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩ applied to
>>>>>>>>>> ⟨Ĥ⟩ specifies a sequence of configurations that do not halt
>>>>>>>>>>
>>>>>>>>>> even if they stop running because the simulation has been
>>>>>>>>>> aborted.
>>>>>>>>>>
>>>>>>>>>> I said that incorrectly only the above way of saying it is
>>>>>>>>>> accurate, the second way of saying it can be misinterpreted.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Except the pure simulation of the inputs to H/embeddd_H don't
>>>>>>>>> stop when H/embedded_H abrot their simulation
>>>>
>>>> Only a complete moron would say this.
>>>
>>> Why do you say that, since it is TRUE?
>>>
>> You total jackass know that there is only a single pure simulation of
>> N steps of the input.
>>
>
> Then what is the computation UTM(<H^>,<H^>) ???
>


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<d2KIJ.24507$541.2175@fx35.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx35.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me> <eXlIJ.16438$2W.334@fx36.iad>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 300
Message-ID: <d2KIJ.24507$541.2175@fx35.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: Thu, 27 Jan 2022 23:11:53 -0500
X-Received-Bytes: 17672
 by: Richard Damon - Fri, 28 Jan 2022 04:11 UTC

On 1/27/22 10:50 PM, olcott wrote:
> On 1/27/2022 9:44 PM, Richard Damon wrote:
>> On 1/27/22 10:21 PM, olcott wrote:
>>> On 1/27/2022 9:00 PM, Richard Damon wrote:
>>>> On 1/27/22 9:51 PM, olcott wrote:
>>>>> On 1/27/2022 8:23 PM, Richard Damon wrote:
>>>>>> On 1/27/22 9:04 PM, olcott wrote:
>>>>>>> On 1/27/2022 7:56 PM, Richard Damon wrote:
>>>>>>>> On 1/27/22 7:47 PM, olcott wrote:
>>>>>>>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>>>>>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>>>>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that only
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an infinite simulation of an infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence of configurations can recognize
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an infinite sequence of configurations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^ based
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on an H that at some point goest to H.Qn
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that correctly detects the infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> patterns are only really infinite when you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work them out to infinitity.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> look at are wrong. When H simulates H^, it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> needs to trace out the actual execution
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> path of the H that part of H^, not switch
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to tracing what it was tracing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual capacity to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that when embedded_H simulates
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ applied to ⟨Ĥ⟩ this is the pattern:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY point,
>>>>>>>>>>>>>>>>>>>>>>>>>>> then the above is NOT the accurate trace of
>>>>>>>>>>>>>>>>>>>>>>>>>>> the behavior of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally applies
>>>>>>>>>>>>>>>>>>>>>>>>>> to this case:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>> infinitely it is not an accurate simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does abort
>>>>>>>>>>>>>>>>>>>>>>>>> its simulation, then it needs to take into
>>>>>>>>>>>>>>>>>>>>>>>>> account that the machine it is simulating will
>>>>>>>>>>>>>>>>>>>>>>>>> do so too.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> As long as H correctly determines that its
>>>>>>>>>>>>>>>>>>>>>>>> simulated input cannot possibly reach its final
>>>>>>>>>>>>>>>>>>>>>>>> state in any finite number of steps it has
>>>>>>>>>>>>>>>>>>>>>>>> conclusively proved that this input never halts
>>>>>>>>>>>>>>>>>>>>>>>> according to the Linz definition:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its input
>>>>>>>>>>>>>>>>>>>>>>> never halts, and for H^, that means even if the H
>>>>>>>>>>>>>>>>>>>>>>> insisde H^ goes to H.Qn which means that H^ goes
>>>>>>>>>>>>>>>>>>>>>>> to H^.Qn, which of course Halts.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that its
>>>>>>>>>>>>>>>>>>>>>> simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly
>>>>>>>>>>>>>>>>>>>>>> reach its final state in any finite number of
>>>>>>>>>>>>>>>>>>>>>> steps it terminates this simulation immediately
>>>>>>>>>>>>>>>>>>>>>> stopping every element of the entire chain of
>>>>>>>>>>>>>>>>>>>>>> nested simulations.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If you are claiming that embedded_H and H behave
>>>>>>>>>>>>>>>>>>>>> differently then you have been lying that you built
>>>>>>>>>>>>>>>>>>>>> H^ by the instruction of Linz, as the copy of H
>>>>>>>>>>>>>>>>>>>>> inside H^ is IDENTICAL (except what happens AFTER
>>>>>>>>>>>>>>>>>>>>> getting to H.Qy)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Now, IF H could make that proof, then it would be
>>>>>>>>>>>>>>>>>>>>> correct to go to H.Qn, but it would need to take
>>>>>>>>>>>>>>>>>>>>> into account that H^ halts if its copy of H goes to
>>>>>>>>>>>>>>>>>>>>> H.Qn, so this is NEVER possible.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which causes
>>>>>>>>>>>>>>>>>>>>>> the original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ
>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ is not an input to embedded_H and a
>>>>>>>>>>>>>>>>>>>>>> decider is only accountable for computing the
>>>>>>>>>>>>>>>>>>>>>> mapping from its actual inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>> reject state it makes no difference that Ĥ applied
>>>>>>>>>>>>>>>>>>>>>> to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thus you have admitted to LYING about working on
>>>>>>>>>>>>>>>>>>>>> the Halting problem as if you were the embedded_H
>>>>>>>>>>>>>>>>>>>>> would be the same algorithm as H, and the
>>>>>>>>>>>>>>>>>>>>> requirement on H was that is IS accoutable for the
>>>>>>>>>>>>>>>>>>>>> machine its input represents,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You are simply too freaking stupid to understand
>>>>>>>>>>>>>>>>>>>> that deciders thus halt deciders are only
>>>>>>>>>>>>>>>>>>>> accountable for computing the mapping from their
>>>>>>>>>>>>>>>>>>>> actual inputs (nothing else in the whole freaking
>>>>>>>>>>>>>>>>>>>> universe besides their actual inputs) to an accept
>>>>>>>>>>>>>>>>>>>> or reject state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It seems you don't understand the difference between
>>>>>>>>>>>>>>>>>>> capabilities and requirements.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it can
>>>>>>>>>>>>>>>>>>> do. It can only computate a mapping based on what it
>>>>>>>>>>>>>>>>>>> actually can do.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which is to
>>>>>>>>>>>>>>>>>>> decide on the behavior of what its input would do if
>>>>>>>>>>>>>>>>>>> given to a UTM.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> embedded_H must only determine whether or not is
>>>>>>>>>>>>>>>>>> simulated input can ever reach its final state in any
>>>>>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Again, you seem to be lying about working on the
>>>>>>>>>>>>>>>>> Halting Problem and Linz proof.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If you were working on the Halting Problem and Linz
>>>>>>>>>>>>>>>>> proof then embedded_H would be identical to H, as
>>>>>>>>>>>>>>>>> required by Linz, and the correct answer for the
>>>>>>>>>>>>>>>>> 'behavior' of the input to embedded_H <H^> <H^> would
>>>>>>>>>>>>>>>>> be the behavior of UTM(<H^>,<H^>) which if embedded_H
>>>>>>>>>>>>>>>>> goes to H.Qn then we know that H^ will go to H^.Qn and
>>>>>>>>>>>>>>>>> Halt, and thus H/embedded_H going to H.Qn is incorrect.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So, you are just admitting that you are lying or are
>>>>>>>>>>>>>>>>> too stupid to understan what you are talking about.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Which is it?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I will not tolerate any digression from the point at
>>>>>>>>>>>>>>>> hand until we have mutual agreement. This is verified as
>>>>>>>>>>>>>>>> completely true entirely on the basis of the meaning of
>>>>>>>>>>>>>>>> its words:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> embedded_H must only determine whether or not its
>>>>>>>>>>>>>>>> simulated input can
>>>>>>>>>>>>>>>> ever reach its final state in any finite number of steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Translation: You will ignroe any disagreement with your
>>>>>>>>>>>>>>> incorrect statement because you need to get people to
>>>>>>>>>>>>>>> accept your falso premise for your unsound argument to work.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The problem with your statement is that you are showing
>>>>>>>>>>>>>>> that you atually mean something different than the true
>>>>>>>>>>>>>>> meaning of the words.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H (and thus embedded_H) need to determine whether or not
>>>>>>>>>>>>>>> its simuleted input will ever reach its final state for
>>>>>>>>>>>>>>> EVERY POSSIBLE finite number of steps, i.e. as determine
>>>>>>>>>>>>>>> by a UTM.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ∃N such that the pure simulation of the input to
>>>>>>>>>>>>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Except that it does unless you are lying about H^ being
>>>>>>>>>>>> built right, at least if H(<H^>,<H^>) -> H.Qn, and it
>>>>>>>>>>>> doesn't matter what H^ does if H doesn't go to H.Qn, as H is
>>>>>>>>>>>> then wrong because it didn't answer.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ∃N such that the pure simulation of the input to embedded_H
>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩ applied to
>>>>>>>>>>> ⟨Ĥ⟩ specifies a sequence of configurations that do not halt
>>>>>>>>>>>
>>>>>>>>>>> even if they stop running because the simulation has been
>>>>>>>>>>> aborted.
>>>>>>>>>>>
>>>>>>>>>>> I said that incorrectly only the above way of saying it is
>>>>>>>>>>> accurate, the second way of saying it can be misinterpreted.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Except the pure simulation of the inputs to H/embeddd_H don't
>>>>>>>>>> stop when H/embedded_H abrot their simulation
>>>>>
>>>>> Only a complete moron would say this.
>>>>
>>>> Why do you say that, since it is TRUE?
>>>>
>>> You total jackass know that there is only a single pure simulation of
>>> N steps of the input.
>>>
>>
>> Then what is the computation UTM(<H^>,<H^>) ???
>>
>
> Do I have to put this as a signature line so you don't forget it from
> one post to the next?
>
> We define Linz H to base its halt status decision on the behavior of its
> pure simulation of N steps of its input. N is either the number of steps
> that it takes for its simulated input to reach its final state or the
> number of steps required for H to match an infinite behavior pattern
> proving that its simulated input would never reach its own final state
> in any finite number of steps. In this case H aborts the simulation of
> this input and transitions to H.qn.
>
>


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 27 Jan 2022 22:20:40 -0600
Date: Thu, 27 Jan 2022 22:20:38 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <d2KIJ.24507$541.2175@fx35.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
Lines: 302
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-9RHotXT3IURL8RJnic4iByebkey/6AEsJ/DuLbRFkJRloOtgyoKTtIVwj3IwnwufrBXBajkt3t95BcD!zYuW0eB+7j2Xxv0+2xyXbgXkoBjfWOGhD99ipWhE9jm/Q2IZ7Pjn7NNr88Wbfk81tEzgxVoQobSS
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 18286
 by: olcott - Fri, 28 Jan 2022 04:20 UTC

On 1/27/2022 10:11 PM, Richard Damon wrote:
> On 1/27/22 10:50 PM, olcott wrote:
>> On 1/27/2022 9:44 PM, Richard Damon wrote:
>>> On 1/27/22 10:21 PM, olcott wrote:
>>>> On 1/27/2022 9:00 PM, Richard Damon wrote:
>>>>> On 1/27/22 9:51 PM, olcott wrote:
>>>>>> On 1/27/2022 8:23 PM, Richard Damon wrote:
>>>>>>> On 1/27/22 9:04 PM, olcott wrote:
>>>>>>>> On 1/27/2022 7:56 PM, Richard Damon wrote:
>>>>>>>>> On 1/27/22 7:47 PM, olcott wrote:
>>>>>>>>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>>>>>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>>>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only an infinite simulation of an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite sequence of configurations can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recognize an infinite sequence of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^ based
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on an H that at some point goest to H.Qn
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that correctly detects the infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> patterns are only really infinite when you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work them out to infinitity.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you look at are wrong. When H simulates
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H^, it needs to trace out the actual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution path of the H that part of H^,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not switch to tracing what it was tracing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual capacity
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to understand that when embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ this is the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY point,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> then the above is NOT the accurate trace of
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the behavior of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally
>>>>>>>>>>>>>>>>>>>>>>>>>>> applies to this case:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitely it is not an accurate simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does abort
>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation, then it needs to take into
>>>>>>>>>>>>>>>>>>>>>>>>>> account that the machine it is simulating will
>>>>>>>>>>>>>>>>>>>>>>>>>> do so too.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> As long as H correctly determines that its
>>>>>>>>>>>>>>>>>>>>>>>>> simulated input cannot possibly reach its final
>>>>>>>>>>>>>>>>>>>>>>>>> state in any finite number of steps it has
>>>>>>>>>>>>>>>>>>>>>>>>> conclusively proved that this input never halts
>>>>>>>>>>>>>>>>>>>>>>>>> according to the Linz definition:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its input
>>>>>>>>>>>>>>>>>>>>>>>> never halts, and for H^, that means even if the
>>>>>>>>>>>>>>>>>>>>>>>> H insisde H^ goes to H.Qn which means that H^
>>>>>>>>>>>>>>>>>>>>>>>> goes to H^.Qn, which of course Halts.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that its
>>>>>>>>>>>>>>>>>>>>>>> simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot
>>>>>>>>>>>>>>>>>>>>>>> possibly reach its final state in any finite
>>>>>>>>>>>>>>>>>>>>>>> number of steps it terminates this simulation
>>>>>>>>>>>>>>>>>>>>>>> immediately stopping every element of the entire
>>>>>>>>>>>>>>>>>>>>>>> chain of nested simulations.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If you are claiming that embedded_H and H behave
>>>>>>>>>>>>>>>>>>>>>> differently then you have been lying that you
>>>>>>>>>>>>>>>>>>>>>> built H^ by the instruction of Linz, as the copy
>>>>>>>>>>>>>>>>>>>>>> of H inside H^ is IDENTICAL (except what happens
>>>>>>>>>>>>>>>>>>>>>> AFTER getting to H.Qy)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Now, IF H could make that proof, then it would be
>>>>>>>>>>>>>>>>>>>>>> correct to go to H.Qn, but it would need to take
>>>>>>>>>>>>>>>>>>>>>> into account that H^ halts if its copy of H goes
>>>>>>>>>>>>>>>>>>>>>> to H.Qn, so this is NEVER possible.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which causes
>>>>>>>>>>>>>>>>>>>>>>> the original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ
>>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ is not an input to embedded_H and
>>>>>>>>>>>>>>>>>>>>>>> a decider is only accountable for computing the
>>>>>>>>>>>>>>>>>>>>>>> mapping from its actual inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>> reject state it makes no difference that Ĥ
>>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thus you have admitted to LYING about working on
>>>>>>>>>>>>>>>>>>>>>> the Halting problem as if you were the embedded_H
>>>>>>>>>>>>>>>>>>>>>> would be the same algorithm as H, and the
>>>>>>>>>>>>>>>>>>>>>> requirement on H was that is IS accoutable for the
>>>>>>>>>>>>>>>>>>>>>> machine its input represents,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You are simply too freaking stupid to understand
>>>>>>>>>>>>>>>>>>>>> that deciders thus halt deciders are only
>>>>>>>>>>>>>>>>>>>>> accountable for computing the mapping from their
>>>>>>>>>>>>>>>>>>>>> actual inputs (nothing else in the whole freaking
>>>>>>>>>>>>>>>>>>>>> universe besides their actual inputs) to an accept
>>>>>>>>>>>>>>>>>>>>> or reject state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It seems you don't understand the difference between
>>>>>>>>>>>>>>>>>>>> capabilities and requirements.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it can
>>>>>>>>>>>>>>>>>>>> do. It can only computate a mapping based on what it
>>>>>>>>>>>>>>>>>>>> actually can do.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which is to
>>>>>>>>>>>>>>>>>>>> decide on the behavior of what its input would do if
>>>>>>>>>>>>>>>>>>>> given to a UTM.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> embedded_H must only determine whether or not is
>>>>>>>>>>>>>>>>>>> simulated input can ever reach its final state in any
>>>>>>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Again, you seem to be lying about working on the
>>>>>>>>>>>>>>>>>> Halting Problem and Linz proof.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If you were working on the Halting Problem and Linz
>>>>>>>>>>>>>>>>>> proof then embedded_H would be identical to H, as
>>>>>>>>>>>>>>>>>> required by Linz, and the correct answer for the
>>>>>>>>>>>>>>>>>> 'behavior' of the input to embedded_H <H^> <H^> would
>>>>>>>>>>>>>>>>>> be the behavior of UTM(<H^>,<H^>) which if embedded_H
>>>>>>>>>>>>>>>>>> goes to H.Qn then we know that H^ will go to H^.Qn and
>>>>>>>>>>>>>>>>>> Halt, and thus H/embedded_H going to H.Qn is incorrect.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So, you are just admitting that you are lying or are
>>>>>>>>>>>>>>>>>> too stupid to understan what you are talking about.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Which is it?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I will not tolerate any digression from the point at
>>>>>>>>>>>>>>>>> hand until we have mutual agreement. This is verified
>>>>>>>>>>>>>>>>> as completely true entirely on the basis of the meaning
>>>>>>>>>>>>>>>>> of its words:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> embedded_H must only determine whether or not its
>>>>>>>>>>>>>>>>> simulated input can
>>>>>>>>>>>>>>>>> ever reach its final state in any finite number of steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Translation: You will ignroe any disagreement with your
>>>>>>>>>>>>>>>> incorrect statement because you need to get people to
>>>>>>>>>>>>>>>> accept your falso premise for your unsound argument to
>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The problem with your statement is that you are showing
>>>>>>>>>>>>>>>> that you atually mean something different than the true
>>>>>>>>>>>>>>>> meaning of the words.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H (and thus embedded_H) need to determine whether or not
>>>>>>>>>>>>>>>> its simuleted input will ever reach its final state for
>>>>>>>>>>>>>>>> EVERY POSSIBLE finite number of steps, i.e. as determine
>>>>>>>>>>>>>>>> by a UTM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ∃N such that the pure simulation of the input to
>>>>>>>>>>>>>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Except that it does unless you are lying about H^ being
>>>>>>>>>>>>> built right, at least if H(<H^>,<H^>) -> H.Qn, and it
>>>>>>>>>>>>> doesn't matter what H^ does if H doesn't go to H.Qn, as H
>>>>>>>>>>>>> is then wrong because it didn't answer.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ∃N such that the pure simulation of the input to embedded_H
>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩ applied
>>>>>>>>>>>> to ⟨Ĥ⟩ specifies a sequence of configurations that do not halt
>>>>>>>>>>>>
>>>>>>>>>>>> even if they stop running because the simulation has been
>>>>>>>>>>>> aborted.
>>>>>>>>>>>>
>>>>>>>>>>>> I said that incorrectly only the above way of saying it is
>>>>>>>>>>>> accurate, the second way of saying it can be misinterpreted.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Except the pure simulation of the inputs to H/embeddd_H don't
>>>>>>>>>>> stop when H/embedded_H abrot their simulation
>>>>>>
>>>>>> Only a complete moron would say this.
>>>>>
>>>>> Why do you say that, since it is TRUE?
>>>>>
>>>> You total jackass know that there is only a single pure simulation
>>>> of N steps of the input.
>>>>
>>>
>>> Then what is the computation UTM(<H^>,<H^>) ???
>>>
>>
>> Do I have to put this as a signature line so you don't forget it from
>> one post to the next?
>>
>> We define Linz H to base its halt status decision on the behavior of
>> its pure simulation of N steps of its input. N is either the number of
>> steps that it takes for its simulated input to reach its final state
>> or the number of steps required for H to match an infinite behavior
>> pattern proving that its simulated input would never reach its own
>> final state in any finite number of steps. In this case H aborts the
>> simulation of this input and transitions to H.qn.
>>
>>
>
> You are using your Fairy Dust Powered Unicorns again. There is no
> pattern you can find in a finite numbe N steps that 'proves' that H's
> simulation of <H^> <H^> will never halt when H takes into account that
> the H inside H^ will also use that pattern, BECAUSE any pattern that H
> sees, if it uses that as a pattern it wants to claim will do that, then
> it turns out that with such an H, H^(<H^>) will halt.


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<QRKIJ.10111$uP.9595@fx16.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx16.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 320
Message-ID: <QRKIJ.10111$uP.9595@fx16.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 28 Jan 2022 00:06:56 -0500
X-Received-Bytes: 19018
 by: Richard Damon - Fri, 28 Jan 2022 05:06 UTC

On 1/27/22 11:20 PM, olcott wrote:
> On 1/27/2022 10:11 PM, Richard Damon wrote:
>> On 1/27/22 10:50 PM, olcott wrote:
>>> On 1/27/2022 9:44 PM, Richard Damon wrote:
>>>> On 1/27/22 10:21 PM, olcott wrote:
>>>>> On 1/27/2022 9:00 PM, Richard Damon wrote:
>>>>>> On 1/27/22 9:51 PM, olcott wrote:
>>>>>>> On 1/27/2022 8:23 PM, Richard Damon wrote:
>>>>>>>> On 1/27/22 9:04 PM, olcott wrote:
>>>>>>>>> On 1/27/2022 7:56 PM, Richard Damon wrote:
>>>>>>>>>> On 1/27/22 7:47 PM, olcott wrote:
>>>>>>>>>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>>>>>>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>>>>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only an infinite simulation of an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite sequence of configurations can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recognize an infinite sequence of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> based on an H that at some point goest to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H.Qn that correctly detects the infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> patterns are only really infinite when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you work them out to infinitity.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you look at are wrong. When H simulates
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H^, it needs to trace out the actual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution path of the H that part of H^,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not switch to tracing what it was tracing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual capacity
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to understand that when embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ this is the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> point, then the above is NOT the accurate
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> trace of the behavior of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally
>>>>>>>>>>>>>>>>>>>>>>>>>>>> applies to this case:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitely it is not an accurate simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does
>>>>>>>>>>>>>>>>>>>>>>>>>>> abort its simulation, then it needs to take
>>>>>>>>>>>>>>>>>>>>>>>>>>> into account that the machine it is
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating will do so too.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> As long as H correctly determines that its
>>>>>>>>>>>>>>>>>>>>>>>>>> simulated input cannot possibly reach its
>>>>>>>>>>>>>>>>>>>>>>>>>> final state in any finite number of steps it
>>>>>>>>>>>>>>>>>>>>>>>>>> has conclusively proved that this input never
>>>>>>>>>>>>>>>>>>>>>>>>>> halts according to the Linz definition:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its input
>>>>>>>>>>>>>>>>>>>>>>>>> never halts, and for H^, that means even if the
>>>>>>>>>>>>>>>>>>>>>>>>> H insisde H^ goes to H.Qn which means that H^
>>>>>>>>>>>>>>>>>>>>>>>>> goes to H^.Qn, which of course Halts.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that
>>>>>>>>>>>>>>>>>>>>>>>> its simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot
>>>>>>>>>>>>>>>>>>>>>>>> possibly reach its final state in any finite
>>>>>>>>>>>>>>>>>>>>>>>> number of steps it terminates this simulation
>>>>>>>>>>>>>>>>>>>>>>>> immediately stopping every element of the entire
>>>>>>>>>>>>>>>>>>>>>>>> chain of nested simulations.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If you are claiming that embedded_H and H behave
>>>>>>>>>>>>>>>>>>>>>>> differently then you have been lying that you
>>>>>>>>>>>>>>>>>>>>>>> built H^ by the instruction of Linz, as the copy
>>>>>>>>>>>>>>>>>>>>>>> of H inside H^ is IDENTICAL (except what happens
>>>>>>>>>>>>>>>>>>>>>>> AFTER getting to H.Qy)
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Now, IF H could make that proof, then it would be
>>>>>>>>>>>>>>>>>>>>>>> correct to go to H.Qn, but it would need to take
>>>>>>>>>>>>>>>>>>>>>>> into account that H^ halts if its copy of H goes
>>>>>>>>>>>>>>>>>>>>>>> to H.Qn, so this is NEVER possible.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which causes
>>>>>>>>>>>>>>>>>>>>>>>> the original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ
>>>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ is not an input to embedded_H and
>>>>>>>>>>>>>>>>>>>>>>>> a decider is only accountable for computing the
>>>>>>>>>>>>>>>>>>>>>>>> mapping from its actual inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>> reject state it makes no difference that Ĥ
>>>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thus you have admitted to LYING about working on
>>>>>>>>>>>>>>>>>>>>>>> the Halting problem as if you were the embedded_H
>>>>>>>>>>>>>>>>>>>>>>> would be the same algorithm as H, and the
>>>>>>>>>>>>>>>>>>>>>>> requirement on H was that is IS accoutable for
>>>>>>>>>>>>>>>>>>>>>>> the machine its input represents,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You are simply too freaking stupid to understand
>>>>>>>>>>>>>>>>>>>>>> that deciders thus halt deciders are only
>>>>>>>>>>>>>>>>>>>>>> accountable for computing the mapping from their
>>>>>>>>>>>>>>>>>>>>>> actual inputs (nothing else in the whole freaking
>>>>>>>>>>>>>>>>>>>>>> universe besides their actual inputs) to an accept
>>>>>>>>>>>>>>>>>>>>>> or reject state.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It seems you don't understand the difference
>>>>>>>>>>>>>>>>>>>>> between capabilities and requirements.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it can
>>>>>>>>>>>>>>>>>>>>> do. It can only computate a mapping based on what
>>>>>>>>>>>>>>>>>>>>> it actually can do.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which is
>>>>>>>>>>>>>>>>>>>>> to decide on the behavior of what its input would
>>>>>>>>>>>>>>>>>>>>> do if given to a UTM.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> embedded_H must only determine whether or not is
>>>>>>>>>>>>>>>>>>>> simulated input can ever reach its final state in
>>>>>>>>>>>>>>>>>>>> any finite number of steps.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Again, you seem to be lying about working on the
>>>>>>>>>>>>>>>>>>> Halting Problem and Linz proof.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If you were working on the Halting Problem and Linz
>>>>>>>>>>>>>>>>>>> proof then embedded_H would be identical to H, as
>>>>>>>>>>>>>>>>>>> required by Linz, and the correct answer for the
>>>>>>>>>>>>>>>>>>> 'behavior' of the input to embedded_H <H^> <H^> would
>>>>>>>>>>>>>>>>>>> be the behavior of UTM(<H^>,<H^>) which if embedded_H
>>>>>>>>>>>>>>>>>>> goes to H.Qn then we know that H^ will go to H^.Qn
>>>>>>>>>>>>>>>>>>> and Halt, and thus H/embedded_H going to H.Qn is
>>>>>>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So, you are just admitting that you are lying or are
>>>>>>>>>>>>>>>>>>> too stupid to understan what you are talking about.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Which is it?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I will not tolerate any digression from the point at
>>>>>>>>>>>>>>>>>> hand until we have mutual agreement. This is verified
>>>>>>>>>>>>>>>>>> as completely true entirely on the basis of the
>>>>>>>>>>>>>>>>>> meaning of its words:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> embedded_H must only determine whether or not its
>>>>>>>>>>>>>>>>>> simulated input can
>>>>>>>>>>>>>>>>>> ever reach its final state in any finite number of steps.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Translation: You will ignroe any disagreement with your
>>>>>>>>>>>>>>>>> incorrect statement because you need to get people to
>>>>>>>>>>>>>>>>> accept your falso premise for your unsound argument to
>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The problem with your statement is that you are showing
>>>>>>>>>>>>>>>>> that you atually mean something different than the true
>>>>>>>>>>>>>>>>> meaning of the words.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H (and thus embedded_H) need to determine whether or
>>>>>>>>>>>>>>>>> not its simuleted input will ever reach its final state
>>>>>>>>>>>>>>>>> for EVERY POSSIBLE finite number of steps, i.e. as
>>>>>>>>>>>>>>>>> determine by a UTM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ∃N such that the pure simulation of the input to
>>>>>>>>>>>>>>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Except that it does unless you are lying about H^ being
>>>>>>>>>>>>>> built right, at least if H(<H^>,<H^>) -> H.Qn, and it
>>>>>>>>>>>>>> doesn't matter what H^ does if H doesn't go to H.Qn, as H
>>>>>>>>>>>>>> is then wrong because it didn't answer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ∃N such that the pure simulation of the input to embedded_H
>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩ applied
>>>>>>>>>>>>> to ⟨Ĥ⟩ specifies a sequence of configurations that do not halt
>>>>>>>>>>>>>
>>>>>>>>>>>>> even if they stop running because the simulation has been
>>>>>>>>>>>>> aborted.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I said that incorrectly only the above way of saying it is
>>>>>>>>>>>>> accurate, the second way of saying it can be misinterpreted.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Except the pure simulation of the inputs to H/embeddd_H
>>>>>>>>>>>> don't stop when H/embedded_H abrot their simulation
>>>>>>>
>>>>>>> Only a complete moron would say this.
>>>>>>
>>>>>> Why do you say that, since it is TRUE?
>>>>>>
>>>>> You total jackass know that there is only a single pure simulation
>>>>> of N steps of the input.
>>>>>
>>>>
>>>> Then what is the computation UTM(<H^>,<H^>) ???
>>>>
>>>
>>> Do I have to put this as a signature line so you don't forget it from
>>> one post to the next?
>>>
>>> We define Linz H to base its halt status decision on the behavior of
>>> its pure simulation of N steps of its input. N is either the number
>>> of steps that it takes for its simulated input to reach its final
>>> state or the number of steps required for H to match an infinite
>>> behavior pattern proving that its simulated input would never reach
>>> its own final state in any finite number of steps. In this case H
>>> aborts the simulation of this input and transitions to H.qn.
>>>
>>>
>>
>> You are using your Fairy Dust Powered Unicorns again. There is no
>> pattern you can find in a finite numbe N steps that 'proves' that H's
>> simulation of <H^> <H^> will never halt when H takes into account that
>> the H inside H^ will also use that pattern, BECAUSE any pattern that H
>> sees, if it uses that as a pattern it wants to claim will do that,
>> then it turns out that with such an H, H^(<H^>) will halt.
>
> The outermost invocation of embedded_H sees the most nested simulation
> steps thus is able to abort the inner simulations before they have seen
> enough to know that they need to do this.
>


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 27 Jan 2022 23:22:42 -0600
Date: Thu, 27 Jan 2022 23:22:40 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <QRKIJ.10111$uP.9595@fx16.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
Lines: 339
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-7i9bt1yK1+H/QKQ2Z6TFD6QIZSt+DIZRP8tCs78pg1ra3gACeztdALEQgilzsMv1vwhpDh99dF03Ech!YLgGRVIsNT/XeckQ1GTvx5KJf7iVu0VOcOKugQK+wUjAqflu52vdKdi4eDlaNwW6I6MBS2zJhUrd
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 20105
 by: olcott - Fri, 28 Jan 2022 05:22 UTC

On 1/27/2022 11:06 PM, Richard Damon wrote:
> On 1/27/22 11:20 PM, olcott wrote:
>> On 1/27/2022 10:11 PM, Richard Damon wrote:
>>> On 1/27/22 10:50 PM, olcott wrote:
>>>> On 1/27/2022 9:44 PM, Richard Damon wrote:
>>>>> On 1/27/22 10:21 PM, olcott wrote:
>>>>>> On 1/27/2022 9:00 PM, Richard Damon wrote:
>>>>>>> On 1/27/22 9:51 PM, olcott wrote:
>>>>>>>> On 1/27/2022 8:23 PM, Richard Damon wrote:
>>>>>>>>> On 1/27/22 9:04 PM, olcott wrote:
>>>>>>>>>> On 1/27/2022 7:56 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/27/22 7:47 PM, olcott wrote:
>>>>>>>>>>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>>>>>>>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only an infinite simulation of an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite sequence of configurations can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recognize an infinite sequence of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> based on an H that at some point goest
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to H.Qn that correctly detects the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite patterns are only really
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite when you work them out to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitity.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you look at are wrong. When H simulates
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H^, it needs to trace out the actual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution path of the H that part of H^,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not switch to tracing what it was tracing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual capacity
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to understand that when embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ this is the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> point, then the above is NOT the accurate
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> trace of the behavior of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BECAUSE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> applies to this case:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitely it is not an accurate simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does
>>>>>>>>>>>>>>>>>>>>>>>>>>>> abort its simulation, then it needs to take
>>>>>>>>>>>>>>>>>>>>>>>>>>>> into account that the machine it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating will do so too.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> As long as H correctly determines that its
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated input cannot possibly reach its
>>>>>>>>>>>>>>>>>>>>>>>>>>> final state in any finite number of steps it
>>>>>>>>>>>>>>>>>>>>>>>>>>> has conclusively proved that this input never
>>>>>>>>>>>>>>>>>>>>>>>>>>> halts according to the Linz definition:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its
>>>>>>>>>>>>>>>>>>>>>>>>>> input never halts, and for H^, that means even
>>>>>>>>>>>>>>>>>>>>>>>>>> if the H insisde H^ goes to H.Qn which means
>>>>>>>>>>>>>>>>>>>>>>>>>> that H^ goes to H^.Qn, which of course Halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that
>>>>>>>>>>>>>>>>>>>>>>>>> its simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot
>>>>>>>>>>>>>>>>>>>>>>>>> possibly reach its final state in any finite
>>>>>>>>>>>>>>>>>>>>>>>>> number of steps it terminates this simulation
>>>>>>>>>>>>>>>>>>>>>>>>> immediately stopping every element of the
>>>>>>>>>>>>>>>>>>>>>>>>> entire chain of nested simulations.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> If you are claiming that embedded_H and H behave
>>>>>>>>>>>>>>>>>>>>>>>> differently then you have been lying that you
>>>>>>>>>>>>>>>>>>>>>>>> built H^ by the instruction of Linz, as the copy
>>>>>>>>>>>>>>>>>>>>>>>> of H inside H^ is IDENTICAL (except what happens
>>>>>>>>>>>>>>>>>>>>>>>> AFTER getting to H.Qy)
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Now, IF H could make that proof, then it would
>>>>>>>>>>>>>>>>>>>>>>>> be correct to go to H.Qn, but it would need to
>>>>>>>>>>>>>>>>>>>>>>>> take into account that H^ halts if its copy of H
>>>>>>>>>>>>>>>>>>>>>>>> goes to H.Qn, so this is NEVER possible.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which
>>>>>>>>>>>>>>>>>>>>>>>>> causes the original Ĥ applied to ⟨Ĥ⟩ to halt.
>>>>>>>>>>>>>>>>>>>>>>>>> Since Ĥ applied to ⟨Ĥ⟩ is not an input to
>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H and a decider is only accountable
>>>>>>>>>>>>>>>>>>>>>>>>> for computing the mapping from its actual
>>>>>>>>>>>>>>>>>>>>>>>>> inputs to an accept or reject state it makes no
>>>>>>>>>>>>>>>>>>>>>>>>> difference that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thus you have admitted to LYING about working on
>>>>>>>>>>>>>>>>>>>>>>>> the Halting problem as if you were the
>>>>>>>>>>>>>>>>>>>>>>>> embedded_H would be the same algorithm as H, and
>>>>>>>>>>>>>>>>>>>>>>>> the requirement on H was that is IS accoutable
>>>>>>>>>>>>>>>>>>>>>>>> for the machine its input represents,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> You are simply too freaking stupid to understand
>>>>>>>>>>>>>>>>>>>>>>> that deciders thus halt deciders are only
>>>>>>>>>>>>>>>>>>>>>>> accountable for computing the mapping from their
>>>>>>>>>>>>>>>>>>>>>>> actual inputs (nothing else in the whole freaking
>>>>>>>>>>>>>>>>>>>>>>> universe besides their actual inputs) to an
>>>>>>>>>>>>>>>>>>>>>>> accept or reject state.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It seems you don't understand the difference
>>>>>>>>>>>>>>>>>>>>>> between capabilities and requirements.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it can
>>>>>>>>>>>>>>>>>>>>>> do. It can only computate a mapping based on what
>>>>>>>>>>>>>>>>>>>>>> it actually can do.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which is
>>>>>>>>>>>>>>>>>>>>>> to decide on the behavior of what its input would
>>>>>>>>>>>>>>>>>>>>>> do if given to a UTM.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> embedded_H must only determine whether or not is
>>>>>>>>>>>>>>>>>>>>> simulated input can ever reach its final state in
>>>>>>>>>>>>>>>>>>>>> any finite number of steps.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Again, you seem to be lying about working on the
>>>>>>>>>>>>>>>>>>>> Halting Problem and Linz proof.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If you were working on the Halting Problem and Linz
>>>>>>>>>>>>>>>>>>>> proof then embedded_H would be identical to H, as
>>>>>>>>>>>>>>>>>>>> required by Linz, and the correct answer for the
>>>>>>>>>>>>>>>>>>>> 'behavior' of the input to embedded_H <H^> <H^>
>>>>>>>>>>>>>>>>>>>> would be the behavior of UTM(<H^>,<H^>) which if
>>>>>>>>>>>>>>>>>>>> embedded_H goes to H.Qn then we know that H^ will go
>>>>>>>>>>>>>>>>>>>> to H^.Qn and Halt, and thus H/embedded_H going to
>>>>>>>>>>>>>>>>>>>> H.Qn is incorrect.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So, you are just admitting that you are lying or are
>>>>>>>>>>>>>>>>>>>> too stupid to understan what you are talking about.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Which is it?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I will not tolerate any digression from the point at
>>>>>>>>>>>>>>>>>>> hand until we have mutual agreement. This is verified
>>>>>>>>>>>>>>>>>>> as completely true entirely on the basis of the
>>>>>>>>>>>>>>>>>>> meaning of its words:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> embedded_H must only determine whether or not its
>>>>>>>>>>>>>>>>>>> simulated input can
>>>>>>>>>>>>>>>>>>> ever reach its final state in any finite number of
>>>>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Translation: You will ignroe any disagreement with
>>>>>>>>>>>>>>>>>> your incorrect statement because you need to get
>>>>>>>>>>>>>>>>>> people to accept your falso premise for your unsound
>>>>>>>>>>>>>>>>>> argument to work.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The problem with your statement is that you are
>>>>>>>>>>>>>>>>>> showing that you atually mean something different than
>>>>>>>>>>>>>>>>>> the true meaning of the words.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H (and thus embedded_H) need to determine whether or
>>>>>>>>>>>>>>>>>> not its simuleted input will ever reach its final
>>>>>>>>>>>>>>>>>> state for EVERY POSSIBLE finite number of steps, i.e.
>>>>>>>>>>>>>>>>>> as determine by a UTM.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ∃N such that the pure simulation of the input to
>>>>>>>>>>>>>>>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Except that it does unless you are lying about H^ being
>>>>>>>>>>>>>>> built right, at least if H(<H^>,<H^>) -> H.Qn, and it
>>>>>>>>>>>>>>> doesn't matter what H^ does if H doesn't go to H.Qn, as H
>>>>>>>>>>>>>>> is then wrong because it didn't answer.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ∃N such that the pure simulation of the input to
>>>>>>>>>>>>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩ applied
>>>>>>>>>>>>>> to ⟨Ĥ⟩ specifies a sequence of configurations that do not
>>>>>>>>>>>>>> halt
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> even if they stop running because the simulation has been
>>>>>>>>>>>>>> aborted.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I said that incorrectly only the above way of saying it is
>>>>>>>>>>>>>> accurate, the second way of saying it can be misinterpreted.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Except the pure simulation of the inputs to H/embeddd_H
>>>>>>>>>>>>> don't stop when H/embedded_H abrot their simulation
>>>>>>>>
>>>>>>>> Only a complete moron would say this.
>>>>>>>
>>>>>>> Why do you say that, since it is TRUE?
>>>>>>>
>>>>>> You total jackass know that there is only a single pure simulation
>>>>>> of N steps of the input.
>>>>>>
>>>>>
>>>>> Then what is the computation UTM(<H^>,<H^>) ???
>>>>>
>>>>
>>>> Do I have to put this as a signature line so you don't forget it
>>>> from one post to the next?
>>>>
>>>> We define Linz H to base its halt status decision on the behavior of
>>>> its pure simulation of N steps of its input. N is either the number
>>>> of steps that it takes for its simulated input to reach its final
>>>> state or the number of steps required for H to match an infinite
>>>> behavior pattern proving that its simulated input would never reach
>>>> its own final state in any finite number of steps. In this case H
>>>> aborts the simulation of this input and transitions to H.qn.
>>>>
>>>>
>>>
>>> You are using your Fairy Dust Powered Unicorns again. There is no
>>> pattern you can find in a finite numbe N steps that 'proves' that H's
>>> simulation of <H^> <H^> will never halt when H takes into account
>>> that the H inside H^ will also use that pattern, BECAUSE any pattern
>>> that H sees, if it uses that as a pattern it wants to claim will do
>>> that, then it turns out that with such an H, H^(<H^>) will halt.
>>
>> The outermost invocation of embedded_H sees the most nested simulation
>> steps thus is able to abort the inner simulations before they have
>> seen enough to know that they need to do this.
>>
>
> WRONG.
>
> Remember, the definition of Halting is based on running the computation
> the input represents, (or the UTM simulation of that input), and the
> outer H/embedded_H CAN'T abort that operation, because it is independent
> of it.
>


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<mIQIJ.34880$%T.27606@fx06.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!npeer.as286.net!npeer-ng0.as286.net!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.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:91.0)
Gecko/20100101 Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me> <csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 354
Message-ID: <mIQIJ.34880$%T.27606@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: Fri, 28 Jan 2022 06:46:25 -0500
X-Received-Bytes: 20652
 by: Richard Damon - Fri, 28 Jan 2022 11:46 UTC

On 1/28/22 12:22 AM, olcott wrote:
> On 1/27/2022 11:06 PM, Richard Damon wrote:
>> On 1/27/22 11:20 PM, olcott wrote:
>>> On 1/27/2022 10:11 PM, Richard Damon wrote:
>>>> On 1/27/22 10:50 PM, olcott wrote:
>>>>> On 1/27/2022 9:44 PM, Richard Damon wrote:
>>>>>> On 1/27/22 10:21 PM, olcott wrote:
>>>>>>> On 1/27/2022 9:00 PM, Richard Damon wrote:
>>>>>>>> On 1/27/22 9:51 PM, olcott wrote:
>>>>>>>>> On 1/27/2022 8:23 PM, Richard Damon wrote:
>>>>>>>>>> On 1/27/22 9:04 PM, olcott wrote:
>>>>>>>>>>> On 1/27/2022 7:56 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/27/22 7:47 PM, olcott wrote:
>>>>>>>>>>>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>>>>>>>>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only an infinite simulation of an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite sequence of configurations
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can recognize an infinite sequence of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> based on an H that at some point goest
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to H.Qn that correctly detects the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite patterns are only really
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite when you work them out to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitity.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the traces
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you look at are wrong. When H simulates
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H^, it needs to trace out the actual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution path of the H that part of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H^, not switch to tracing what it was
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tracing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> capacity to understand that when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this is the pattern:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> point, then the above is NOT the accurate
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> trace of the behavior of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BECAUSE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> applies to this case:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitely it is not an accurate simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> abort its simulation, then it needs to take
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> into account that the machine it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating will do so too.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> As long as H correctly determines that its
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated input cannot possibly reach its
>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state in any finite number of steps it
>>>>>>>>>>>>>>>>>>>>>>>>>>>> has conclusively proved that this input
>>>>>>>>>>>>>>>>>>>>>>>>>>>> never halts according to the Linz definition:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its
>>>>>>>>>>>>>>>>>>>>>>>>>>> input never halts, and for H^, that means
>>>>>>>>>>>>>>>>>>>>>>>>>>> even if the H insisde H^ goes to H.Qn which
>>>>>>>>>>>>>>>>>>>>>>>>>>> means that H^ goes to H^.Qn, which of course
>>>>>>>>>>>>>>>>>>>>>>>>>>> Halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that
>>>>>>>>>>>>>>>>>>>>>>>>>> its simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot
>>>>>>>>>>>>>>>>>>>>>>>>>> possibly reach its final state in any finite
>>>>>>>>>>>>>>>>>>>>>>>>>> number of steps it terminates this simulation
>>>>>>>>>>>>>>>>>>>>>>>>>> immediately stopping every element of the
>>>>>>>>>>>>>>>>>>>>>>>>>> entire chain of nested simulations.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> If you are claiming that embedded_H and H
>>>>>>>>>>>>>>>>>>>>>>>>> behave differently then you have been lying
>>>>>>>>>>>>>>>>>>>>>>>>> that you built H^ by the instruction of Linz,
>>>>>>>>>>>>>>>>>>>>>>>>> as the copy of H inside H^ is IDENTICAL (except
>>>>>>>>>>>>>>>>>>>>>>>>> what happens AFTER getting to H.Qy)
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Now, IF H could make that proof, then it would
>>>>>>>>>>>>>>>>>>>>>>>>> be correct to go to H.Qn, but it would need to
>>>>>>>>>>>>>>>>>>>>>>>>> take into account that H^ halts if its copy of
>>>>>>>>>>>>>>>>>>>>>>>>> H goes to H.Qn, so this is NEVER possible.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which
>>>>>>>>>>>>>>>>>>>>>>>>>> causes the original Ĥ applied to ⟨Ĥ⟩ to halt.
>>>>>>>>>>>>>>>>>>>>>>>>>> Since Ĥ applied to ⟨Ĥ⟩ is not an input to
>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H and a decider is only accountable
>>>>>>>>>>>>>>>>>>>>>>>>>> for computing the mapping from its actual
>>>>>>>>>>>>>>>>>>>>>>>>>> inputs to an accept or reject state it makes
>>>>>>>>>>>>>>>>>>>>>>>>>> no difference that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thus you have admitted to LYING about working
>>>>>>>>>>>>>>>>>>>>>>>>> on the Halting problem as if you were the
>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H would be the same algorithm as H,
>>>>>>>>>>>>>>>>>>>>>>>>> and the requirement on H was that is IS
>>>>>>>>>>>>>>>>>>>>>>>>> accoutable for the machine its input represents,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You are simply too freaking stupid to understand
>>>>>>>>>>>>>>>>>>>>>>>> that deciders thus halt deciders are only
>>>>>>>>>>>>>>>>>>>>>>>> accountable for computing the mapping from their
>>>>>>>>>>>>>>>>>>>>>>>> actual inputs (nothing else in the whole
>>>>>>>>>>>>>>>>>>>>>>>> freaking universe besides their actual inputs)
>>>>>>>>>>>>>>>>>>>>>>>> to an accept or reject state.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It seems you don't understand the difference
>>>>>>>>>>>>>>>>>>>>>>> between capabilities and requirements.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it
>>>>>>>>>>>>>>>>>>>>>>> can do. It can only computate a mapping based on
>>>>>>>>>>>>>>>>>>>>>>> what it actually can do.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which is
>>>>>>>>>>>>>>>>>>>>>>> to decide on the behavior of what its input would
>>>>>>>>>>>>>>>>>>>>>>> do if given to a UTM.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> embedded_H must only determine whether or not is
>>>>>>>>>>>>>>>>>>>>>> simulated input can ever reach its final state in
>>>>>>>>>>>>>>>>>>>>>> any finite number of steps.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Again, you seem to be lying about working on the
>>>>>>>>>>>>>>>>>>>>> Halting Problem and Linz proof.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If you were working on the Halting Problem and Linz
>>>>>>>>>>>>>>>>>>>>> proof then embedded_H would be identical to H, as
>>>>>>>>>>>>>>>>>>>>> required by Linz, and the correct answer for the
>>>>>>>>>>>>>>>>>>>>> 'behavior' of the input to embedded_H <H^> <H^>
>>>>>>>>>>>>>>>>>>>>> would be the behavior of UTM(<H^>,<H^>) which if
>>>>>>>>>>>>>>>>>>>>> embedded_H goes to H.Qn then we know that H^ will
>>>>>>>>>>>>>>>>>>>>> go to H^.Qn and Halt, and thus H/embedded_H going
>>>>>>>>>>>>>>>>>>>>> to H.Qn is incorrect.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> So, you are just admitting that you are lying or
>>>>>>>>>>>>>>>>>>>>> are too stupid to understan what you are talking
>>>>>>>>>>>>>>>>>>>>> about.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Which is it?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I will not tolerate any digression from the point at
>>>>>>>>>>>>>>>>>>>> hand until we have mutual agreement. This is
>>>>>>>>>>>>>>>>>>>> verified as completely true entirely on the basis of
>>>>>>>>>>>>>>>>>>>> the meaning of its words:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> embedded_H must only determine whether or not its
>>>>>>>>>>>>>>>>>>>> simulated input can
>>>>>>>>>>>>>>>>>>>> ever reach its final state in any finite number of
>>>>>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Translation: You will ignroe any disagreement with
>>>>>>>>>>>>>>>>>>> your incorrect statement because you need to get
>>>>>>>>>>>>>>>>>>> people to accept your falso premise for your unsound
>>>>>>>>>>>>>>>>>>> argument to work.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The problem with your statement is that you are
>>>>>>>>>>>>>>>>>>> showing that you atually mean something different
>>>>>>>>>>>>>>>>>>> than the true meaning of the words.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> H (and thus embedded_H) need to determine whether or
>>>>>>>>>>>>>>>>>>> not its simuleted input will ever reach its final
>>>>>>>>>>>>>>>>>>> state for EVERY POSSIBLE finite number of steps, i.e.
>>>>>>>>>>>>>>>>>>> as determine by a UTM.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ∃N such that the pure simulation of the input to
>>>>>>>>>>>>>>>>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except that it does unless you are lying about H^ being
>>>>>>>>>>>>>>>> built right, at least if H(<H^>,<H^>) -> H.Qn, and it
>>>>>>>>>>>>>>>> doesn't matter what H^ does if H doesn't go to H.Qn, as
>>>>>>>>>>>>>>>> H is then wrong because it didn't answer.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ∃N such that the pure simulation of the input to
>>>>>>>>>>>>>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩
>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ specifies a sequence of configurations
>>>>>>>>>>>>>>> that do not halt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> even if they stop running because the simulation has been
>>>>>>>>>>>>>>> aborted.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I said that incorrectly only the above way of saying it
>>>>>>>>>>>>>>> is accurate, the second way of saying it can be
>>>>>>>>>>>>>>> misinterpreted.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Except the pure simulation of the inputs to H/embeddd_H
>>>>>>>>>>>>>> don't stop when H/embedded_H abrot their simulation
>>>>>>>>>
>>>>>>>>> Only a complete moron would say this.
>>>>>>>>
>>>>>>>> Why do you say that, since it is TRUE?
>>>>>>>>
>>>>>>> You total jackass know that there is only a single pure
>>>>>>> simulation of N steps of the input.
>>>>>>>
>>>>>>
>>>>>> Then what is the computation UTM(<H^>,<H^>) ???
>>>>>>
>>>>>
>>>>> Do I have to put this as a signature line so you don't forget it
>>>>> from one post to the next?
>>>>>
>>>>> We define Linz H to base its halt status decision on the behavior
>>>>> of its pure simulation of N steps of its input. N is either the
>>>>> number of steps that it takes for its simulated input to reach its
>>>>> final state or the number of steps required for H to match an
>>>>> infinite behavior pattern proving that its simulated input would
>>>>> never reach its own final state in any finite number of steps. In
>>>>> this case H aborts the simulation of this input and transitions to
>>>>> H.qn.
>>>>>
>>>>>
>>>>
>>>> You are using your Fairy Dust Powered Unicorns again. There is no
>>>> pattern you can find in a finite numbe N steps that 'proves' that
>>>> H's simulation of <H^> <H^> will never halt when H takes into
>>>> account that the H inside H^ will also use that pattern, BECAUSE any
>>>> pattern that H sees, if it uses that as a pattern it wants to claim
>>>> will do that, then it turns out that with such an H, H^(<H^>) will
>>>> halt.
>>>
>>> The outermost invocation of embedded_H sees the most nested
>>> simulation steps thus is able to abort the inner simulations before
>>> they have seen enough to know that they need to do this.
>>>
>>
>> WRONG.
>>
>> Remember, the definition of Halting is based on running the
>> computation the input represents, (or the UTM simulation of that
>> input), and the outer H/embedded_H CAN'T abort that operation, because
>> it is independent of it.
>>
>
> You just don't understand these things well enough. The outermost
> invocation of nested simulations it an integral aspect of these nested
> simulations.


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 28 Jan 2022 08:39:40 -0600
Date: Fri, 28 Jan 2022 08:39:39 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <mIQIJ.34880$%T.27606@fx06.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
Lines: 372
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-H1YuLNbgUxhJrOPmny3ZGzSUg+E+vH+W6JKOBN9DHVBKDy9PCNXjbIPWrYi2SK0eh8oZRy0mNRN+DjC!qI95iv+jfAJyRHp9LduH4xU4SyJaYclPYhVM6oZ4UhEe6eewveeDVwPlEUOev2M0clyL4JtMowSL
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 21719
 by: olcott - Fri, 28 Jan 2022 14:39 UTC

On 1/28/2022 5:46 AM, Richard Damon wrote:
> On 1/28/22 12:22 AM, olcott wrote:
>> On 1/27/2022 11:06 PM, Richard Damon wrote:
>>> On 1/27/22 11:20 PM, olcott wrote:
>>>> On 1/27/2022 10:11 PM, Richard Damon wrote:
>>>>> On 1/27/22 10:50 PM, olcott wrote:
>>>>>> On 1/27/2022 9:44 PM, Richard Damon wrote:
>>>>>>> On 1/27/22 10:21 PM, olcott wrote:
>>>>>>>> On 1/27/2022 9:00 PM, Richard Damon wrote:
>>>>>>>>> On 1/27/22 9:51 PM, olcott wrote:
>>>>>>>>>> On 1/27/2022 8:23 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/27/22 9:04 PM, olcott wrote:
>>>>>>>>>>>> On 1/27/2022 7:56 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/27/22 7:47 PM, olcott wrote:
>>>>>>>>>>>>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only an infinite simulation of an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite sequence of configurations
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can recognize an infinite sequence of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all) infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution in finite time due to patterns.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> based on an H that at some point goest
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to H.Qn that correctly detects the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite patterns are only really
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite when you work them out to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitity.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> traces you look at are wrong. When H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates H^, it needs to trace out
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the actual execution path of the H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that part of H^, not switch to tracing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what it was tracing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> capacity to understand that when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this is the pattern:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and thus can't give an answer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> point, then the above is NOT the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> accurate trace of the behavior of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BECAUSE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> applies to this case:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitely it is not an accurate simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> abort its simulation, then it needs to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> take into account that the machine it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating will do so too.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As long as H correctly determines that its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated input cannot possibly reach its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state in any finite number of steps
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it has conclusively proved that this input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never halts according to the Linz definition:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its
>>>>>>>>>>>>>>>>>>>>>>>>>>>> input never halts, and for H^, that means
>>>>>>>>>>>>>>>>>>>>>>>>>>>> even if the H insisde H^ goes to H.Qn which
>>>>>>>>>>>>>>>>>>>>>>>>>>>> means that H^ goes to H^.Qn, which of course
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines that
>>>>>>>>>>>>>>>>>>>>>>>>>>> its simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot
>>>>>>>>>>>>>>>>>>>>>>>>>>> possibly reach its final state in any finite
>>>>>>>>>>>>>>>>>>>>>>>>>>> number of steps it terminates this simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>> immediately stopping every element of the
>>>>>>>>>>>>>>>>>>>>>>>>>>> entire chain of nested simulations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> If you are claiming that embedded_H and H
>>>>>>>>>>>>>>>>>>>>>>>>>> behave differently then you have been lying
>>>>>>>>>>>>>>>>>>>>>>>>>> that you built H^ by the instruction of Linz,
>>>>>>>>>>>>>>>>>>>>>>>>>> as the copy of H inside H^ is IDENTICAL
>>>>>>>>>>>>>>>>>>>>>>>>>> (except what happens AFTER getting to H.Qy)
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Now, IF H could make that proof, then it would
>>>>>>>>>>>>>>>>>>>>>>>>>> be correct to go to H.Qn, but it would need to
>>>>>>>>>>>>>>>>>>>>>>>>>> take into account that H^ halts if its copy of
>>>>>>>>>>>>>>>>>>>>>>>>>> H goes to H.Qn, so this is NEVER possible.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which
>>>>>>>>>>>>>>>>>>>>>>>>>>> causes the original Ĥ applied to ⟨Ĥ⟩ to halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Since Ĥ applied to ⟨Ĥ⟩ is not an input to
>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H and a decider is only accountable
>>>>>>>>>>>>>>>>>>>>>>>>>>> for computing the mapping from its actual
>>>>>>>>>>>>>>>>>>>>>>>>>>> inputs to an accept or reject state it makes
>>>>>>>>>>>>>>>>>>>>>>>>>>> no difference that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thus you have admitted to LYING about working
>>>>>>>>>>>>>>>>>>>>>>>>>> on the Halting problem as if you were the
>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H would be the same algorithm as H,
>>>>>>>>>>>>>>>>>>>>>>>>>> and the requirement on H was that is IS
>>>>>>>>>>>>>>>>>>>>>>>>>> accoutable for the machine its input represents,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> You are simply too freaking stupid to
>>>>>>>>>>>>>>>>>>>>>>>>> understand that deciders thus halt deciders are
>>>>>>>>>>>>>>>>>>>>>>>>> only accountable for computing the mapping from
>>>>>>>>>>>>>>>>>>>>>>>>> their actual inputs (nothing else in the whole
>>>>>>>>>>>>>>>>>>>>>>>>> freaking universe besides their actual inputs)
>>>>>>>>>>>>>>>>>>>>>>>>> to an accept or reject state.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It seems you don't understand the difference
>>>>>>>>>>>>>>>>>>>>>>>> between capabilities and requirements.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it
>>>>>>>>>>>>>>>>>>>>>>>> can do. It can only computate a mapping based on
>>>>>>>>>>>>>>>>>>>>>>>> what it actually can do.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which
>>>>>>>>>>>>>>>>>>>>>>>> is to decide on the behavior of what its input
>>>>>>>>>>>>>>>>>>>>>>>> would do if given to a UTM.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> embedded_H must only determine whether or not is
>>>>>>>>>>>>>>>>>>>>>>> simulated input can ever reach its final state in
>>>>>>>>>>>>>>>>>>>>>>> any finite number of steps.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Again, you seem to be lying about working on the
>>>>>>>>>>>>>>>>>>>>>> Halting Problem and Linz proof.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If you were working on the Halting Problem and
>>>>>>>>>>>>>>>>>>>>>> Linz proof then embedded_H would be identical to
>>>>>>>>>>>>>>>>>>>>>> H, as required by Linz, and the correct answer for
>>>>>>>>>>>>>>>>>>>>>> the 'behavior' of the input to embedded_H <H^>
>>>>>>>>>>>>>>>>>>>>>> <H^> would be the behavior of UTM(<H^>,<H^>) which
>>>>>>>>>>>>>>>>>>>>>> if embedded_H goes to H.Qn then we know that H^
>>>>>>>>>>>>>>>>>>>>>> will go to H^.Qn and Halt, and thus H/embedded_H
>>>>>>>>>>>>>>>>>>>>>> going to H.Qn is incorrect.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So, you are just admitting that you are lying or
>>>>>>>>>>>>>>>>>>>>>> are too stupid to understan what you are talking
>>>>>>>>>>>>>>>>>>>>>> about.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Which is it?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I will not tolerate any digression from the point
>>>>>>>>>>>>>>>>>>>>> at hand until we have mutual agreement. This is
>>>>>>>>>>>>>>>>>>>>> verified as completely true entirely on the basis
>>>>>>>>>>>>>>>>>>>>> of the meaning of its words:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> embedded_H must only determine whether or not its
>>>>>>>>>>>>>>>>>>>>> simulated input can
>>>>>>>>>>>>>>>>>>>>> ever reach its final state in any finite number of
>>>>>>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Translation: You will ignroe any disagreement with
>>>>>>>>>>>>>>>>>>>> your incorrect statement because you need to get
>>>>>>>>>>>>>>>>>>>> people to accept your falso premise for your unsound
>>>>>>>>>>>>>>>>>>>> argument to work.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The problem with your statement is that you are
>>>>>>>>>>>>>>>>>>>> showing that you atually mean something different
>>>>>>>>>>>>>>>>>>>> than the true meaning of the words.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H (and thus embedded_H) need to determine whether or
>>>>>>>>>>>>>>>>>>>> not its simuleted input will ever reach its final
>>>>>>>>>>>>>>>>>>>> state for EVERY POSSIBLE finite number of steps,
>>>>>>>>>>>>>>>>>>>> i.e. as determine by a UTM.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ∃N such that the pure simulation of the input to
>>>>>>>>>>>>>>>>>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Except that it does unless you are lying about H^ being
>>>>>>>>>>>>>>>>> built right, at least if H(<H^>,<H^>) -> H.Qn, and it
>>>>>>>>>>>>>>>>> doesn't matter what H^ does if H doesn't go to H.Qn, as
>>>>>>>>>>>>>>>>> H is then wrong because it didn't answer.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ∃N such that the pure simulation of the input to
>>>>>>>>>>>>>>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩
>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ specifies a sequence of configurations
>>>>>>>>>>>>>>>> that do not halt
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> even if they stop running because the simulation has
>>>>>>>>>>>>>>>> been aborted.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I said that incorrectly only the above way of saying it
>>>>>>>>>>>>>>>> is accurate, the second way of saying it can be
>>>>>>>>>>>>>>>> misinterpreted.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Except the pure simulation of the inputs to H/embeddd_H
>>>>>>>>>>>>>>> don't stop when H/embedded_H abrot their simulation
>>>>>>>>>>
>>>>>>>>>> Only a complete moron would say this.
>>>>>>>>>
>>>>>>>>> Why do you say that, since it is TRUE?
>>>>>>>>>
>>>>>>>> You total jackass know that there is only a single pure
>>>>>>>> simulation of N steps of the input.
>>>>>>>>
>>>>>>>
>>>>>>> Then what is the computation UTM(<H^>,<H^>) ???
>>>>>>>
>>>>>>
>>>>>> Do I have to put this as a signature line so you don't forget it
>>>>>> from one post to the next?
>>>>>>
>>>>>> We define Linz H to base its halt status decision on the behavior
>>>>>> of its pure simulation of N steps of its input. N is either the
>>>>>> number of steps that it takes for its simulated input to reach its
>>>>>> final state or the number of steps required for H to match an
>>>>>> infinite behavior pattern proving that its simulated input would
>>>>>> never reach its own final state in any finite number of steps. In
>>>>>> this case H aborts the simulation of this input and transitions to
>>>>>> H.qn.
>>>>>>
>>>>>>
>>>>>
>>>>> You are using your Fairy Dust Powered Unicorns again. There is no
>>>>> pattern you can find in a finite numbe N steps that 'proves' that
>>>>> H's simulation of <H^> <H^> will never halt when H takes into
>>>>> account that the H inside H^ will also use that pattern, BECAUSE
>>>>> any pattern that H sees, if it uses that as a pattern it wants to
>>>>> claim will do that, then it turns out that with such an H, H^(<H^>)
>>>>> will halt.
>>>>
>>>> The outermost invocation of embedded_H sees the most nested
>>>> simulation steps thus is able to abort the inner simulations before
>>>> they have seen enough to know that they need to do this.
>>>>
>>>
>>> WRONG.
>>>
>>> Remember, the definition of Halting is based on running the
>>> computation the input represents, (or the UTM simulation of that
>>> input), and the outer H/embedded_H CAN'T abort that operation,
>>> because it is independent of it.
>>>
>>
>> You just don't understand these things well enough. The outermost
>> invocation of nested simulations it an integral aspect of these nested
>> simulations.
>
> And you don't understand that the problem is about the natural behavior
> of the independent machine H^, and nothing CAN 'abort' that.
>


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<Ol0JJ.27499$541.4855@fx35.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx35.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
<ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 390
Message-ID: <Ol0JJ.27499$541.4855@fx35.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: Fri, 28 Jan 2022 20:01:34 -0500
X-Received-Bytes: 22460
 by: Richard Damon - Sat, 29 Jan 2022 01:01 UTC

On 1/28/22 9:39 AM, olcott wrote:
> On 1/28/2022 5:46 AM, Richard Damon wrote:
>> On 1/28/22 12:22 AM, olcott wrote:
>>> On 1/27/2022 11:06 PM, Richard Damon wrote:
>>>> On 1/27/22 11:20 PM, olcott wrote:
>>>>> On 1/27/2022 10:11 PM, Richard Damon wrote:
>>>>>> On 1/27/22 10:50 PM, olcott wrote:
>>>>>>> On 1/27/2022 9:44 PM, Richard Damon wrote:
>>>>>>>> On 1/27/22 10:21 PM, olcott wrote:
>>>>>>>>> On 1/27/2022 9:00 PM, Richard Damon wrote:
>>>>>>>>>> On 1/27/22 9:51 PM, olcott wrote:
>>>>>>>>>>> On 1/27/2022 8:23 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/27/22 9:04 PM, olcott wrote:
>>>>>>>>>>>>> On 1/27/2022 7:56 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/27/22 7:47 PM, olcott wrote:
>>>>>>>>>>>>>>> On 1/27/2022 6:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/27/22 7:14 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/27/2022 5:53 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/27/22 10:34 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/27/2022 9:25 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 1/27/2022 5:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/26/22 11:37 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 10:59 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:42 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You keep coming back to the idea
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that only an infinite simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an infinite sequence of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations can recognize an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite sequence of configurations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can detect SOME (not all)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite execution in finite time due
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to patterns.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is no finite pattern in the H^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> based on an H that at some point
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> goest to H.Qn that correctly detects
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the infinite behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THAT is the point you miss, SOME
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite patterns are only really
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite when you work them out to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitity.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Part of your problem is that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> traces you look at are wrong. When H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates H^, it needs to trace out
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the actual execution path of the H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that part of H^, not switch to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tracing what it was tracing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You simply lack the intellectual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> capacity to understand that when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ applied to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ this is the pattern:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which only happens if H NEVER aborts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation and thus can't give an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> answer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H DOES abort its simulation at ANY
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> point, then the above is NOT the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> accurate trace of the behavior of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BECAUSE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 00000d9d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You exactly same jackass point equally
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> applies to this case:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless H simulates the infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitely it is not an accurate
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The key point you miss is that if H does
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> abort its simulation, then it needs to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> take into account that the machine it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating will do so too.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As long as H correctly determines that its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated input cannot possibly reach its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state in any finite number of steps
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it has conclusively proved that this input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never halts according to the Linz definition:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But it needs to prove that the UTM of its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input never halts, and for H^, that means
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> even if the H insisde H^ goes to H.Qn which
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> means that H^ goes to H^.Qn, which of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> course Halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> As soon as embedded_H (not H) determines
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach its final state in any
>>>>>>>>>>>>>>>>>>>>>>>>>>>> finite number of steps it terminates this
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation immediately stopping every
>>>>>>>>>>>>>>>>>>>>>>>>>>>> element of the entire chain of nested
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> If you are claiming that embedded_H and H
>>>>>>>>>>>>>>>>>>>>>>>>>>> behave differently then you have been lying
>>>>>>>>>>>>>>>>>>>>>>>>>>> that you built H^ by the instruction of Linz,
>>>>>>>>>>>>>>>>>>>>>>>>>>> as the copy of H inside H^ is IDENTICAL
>>>>>>>>>>>>>>>>>>>>>>>>>>> (except what happens AFTER getting to H.Qy)
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Now, IF H could make that proof, then it
>>>>>>>>>>>>>>>>>>>>>>>>>>> would be correct to go to H.Qn, but it would
>>>>>>>>>>>>>>>>>>>>>>>>>>> need to take into account that H^ halts if
>>>>>>>>>>>>>>>>>>>>>>>>>>> its copy of H goes to H.Qn, so this is NEVER
>>>>>>>>>>>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> FAIL
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Then embedded_H transitions to Ĥ.qn which
>>>>>>>>>>>>>>>>>>>>>>>>>>>> causes the original Ĥ applied to ⟨Ĥ⟩ to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt. Since Ĥ applied to ⟨Ĥ⟩ is not an input
>>>>>>>>>>>>>>>>>>>>>>>>>>>> to embedded_H and a decider is only
>>>>>>>>>>>>>>>>>>>>>>>>>>>> accountable for computing the mapping from
>>>>>>>>>>>>>>>>>>>>>>>>>>>> its actual inputs to an accept or reject
>>>>>>>>>>>>>>>>>>>>>>>>>>>> state it makes no difference that Ĥ applied
>>>>>>>>>>>>>>>>>>>>>>>>>>>> to ⟨Ĥ⟩ halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Thus you have admitted to LYING about working
>>>>>>>>>>>>>>>>>>>>>>>>>>> on the Halting problem as if you were the
>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H would be the same algorithm as H,
>>>>>>>>>>>>>>>>>>>>>>>>>>> and the requirement on H was that is IS
>>>>>>>>>>>>>>>>>>>>>>>>>>> accoutable for the machine its input represents,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> You are simply too freaking stupid to
>>>>>>>>>>>>>>>>>>>>>>>>>> understand that deciders thus halt deciders
>>>>>>>>>>>>>>>>>>>>>>>>>> are only accountable for computing the mapping
>>>>>>>>>>>>>>>>>>>>>>>>>> from their actual inputs (nothing else in the
>>>>>>>>>>>>>>>>>>>>>>>>>> whole freaking universe besides their actual
>>>>>>>>>>>>>>>>>>>>>>>>>> inputs) to an accept or reject state.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> An actual computer scientist would know this.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> It seems you don't understand the difference
>>>>>>>>>>>>>>>>>>>>>>>>> between capabilities and requirements.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> H is only CAPABLE of deciding based on what it
>>>>>>>>>>>>>>>>>>>>>>>>> can do. It can only computate a mapping based
>>>>>>>>>>>>>>>>>>>>>>>>> on what it actually can do.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> It is REQUIRED to meet its requirements, which
>>>>>>>>>>>>>>>>>>>>>>>>> is to decide on the behavior of what its input
>>>>>>>>>>>>>>>>>>>>>>>>> would do if given to a UTM.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> embedded_H must only determine whether or not is
>>>>>>>>>>>>>>>>>>>>>>>> simulated input can ever reach its final state
>>>>>>>>>>>>>>>>>>>>>>>> in any finite number of steps.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Again, you seem to be lying about working on the
>>>>>>>>>>>>>>>>>>>>>>> Halting Problem and Linz proof.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If you were working on the Halting Problem and
>>>>>>>>>>>>>>>>>>>>>>> Linz proof then embedded_H would be identical to
>>>>>>>>>>>>>>>>>>>>>>> H, as required by Linz, and the correct answer
>>>>>>>>>>>>>>>>>>>>>>> for the 'behavior' of the input to embedded_H
>>>>>>>>>>>>>>>>>>>>>>> <H^> <H^> would be the behavior of UTM(<H^>,<H^>)
>>>>>>>>>>>>>>>>>>>>>>> which if embedded_H goes to H.Qn then we know
>>>>>>>>>>>>>>>>>>>>>>> that H^ will go to H^.Qn and Halt, and thus
>>>>>>>>>>>>>>>>>>>>>>> H/embedded_H going to H.Qn is incorrect.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> So, you are just admitting that you are lying or
>>>>>>>>>>>>>>>>>>>>>>> are too stupid to understan what you are talking
>>>>>>>>>>>>>>>>>>>>>>> about.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Which is it?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I will not tolerate any digression from the point
>>>>>>>>>>>>>>>>>>>>>> at hand until we have mutual agreement. This is
>>>>>>>>>>>>>>>>>>>>>> verified as completely true entirely on the basis
>>>>>>>>>>>>>>>>>>>>>> of the meaning of its words:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> embedded_H must only determine whether or not its
>>>>>>>>>>>>>>>>>>>>>> simulated input can
>>>>>>>>>>>>>>>>>>>>>> ever reach its final state in any finite number of
>>>>>>>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Translation: You will ignroe any disagreement with
>>>>>>>>>>>>>>>>>>>>> your incorrect statement because you need to get
>>>>>>>>>>>>>>>>>>>>> people to accept your falso premise for your
>>>>>>>>>>>>>>>>>>>>> unsound argument to work.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The problem with your statement is that you are
>>>>>>>>>>>>>>>>>>>>> showing that you atually mean something different
>>>>>>>>>>>>>>>>>>>>> than the true meaning of the words.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> H (and thus embedded_H) need to determine whether
>>>>>>>>>>>>>>>>>>>>> or not its simuleted input will ever reach its
>>>>>>>>>>>>>>>>>>>>> final state for EVERY POSSIBLE finite number of
>>>>>>>>>>>>>>>>>>>>> steps, i.e. as determine by a UTM.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ∃N such that the pure simulation of the input to
>>>>>>>>>>>>>>>>>>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Except that it does unless you are lying about H^
>>>>>>>>>>>>>>>>>> being built right, at least if H(<H^>,<H^>) -> H.Qn,
>>>>>>>>>>>>>>>>>> and it doesn't matter what H^ does if H doesn't go to
>>>>>>>>>>>>>>>>>> H.Qn, as H is then wrong because it didn't answer.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ∃N such that the pure simulation of the input to
>>>>>>>>>>>>>>>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>>>> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps, otherwise ⟨Ĥ⟩
>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ specifies a sequence of configurations
>>>>>>>>>>>>>>>>> that do not halt
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> even if they stop running because the simulation has
>>>>>>>>>>>>>>>>> been aborted.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I said that incorrectly only the above way of saying it
>>>>>>>>>>>>>>>>> is accurate, the second way of saying it can be
>>>>>>>>>>>>>>>>> misinterpreted.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except the pure simulation of the inputs to H/embeddd_H
>>>>>>>>>>>>>>>> don't stop when H/embedded_H abrot their simulation
>>>>>>>>>>>
>>>>>>>>>>> Only a complete moron would say this.
>>>>>>>>>>
>>>>>>>>>> Why do you say that, since it is TRUE?
>>>>>>>>>>
>>>>>>>>> You total jackass know that there is only a single pure
>>>>>>>>> simulation of N steps of the input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Then what is the computation UTM(<H^>,<H^>) ???
>>>>>>>>
>>>>>>>
>>>>>>> Do I have to put this as a signature line so you don't forget it
>>>>>>> from one post to the next?
>>>>>>>
>>>>>>> We define Linz H to base its halt status decision on the behavior
>>>>>>> of its pure simulation of N steps of its input. N is either the
>>>>>>> number of steps that it takes for its simulated input to reach
>>>>>>> its final state or the number of steps required for H to match an
>>>>>>> infinite behavior pattern proving that its simulated input would
>>>>>>> never reach its own final state in any finite number of steps. In
>>>>>>> this case H aborts the simulation of this input and transitions
>>>>>>> to H.qn.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> You are using your Fairy Dust Powered Unicorns again. There is no
>>>>>> pattern you can find in a finite numbe N steps that 'proves' that
>>>>>> H's simulation of <H^> <H^> will never halt when H takes into
>>>>>> account that the H inside H^ will also use that pattern, BECAUSE
>>>>>> any pattern that H sees, if it uses that as a pattern it wants to
>>>>>> claim will do that, then it turns out that with such an H,
>>>>>> H^(<H^>) will halt.
>>>>>
>>>>> The outermost invocation of embedded_H sees the most nested
>>>>> simulation steps thus is able to abort the inner simulations before
>>>>> they have seen enough to know that they need to do this.
>>>>>
>>>>
>>>> WRONG.
>>>>
>>>> Remember, the definition of Halting is based on running the
>>>> computation the input represents, (or the UTM simulation of that
>>>> input), and the outer H/embedded_H CAN'T abort that operation,
>>>> because it is independent of it.
>>>>
>>>
>>> You just don't understand these things well enough. The outermost
>>> invocation of nested simulations it an integral aspect of these
>>> nested simulations.
>>
>> And you don't understand that the problem is about the natural
>> behavior of the independent machine H^, and nothing CAN 'abort' that.
>>
>
> Because the halt decider must be a decider you are wrong.
>
>> WITHIN H^ is a copy of H thatyou are describing as aborting its
>> simulation of H^, and if that H goes to H.Qn, then H^ will halt
>> showing that H was wrong, and if it doesn't, then NO copy of H will,
>> so H fails by not answering.
>>
>
> A halt decider is a decider thus only accountable for actual behavior of
> its actual inputs. We aren't getting anywhere with this so I give up on
> you.


Click here to read the complete article
Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<875yq2h2ea.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]
Date: Sat, 29 Jan 2022 17:34:21 +0000
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <875yq2h2ea.fsf@bsb.me.uk>
References: <ssh8vu$4c0$1@dont-email.me> <ssue1i$81l$1@dont-email.me>
<AfGIJ.3844$dV.1984@fx44.iad>
<sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com>
<dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad>
<n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="00be0330ed62b735868e93f7a4aba188";
logging-data="28942"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+PFVN6ErHiOhAbUg02KLooZQ7sxmsmzkk="
Cancel-Lock: sha1:AKFqn/JvgYPd4EyJqLn9Gw++etE=
sha1:TfCCxAhXLO5PIaKPzXyk076LHoo=
X-BSB-Auth: 1.50307aeb5ab4035ce722.20220129173421GMT.875yq2h2ea.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 29 Jan 2022 17:34 UTC

Richard Damon <Richard@Damon-Family.org> writes:

> And the 'actual behavior of its actual inputs' is DEFINED to be what
> the computation the input actually does when run as an independent
> machine, or what a UTM will do when simulating that input.
>
> If that isn't the meaning you are using, then you are just lying that
> you are working on the halting problem, which is what seems to be the
> case. (That you are lying that is).

It is certainly true that PO is not addressing the halting problem. He
has been 100% clear that false is, in his "opinion", the correct result
for at least one halting computation. This is not in dispute (unless
he's retracted that and I missed it).

To you and I, this means that he's not working on the halting problem,
but I am not sure you can say he is lying about that. For one thing,
how can he be intending to deceive (a core part of lying) when he's been
clear the he accepts the wrong answer as being the right one? If
someone claims to be working on "the addition problem", and also claims
that 2+2=5 is correct, it's hard to consider either claim to be a lie.
The person is just deeply confused.

But what sort of confused can explain this nonsense? I think the answer
lies in PO's background. The "binary square root" function is not
computable as far as a mathematician is concerned because no TM can halt
with, say, sqrt(0b10) on the tape. But to an engineer, the function
poses no problem because we can get as close as we like. If
0b1.01101010000 is not good enough, just add more digits.

The point is I think PO does not know what a formal, mathematical
problem really is. To him, anything about code, machines or programs is
about solving an engineering problem "well enough" -- with "well enough"
open to be defined by PO himself.

More disturbing to me is that he is not even talking about Turing
machines, again as evidenced by his own plain words. It is not in
dispute that he claims that two (deterministic) TMs, one an identical
copy of the other, can transition to different states despite both being
presented with identical input. These are not Turing machines but Magic
machines, and I can't see how any discussion can be had while the action
of the things being considered is not a simple function of the input and
the state transition graph.

This is why I stopped replying. While there are things to say about
PO's Other Halting problem (principally that even the POOH problem can't
be solved), I had nothing more to say while the "machines" being
discussed are magic.

--
Ben.

Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<st3vrv$hnh$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Followup-To: comp.theory
Date: Sat, 29 Jan 2022 12:09:01 -0600
Organization: A noiseless patient Spider
Lines: 83
Message-ID: <st3vrv$hnh$1@dont-email.me>
References: <ssh8vu$4c0$1@dont-email.me> <ssue1i$81l$1@dont-email.me>
<AfGIJ.3844$dV.1984@fx44.iad> <sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 29 Jan 2022 18:09:03 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="119090c1a975c238d4973f53c8b6cad8";
logging-data="18161"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+WlvoZL9V18be7WhHuFbSA"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Cancel-Lock: sha1:lSZyzSD4lDQo+ze3ZX795hbcmvc=
In-Reply-To: <875yq2h2ea.fsf@bsb.me.uk>
Content-Language: en-US
 by: olcott - Sat, 29 Jan 2022 18:09 UTC

On 1/29/2022 11:34 AM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> And the 'actual behavior of its actual inputs' is DEFINED to be what
>> the computation the input actually does when run as an independent
>> machine, or what a UTM will do when simulating that input.
>>
>> If that isn't the meaning you are using, then you are just lying that
>> you are working on the halting problem, which is what seems to be the
>> case. (That you are lying that is).
>
> It is certainly true that PO is not addressing the halting problem. He
> has been 100% clear that false is, in his "opinion", the correct result
> for at least one halting computation. This is not in dispute (unless
> he's retracted that and I missed it).
>

The following simplifies the syntax for the definition of the Linz
Turing machine Ĥ, it is now a single machine with a single start state.
A copy of Linz H is embedded at Ĥ.qx.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

There are no finite number of steps of the pure simulation of ⟨Ĥ⟩
applied to ⟨Ĥ⟩ by embedded_H such that this simulated input meets the
Linz definition of halting:

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

Therefore it is correct to say that the input to embedded_H specifies a
sequence of configurations that never halts.

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

> To you and I, this means that he's not working on the halting problem,
> but I am not sure you can say he is lying about that. For one thing,
> how can he be intending to deceive (a core part of lying) when he's been
> clear the he accepts the wrong answer as being the right one? If
> someone claims to be working on "the addition problem", and also claims
> that 2+2=5 is correct, it's hard to consider either claim to be a lie.
> The person is just deeply confused.
>
> But what sort of confused can explain this nonsense? I think the answer
> lies in PO's background. The "binary square root" function is not
> computable as far as a mathematician is concerned because no TM can halt
> with, say, sqrt(0b10) on the tape. But to an engineer, the function
> poses no problem because we can get as close as we like. If
> 0b1.01101010000 is not good enough, just add more digits.
>
> The point is I think PO does not know what a formal, mathematical
> problem really is. To him, anything about code, machines or programs is
> about solving an engineering problem "well enough" -- with "well enough"
> open to be defined by PO himself.
>
> More disturbing to me is that he is not even talking about Turing
> machines, again as evidenced by his own plain words. It is not in
> dispute that he claims that two (deterministic) TMs, one an identical
> copy of the other, can transition to different states despite both being
> presented with identical input. These are not Turing machines but Magic
> machines, and I can't see how any discussion can be had while the action
> of the things being considered is not a simple function of the input and
> the state transition graph.
>

H and embedded_H are not identical, one has an infinite loop appended to
its accept state.

I will not tolerate digression into this side issue until after mutual
agreement is achieved on the first point. Until then these side issues
are no more than a dishonest dodge distraction away from the main point.

> This is why I stopped replying. While there are things to say about
> PO's Other Halting problem (principally that even the POOH problem can't
> be solved), I had nothing more to say while the "machines" being
> discussed are magic.
>

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

Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<BSfJJ.316644$qz4.139183@fx97.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx97.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me> <ssue1i$81l$1@dont-email.me>
<AfGIJ.3844$dV.1984@fx44.iad> <sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk>
<st3vrv$hnh$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <st3vrv$hnh$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 148
Message-ID: <BSfJJ.316644$qz4.139183@fx97.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, 29 Jan 2022 13:40:33 -0500
X-Received-Bytes: 8419
 by: Richard Damon - Sat, 29 Jan 2022 18:40 UTC

On 1/29/22 1:09 PM, olcott wrote:
> On 1/29/2022 11:34 AM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> And the 'actual behavior of its actual inputs' is DEFINED to be what
>>> the computation the input actually does when run as an independent
>>> machine, or what a UTM will do when simulating that input.
>>>
>>> If that isn't the meaning you are using, then you are just lying that
>>> you are working on the halting problem, which is what seems to be the
>>> case. (That you are lying that is).
>>
>> It is certainly true that PO is not addressing the halting problem.  He
>> has been 100% clear that false is, in his "opinion", the correct result
>> for at least one halting computation.  This is not in dispute (unless
>> he's retracted that and I missed it).
>>
>
> The following simplifies the syntax for the definition of the Linz
> Turing machine Ĥ, it is now a single machine with a single start state.
> A copy of Linz H is embedded at Ĥ.qx.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Which is soewhat incorrect as it doesn't explain HOW H^ chooses which path.

It is thus an INCOMPLETE description of the machine H^.

>
> There are no finite number of steps of the pure simulation of ⟨Ĥ⟩
> applied to ⟨Ĥ⟩ by embedded_H such that this simulated input meets the
> Linz definition of halting:

Except that there IS if H <H^> <H^> -> H.Qn, the value of N (lets call
it M) in this case is just bigger than the different 'N' that you
describe for a given embedded_H.

If embedded_H goes to H.Qn in N steps, then there exists another number
M, greater than N, which UTM(<H^>,<H^>) will reach a final state, thus
we show that H^ <H^> does Halt.

>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)

Note, Linz definition doesn't talk about by a simulator that might
abort, but what happens when you actually run the Turing Machine, which
mean the machine with either Halt in some finite number of steps, or run
for an infinite number of steps.

>
> Therefore it is correct to say that the input to embedded_H specifies a
> sequence of configurations that never halts.

No it isn't, because there is NO single 'embedded_H' that can simulate
for all arbitrary values of N, except the one that never aborts, and for
that one, while H^ becomes non-halting, so does H so it fails to be a
decider.

Since changing embedded_H changes the input, you can't argue of changing
versions of embedded_H, not if you are following the rules of Compution
Theory and the Halting Problem.

FAIL

>
> https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3
>
>
>> To you and I, this means that he's not working on the halting problem,
>> but I am not sure you can say he is lying about that.  For one thing,
>> how can he be intending to deceive (a core part of lying) when he's been
>> clear the he accepts the wrong answer as being the right one?  If
>> someone claims to be working on "the addition problem", and also claims
>> that 2+2=5 is correct, it's hard to consider either claim to be a lie.
>> The person is just deeply confused.
>>
>> But what sort of confused can explain this nonsense?  I think the answer
>> lies in PO's background.  The "binary square root" function is not
>> computable as far as a mathematician is concerned because no TM can halt
>> with, say, sqrt(0b10) on the tape.  But to an engineer, the function
>> poses no problem because we can get as close as we like.  If
>> 0b1.01101010000 is not good enough, just add more digits.
>>
>> The point is I think PO does not know what a formal, mathematical
>> problem really is.  To him, anything about code, machines or programs is
>> about solving an engineering problem "well enough" -- with "well enough"
>> open to be defined by PO himself.
>>
>> More disturbing to me is that he is not even talking about Turing
>> machines, again as evidenced by his own plain words.  It is not in
>> dispute that he claims that two (deterministic) TMs, one an identical
>> copy of the other, can transition to different states despite both being
>> presented with identical input.  These are not Turing machines but Magic
>> machines, and I can't see how any discussion can be had while the action
>> of the things being considered is not a simple function of the input and
>> the state transition graph.
>>
>
> H and embedded_H are not identical, one has an infinite loop appended to
> its accept state.

That is OUTSIDE the copy of H in H^. That just says that H and H^ aren't
the same machine, but that was never claimed.

H^.qx to H^.qn/H^.qy is the identical algorithm as H.q0 to H.qn/H.qy so
thse section MUST behave the same, and what that section of code does
can not be influenced by what code outside that section does.

That is a fundamental property of Turing Macines, and in fact is a core
princple of computer science that you can partition algorithms into
independent non-interfering chunks. This allows you to simplify your
analysis.

Note also, the change outside H in H^ is on the H.qy branch, which we
aren't even using in your argument, so any change of behavior there is
irrelevant.

>
> I will not tolerate digression into this side issue until after mutual
> agreement is achieved on the first point. Until then these side issues
> are no more than a dishonest dodge distraction away from the main point.

Then you have a long wait, as you are basically making a childish
insistance that people agree to your lies.

The copy of H within H^, from H^.qx to H^.qn must be IDENTICAL to the
algorithm of H from H.q0 to H.qn, and if given the same input (as we
have here) if H goes from H.q0 to H.qn in k steps, then H^ MUST also go
from H^.qx to H^.qn in exactly that same k steps.

This means that if H <H^> <H^> -> H.Qn in k steps then H^ <H^> will go
to H^.qx <H^> <H^> in some fininte number of steps, and then to H^.qn
and halt in k more steps, thus H^ <H^> WILL Halt if H <H^> <H^> -> H.qn,
so H is NOT a correct halt decider for that case. PERIOD.

FAIL.

>
>> This is why I stopped replying.  While there are things to say about
>> PO's Other Halting problem (principally that even the POOH problem can't
>> be solved), I had nothing more to say while the "machines" being
>> discussed are magic.
>>
>
>

Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<st41us$bg4$2@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!42V55DPF/EHESwy7gmIc+w.user.46.165.242.75.POSTED!not-for-mail
From: gettabr...@gmail.net (Greta Baine)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Date: Sat, 29 Jan 2022 10:44:41 -0800
Organization: Aioe.org NNTP Server
Message-ID: <st41us$bg4$2@gioia.aioe.org>
References: <ssh8vu$4c0$1@dont-email.me> <ssue1i$81l$1@dont-email.me>
<AfGIJ.3844$dV.1984@fx44.iad> <sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk>
<st3vrv$hnh$1@dont-email.me>
Reply-To: gettabrane@gmail.net
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="11780"; posting-host="42V55DPF/EHESwy7gmIc+w.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.9.2
 by: Greta Baine - Sat, 29 Jan 2022 18:44 UTC

On 1/29/2022 10:09 AM, olcott wrote:
> *-> nothing <- *

Get a brain you incomprehensible mega-tard.

Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<YYWdnTmmToZ1DWj8nZ2dnUU7-amdnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: sci.math comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 29 Jan 2022 13:09:28 -0600
Date: Sat, 29 Jan 2022 13:09:27 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: sci.math,comp.theory
References: <ssh8vu$4c0$1@dont-email.me> <ssue1i$81l$1@dont-email.me>
<AfGIJ.3844$dV.1984@fx44.iad> <sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk>
<st3vrv$hnh$1@dont-email.me> <st4208$bg4$3@gioia.aioe.org>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <st4208$bg4$3@gioia.aioe.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <YYWdnTmmToZ1DWj8nZ2dnUU7-amdnZ2d@giganews.com>
Lines: 17
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-o3Wi+VBm+2OZufs9ea6WrggRpR3n4SQH38GvJxm/ZDowC4qKvaCEQRrZdnUl+wlA1mra7p1UdUMSnRz!O8pE4d87hgDgoiKBiMJCw0NTQANF91jyxiXbi1mc0luvHcXQnDdLSxDKs1fvwVDDxu0MFTVhgulX
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2560
 by: olcott - Sat, 29 Jan 2022 19:09 UTC

On 1/29/2022 12:45 PM, Greta Baine wrote:
> On 1/29/2022 10:09 AM, olcott wrote:
>
> (nothing)
>
> Get a brain you impotent blithering twatwaffle,

This is merely another way of saying the you know that you are totally
incompetent to point out even a single error in anything that I have said.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]

<klgJJ.23485$jb1.13424@fx46.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx46.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me> <ssue1i$81l$1@dont-email.me>
<AfGIJ.3844$dV.1984@fx44.iad> <sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk>
<st3vrv$hnh$1@dont-email.me> <st4208$bg4$3@gioia.aioe.org>
<YYWdnTmmToZ1DWj8nZ2dnUU7-amdnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <YYWdnTmmToZ1DWj8nZ2dnUU7-amdnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 14
Message-ID: <klgJJ.23485$jb1.13424@fx46.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, 29 Jan 2022 14:13:21 -0500
X-Received-Bytes: 2255
 by: Richard Damon - Sat, 29 Jan 2022 19:13 UTC

On 1/29/22 2:09 PM, olcott wrote:
> On 1/29/2022 12:45 PM, Greta Baine wrote:
>> On 1/29/2022 10:09 AM, olcott wrote:
>>
>> (nothing)
>>
>> Get a brain you impotent blithering twatwaffle,
>
> This is merely another way of saying the you know that you are totally
> incompetent to point out even a single error in anything that I have said.
>
>

Pot, Kettle, Black.

Re: Concise refutation of halting problem proofs V52 [ THE KEY QUESTION ]

<iqGdnZERkLUpPmj8nZ2dnUU7-QnNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.logic
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 29 Jan 2022 14:29:40 -0600
Date: Sat, 29 Jan 2022 14:29:39 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ THE KEY
QUESTION ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.logic
References: <ssh8vu$4c0$1@dont-email.me> <ssue1i$81l$1@dont-email.me>
<AfGIJ.3844$dV.1984@fx44.iad> <sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <875yq2h2ea.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <iqGdnZERkLUpPmj8nZ2dnUU7-QnNnZ2d@giganews.com>
Lines: 96
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-PKgJKs9fF0uO3KfJg6PdonhWel4aYGRC5/coGSQ1fFtyQ926HMOdvVAlPWDK0ynAb9bkyZemNN2xj85!X39UpbrHuAPF/j2EoiLOISRIAU63SsVqbV0cEJ518tV8XCbh9TrQKkkDx2I5tVADWG+kb0AtiuMr
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6376
 by: olcott - Sat, 29 Jan 2022 20:29 UTC

On 1/29/2022 11:34 AM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> And the 'actual behavior of its actual inputs' is DEFINED to be what
>> the computation the input actually does when run as an independent
>> machine, or what a UTM will do when simulating that input.
>>
>> If that isn't the meaning you are using, then you are just lying that
>> you are working on the halting problem, which is what seems to be the
>> case. (That you are lying that is).
>
> It is certainly true that PO is not addressing the halting problem. He
> has been 100% clear that false is, in his "opinion", the correct result
> for at least one halting computation. This is not in dispute (unless
> he's retracted that and I missed it).
>

THIS POINT ADDRESSES THE KEY QUESTION
Which state does Ĥ applied to ⟨Ĥ⟩ transition to correctly ?

The following simplifies the syntax for the definition of the Linz
Turing machine Ĥ, it is now a single machine with a single start state.
A copy of Linz H is embedded at Ĥ.qx.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

There are no finite number of steps of the pure simulation of ⟨Ĥ⟩
applied to ⟨Ĥ⟩ by embedded_H such that this simulated input meets the
Linz definition of halting:

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

Therefore it is correct to say that the input to embedded_H specifies a
sequence of configurations that never halts.

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

> To you and I, this means that he's not working on the halting problem,
> but I am not sure you can say he is lying about that. For one thing,
> how can he be intending to deceive (a core part of lying) when he's been
> clear the he accepts the wrong answer as being the right one? If
> someone claims to be working on "the addition problem", and also claims
> that 2+2=5 is correct, it's hard to consider either claim to be a lie.
> The person is just deeply confused.
>
> But what sort of confused can explain this nonsense? I think the answer
> lies in PO's background. The "binary square root" function is not
> computable as far as a mathematician is concerned because no TM can halt
> with, say, sqrt(0b10) on the tape. But to an engineer, the function
> poses no problem because we can get as close as we like. If
> 0b1.01101010000 is not good enough, just add more digits.
>
> The point is I think PO does not know what a formal, mathematical
> problem really is. To him, anything about code, machines or programs is
> about solving an engineering problem "well enough" -- with "well enough"
> open to be defined by PO himself.
>
> More disturbing to me is that he is not even talking about Turing
> machines, again as evidenced by his own plain words. It is not in
> dispute that he claims that two (deterministic) TMs, one an identical
> copy of the other, can transition to different states despite both being
> presented with identical input. These are not Turing machines but Magic
> machines, and I can't see how any discussion can be had while the action
> of the things being considered is not a simple function of the input and
> the state transition graph.
>

THIS POINT ADDRESSES A SIDE ISSUE NOT RELEVANT TO THE KEY QUESTION:
What are the details of how ⟨Ĥ⟩ applied to ⟨Ĥ⟩ behaves?

H and embedded_H are not identical, one has an infinite loop appended to
its accept state.

I will not tolerate digression into this side issue until after mutual
agreement is achieved on the first point. Until then these side issues
are no more than a dishonest dodge distraction away from the main point.

> This is why I stopped replying. While there are things to say about
> PO's Other Halting problem (principally that even the POOH problem can't
> be solved), I had nothing more to say while the "machines" being
> discussed are magic.
>

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

Re: Concise refutation of halting problem proofs V52 [ THE KEY QUESTION ]

<qNhJJ.67344$SO.20159@fx26.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder.usenetexpress.com!tr1.eu1.usenetexpress.com!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx26.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ THE KEY QUESTION ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ssh8vu$4c0$1@dont-email.me> <ssue1i$81l$1@dont-email.me> <AfGIJ.3844$dV.1984@fx44.iad> <sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com> <UHGIJ.15876$mS1.15729@fx10.iad> <Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com> <_2IIJ.42013$i%.2716@fx04.iad> <j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad> <F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com> <g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me> <vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com> <d2KIJ.24507$541.2175@fx35.iad> <4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com> <QRKIJ.10111$uP.9595@fx16.iad> <v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com> <mIQIJ.34880$%T.27606@fx06.iad> <2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com> <Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk> <iqGdnZERkLUpPmj8nZ2dnUU7-QnNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <iqGdnZERkLUpPmj8nZ2dnUU7-QnNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 116
Message-ID: <qNhJJ.67344$SO.20159@fx26.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, 29 Jan 2022 15:51:35 -0500
X-Received-Bytes: 7120
 by: Richard Damon - Sat, 29 Jan 2022 20:51 UTC

On 1/29/22 3:29 PM, olcott wrote:
> On 1/29/2022 11:34 AM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> And the 'actual behavior of its actual inputs' is DEFINED to be what
>>> the computation the input actually does when run as an independent
>>> machine, or what a UTM will do when simulating that input.
>>>
>>> If that isn't the meaning you are using, then you are just lying that
>>> you are working on the halting problem, which is what seems to be the
>>> case. (That you are lying that is).
>>
>> It is certainly true that PO is not addressing the halting problem.  He
>> has been 100% clear that false is, in his "opinion", the correct result
>> for at least one halting computation.  This is not in dispute (unless
>> he's retracted that and I missed it).
>>
>
> THIS POINT ADDRESSES THE KEY QUESTION
> Which state does Ĥ applied to ⟨Ĥ⟩ transition to correctly ?
>
>
> The following simplifies the syntax for the definition of the Linz
> Turing machine Ĥ, it is now a single machine with a single start state.
> A copy of Linz H is embedded at Ĥ.qx.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> There are no finite number of steps of the pure simulation of ⟨Ĥ⟩
> applied to ⟨Ĥ⟩ by embedded_H such that this simulated input meets the
> Linz definition of halting:
>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)
>
> Therefore it is correct to say that the input to embedded_H specifies a
> sequence of configurations that never halts.
>
> https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3
>
>
>> To you and I, this means that he's not working on the halting problem,
>> but I am not sure you can say he is lying about that.  For one thing,
>> how can he be intending to deceive (a core part of lying) when he's been
>> clear the he accepts the wrong answer as being the right one?  If
>> someone claims to be working on "the addition problem", and also claims
>> that 2+2=5 is correct, it's hard to consider either claim to be a lie.
>> The person is just deeply confused.
>>
>> But what sort of confused can explain this nonsense?  I think the answer
>> lies in PO's background.  The "binary square root" function is not
>> computable as far as a mathematician is concerned because no TM can halt
>> with, say, sqrt(0b10) on the tape.  But to an engineer, the function
>> poses no problem because we can get as close as we like.  If
>> 0b1.01101010000 is not good enough, just add more digits.
>>
>> The point is I think PO does not know what a formal, mathematical
>> problem really is.  To him, anything about code, machines or programs is
>> about solving an engineering problem "well enough" -- with "well enough"
>> open to be defined by PO himself.
>>
>> More disturbing to me is that he is not even talking about Turing
>> machines, again as evidenced by his own plain words.  It is not in
>> dispute that he claims that two (deterministic) TMs, one an identical
>> copy of the other, can transition to different states despite both being
>> presented with identical input.  These are not Turing machines but Magic
>> machines, and I can't see how any discussion can be had while the action
>> of the things being considered is not a simple function of the input and
>> the state transition graph.
>>
>
> THIS POINT ADDRESSES A SIDE ISSUE NOT RELEVANT TO THE KEY QUESTION:
> What are the details of how ⟨Ĥ⟩ applied to ⟨Ĥ⟩ behaves?
>
>
>
> H and embedded_H are not identical, one has an infinite loop appended to
> its accept state.

But that isn't part of the embedded copy of H. When you get into a car
are you no longer you because something has been 'added' to you?

>
> I will not tolerate digression into this side issue until after mutual
> agreement is achieved on the first point. Until then these side issues
> are no more than a dishonest dodge distraction away from the main point.

IF you are just going to continue to lie that the copy of H inside H
isn't actually an identical copy, then you have a very long wait (in a
very hot place).

The adding of the looping state AFTER H^.qy doesn't affect the operation
of the copy of H between H^.qx (mapping to H.q0) and ether H^.qy or
H^.qn (mapping to H.qy and H.qn).

If you care to disagree on that, please show an actual example of this
happening with actual Turing Machine code, as that is a funamental
principle of Computation Theory, and if you can show that adding states
AFTER a copy of a machine can change the behavior of a machine, that
would be a major finding.

Until then, it is just proof that you are still depending of Fairy Dust
powered Unicorns to make your 'proof' work, which proves that it is all
just a great big lie.

>
>
>> This is why I stopped replying.  While there are things to say about
>> PO's Other Halting problem (principally that even the POOH problem can't
>> be solved), I had nothing more to say while the "machines" being
>> discussed are magic.
>>
>
>

Pages:123456789101112
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor