Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Never make anything simple and efficient when a way can be found to make it complex and wonderful.


computers / comp.ai.philosophy / Re: HH(PP,PP) correctly determines that its input never halts

SubjectAuthor
* Re: HH(PP,PP) correctly determines that its input never haltsolcott
`* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
 `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
  `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
   `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    +* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |`* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    | `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |  `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |   `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |    `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     +* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     |+* Re: HH(PP,PP) correctly determines that its input never haltsPython
    |     ||+* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     |||+* Re: HH(PP,PP) correctly determines that its input never haltsPython
    |     ||||`* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     |||| +* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     |||| |`* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     |||| | `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     |||| |  `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     |||| |   `- Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     |||| `* Re: HH(PP,PP) correctly determines that its input never haltsPython
    |     ||||  +* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     ||||  |+* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     ||||  ||`* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     ||||  || `- Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     ||||  |`- Re: HH(PP,PP) correctly determines that its input never haltsPython
    |     ||||  `- Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     |||`- Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     ||`* Re: HH(PP,PP) correctly determines that its input never haltsBen Bacarisse
    |     || +* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     || |`- Re: HH(PP,PP) correctly determines that its input never haltsPython
    |     || +* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     || |`* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     || | `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     || |  `- Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     || `* Re: HH(PP,PP) correctly determines that its input never halts [Ben]olcott
    |     ||  `* Re: HH(PP,PP) correctly determines that its input never halts [Ben]Richard Damon
    |     ||   `* Re: HH(PP,PP) correctly determines that its input never halts [Ben]olcott
    |     ||    `* Re: HH(PP,PP) correctly determines that its input never halts [Ben]Richard Damon
    |     ||     `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     ||      `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     ||       `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     ||        `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     ||         `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     ||          `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     ||           `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     ||            `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     ||             `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     ||              +* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     ||              |`* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     ||              | `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     ||              |  `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     ||              |   `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     ||              |    `* Re: HH(PP,PP) correctly determines that its input never halts [Whyolcott
    |     ||              |     `* Re: HH(PP,PP) correctly determines that its input never halts [WhyRichard Damon
    |     ||              |      `* Re: HH(PP,PP) correctly determines that its input never halts [Whyolcott
    |     ||              |       `* Re: HH(PP,PP) correctly determines that its input never halts [WhyRichard Damon
    |     ||              |        `* Re: HH(PP,PP) correctly determines that its input never halts [Whyolcott
    |     ||              |         `* Re: HH(PP,PP) correctly determines that its input never halts [WhyRichard Damon
    |     ||              |          `* Re: HH(PP,PP) correctly determines that its input never halts [Whyolcott
    |     ||              |           `* Re: HH(PP,PP) correctly determines that its input never halts [WhyRichard Damon
    |     ||              |            `* Re: HH(PP,PP) correctly determines that its input never halts [Whyolcott
    |     ||              |             +* Re: HH(PP,PP) correctly determines that its input never halts [WhyPython
    |     ||              |             |`* Re: HH(PP,PP) correctly determines that its input never halts [Whyolcott
    |     ||              |             | `* Re: HH(PP,PP) correctly determines that its input never halts [WhyRichard Damon
    |     ||              |             |  `* Re: HH(PP,PP) correctly determines that its input never halts [Whyolcott
    |     ||              |             |   `- Re: HH(PP,PP) correctly determines that its input never halts [WhyRichard Damon
    |     ||              |             `* Re: HH(PP,PP) correctly determines that its input never halts [WhyRichard Damon
    |     ||              |              `* Re: HH(PP,PP) correctly determines that its input never halts [Whyolcott
    |     ||              |               `* Re: HH(PP,PP) correctly determines that its input never halts [WhyRichard Damon
    |     ||              |                `* Re: HH(PP,PP) correctly determines that its input never halts [Whyolcott
    |     ||              |                 `- Re: HH(PP,PP) correctly determines that its input never halts [WhyRichard Damon
    |     ||              `- Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     |`* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     | +* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     | |+* Re: HH(PP,PP) correctly determines that its input never haltsPython
    |     | ||`* Re: HH(PP,PP) correctly determines that its input never haltsBen Bacarisse
    |     | || `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     | ||  +* Re: HH(PP,PP) correctly determines that its input never haltsAndré G. Isaak
    |     | ||  |`* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     | ||  | `* Re: HH(PP,PP) correctly determines that its input never haltsAndré G. Isaak
    |     | ||  |  `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     | ||  |   `- Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     | ||  `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     | ||   `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     | ||    `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     | ||     `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     | ||      `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     | ||       `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     | ||        `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     | ||         `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     | ||          `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     | ||           `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     | ||            `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     | ||             `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     | ||              `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     | ||               `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     | ||                `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     | ||                 `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     | ||                  `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    |     | |`* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     | `* Re: HH(PP,PP) correctly determines that its input never haltsolcott
    |     `- Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon
    `* Re: HH(PP,PP) correctly determines that its input never haltsRichard Damon

Pages:123456
Re: HH(PP,PP) correctly determines that its input never halts

<tqpsvf$bu1t$1@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10371&group=comp.ai.philosophy#10371

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Date: Tue, 24 Jan 2023 18:26:22 -0600
Organization: A noiseless patient Spider
Lines: 111
Message-ID: <tqpsvf$bu1t$1@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 25 Jan 2023 00:26:23 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="dbd948dae9e615bb193586795239ba78";
logging-data="391229"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/cKXSlYBuTNF7O52QaF/XN"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.6.1
Cancel-Lock: sha1:uxYJPY2hXBznZb1s394xr/m4ayc=
Content-Language: en-US
In-Reply-To: <51_zL.265586$gGD7.147065@fx11.iad>
 by: olcott - Wed, 25 Jan 2023 00:26 UTC

On 1/24/2023 5:41 PM, Richard Damon wrote:
> On 1/24/23 10:41 AM, olcott wrote:
>> In computability theory, the halting problem is the problem of
>> determining, from a description of an arbitrary computer program and an
>> input, whether the program will finish running, or continue to run
>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>
>> This definition of the halting problem measures correctness in a non-
>> pathological way, thus in the same way that ZFC (redefined set theory
>> and) eliminated Russell's Paradox the previously "impossible" input
>> ceases to be impossible.
>>
>> In computability theory, the halting problem is the problem of defining
>> a machine that correctly determines from a description of an arbitrary
>> computer program and an input, whether or not its specified input pair
>> would terminate normally by reaching it own final state.
>
> Right, the Decider must decide if the actual running of the program
> described by the input would halt when given the input that is the rest
> of that input.
>
> It is NOT asking if the
>
>>
>> The conventional proofs do not actually show that such a machine cannot
>> be defined. HH(PP, PP) does correctly determine that its correctly
>> simulated input cannot possibly reach the final state of PP and
>> terminate normally. (See pages 5-6 of this paper)
>>
>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>
>> If the simulation is incorrect then there must a line of the simulation
>> that behaves differently than what its corresponding line of machine-
>> code specifies.
>
> No, it is incorrect because it is incomplete.
>
> You are just usong the INCORRECT definition of "Correct", and since you
> have been told this in the past, it just shows that you are a LIAR about
> this fact.
>
> "Correct Simulation" is defined as a simulation that exactly matches the
> actual behavior of the machine the input describes.
>

It turns out that is incorrect. The ultimate measure of a correct
simulation is whether or not the simulated input exactly matches the
behavior specified by its machine code.

> Thus the only possible correct simulation of the machine PP given input
> PP is a simulation that shows it will halt, since that IS the behavior
> that will happen when you run PP and give it the input PP, since you
> have STIPULATED that HH(PP,PP) will return non-halting (0).
>
>>
>> On pages 5 and 6 the correct semantics of the x86 language conclusively
>> proves that PP correctly simulated by HH cannot possibly reach the final
>> state of PP and terminate normally.
>>
>> HH correctly determines that PP never halts
>
> Then why will PP(PP) Halt snce PP(PP) will call HH(PP,PP) which will
> return 0 and thus PP will return?
>
> Either HH fails to meet the requirements of being a computation (being a
> fixed mapping of inputs to outputs) or it gave an incorrect answer.
>
>>
>> void PP(ptr x)
>> {
>>    int Halt_Status = HH(x, x);
>>    if (Halt_Status)HERE:
>>      goto HERE;
>>    return;
>> }
>>
>> int main()
>> {
>>    HH(PP, PP);
>> }
>>
>> All of my reviewers that disagreed that the input to HH(PP, PP) was
>> simulated correctly could not point to a single step of the simulation
>> of PP by HH where the execution trace of PP was not the exact behavior
>> that the x86 machine code of PP specified.
>>
>> These reviewers seemed to believe that the execution trace of PP need
>> not have the same behavior that its machine code specifies. That is like
>> saying that 2 + 3 = 17 on the basis of arbitrary whim rather than
>> correct arithmetic.
>>
>
> No, the execution trace of PP actually DOES need to match the behavior
> of the code, and thus the call HH must actually act as if HH was
> actually called and the behavior assumed of that call match what
> HH(PP,PP) actual does, which is return 0.
>

PP correctly simulated by HH cannot possibly reach the final state of PP
whether or not HH ever aborts its correct simulation of PP.

> You analysis looks at a DIFFERENT HH than actually presented, and thus
> your claim that it "Correctly" simulated the input is just a LIE.
>
> HH incorrectly simulates the call to HH as it presumes bhavior different
> that what actually happens, because it presume a different HH.

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

Re: HH(PP,PP) correctly determines that its input never halts

<r50AL.389317$8_id.40494@fx09.iad>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10372&group=comp.ai.philosophy#10372

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx09.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.6.1
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
Content-Language: en-US
In-Reply-To: <tqpsvf$bu1t$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 148
Message-ID: <r50AL.389317$8_id.40494@fx09.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Tue, 24 Jan 2023 21:03:02 -0500
X-Received-Bytes: 6852
 by: Richard Damon - Wed, 25 Jan 2023 02:03 UTC

On 1/24/23 7:26 PM, olcott wrote:
> On 1/24/2023 5:41 PM, Richard Damon wrote:
>> On 1/24/23 10:41 AM, olcott wrote:
>>> In computability theory, the halting problem is the problem of
>>> determining, from a description of an arbitrary computer program and an
>>> input, whether the program will finish running, or continue to run
>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> This definition of the halting problem measures correctness in a non-
>>> pathological way, thus in the same way that ZFC (redefined set theory
>>> and) eliminated Russell's Paradox the previously "impossible" input
>>> ceases to be impossible.
>>>
>>> In computability theory, the halting problem is the problem of defining
>>> a machine that correctly determines from a description of an arbitrary
>>> computer program and an input, whether or not its specified input pair
>>> would terminate normally by reaching it own final state.
>>
>> Right, the Decider must decide if the actual running of the program
>> described by the input would halt when given the input that is the
>> rest of that input.
>>
>> It is NOT asking if the
>>
>>>
>>> The conventional proofs do not actually show that such a machine cannot
>>> be defined. HH(PP, PP) does correctly determine that its correctly
>>> simulated input cannot possibly reach the final state of PP and
>>> terminate normally. (See pages 5-6 of this paper)
>>>
>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>
>>> If the simulation is incorrect then there must a line of the simulation
>>> that behaves differently than what its corresponding line of machine-
>>> code specifies.
>>
>> No, it is incorrect because it is incomplete.
>>
>> You are just usong the INCORRECT definition of "Correct", and since
>> you have been told this in the past, it just shows that you are a LIAR
>> about this fact.
>>
>> "Correct Simulation" is defined as a simulation that exactly matches
>> the actual behavior of the machine the input describes.
>>
>
> It turns out that is incorrect. The ultimate measure of a correct
> simulation is whether or not the simulated input exactly matches the
> behavior specified by its machine code.

Nope, Sourcd for that claim.

Prove it or you are admitting you are lying.

Remember, even YOU said that the correct answer for the Halt Decider is
whether THE PROGRAM (i.e. the one given as the input) would finish
runnibng (Halt) or not.

>
>> Thus the only possible correct simulation of the machine PP given
>> input PP is a simulation that shows it will halt, since that IS the
>> behavior that will happen when you run PP and give it the input PP,
>> since you have STIPULATED that HH(PP,PP) will return non-halting (0).
>>
>>>
>>> On pages 5 and 6 the correct semantics of the x86 language conclusively
>>> proves that PP correctly simulated by HH cannot possibly reach the final
>>> state of PP and terminate normally.
>>>
>>> HH correctly determines that PP never halts
>>
>> Then why will PP(PP) Halt snce PP(PP) will call HH(PP,PP) which will
>> return 0 and thus PP will return?
>>
>> Either HH fails to meet the requirements of being a computation (being
>> a fixed mapping of inputs to outputs) or it gave an incorrect answer.
>>
>>>
>>> void PP(ptr x)
>>> {
>>>    int Halt_Status = HH(x, x);
>>>    if (Halt_Status)HERE:
>>>      goto HERE;
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    HH(PP, PP);
>>> }
>>>
>>> All of my reviewers that disagreed that the input to HH(PP, PP) was
>>> simulated correctly could not point to a single step of the simulation
>>> of PP by HH where the execution trace of PP was not the exact behavior
>>> that the x86 machine code of PP specified.
>>>
>>> These reviewers seemed to believe that the execution trace of PP need
>>> not have the same behavior that its machine code specifies. That is like
>>> saying that 2 + 3 = 17 on the basis of arbitrary whim rather than
>>> correct arithmetic.
>>>
>>
>> No, the execution trace of PP actually DOES need to match the behavior
>> of the code, and thus the call HH must actually act as if HH was
>> actually called and the behavior assumed of that call match what
>> HH(PP,PP) actual does, which is return 0.
>>
>
> PP correctly simulated by HH cannot possibly reach the final state of PP
> whether or not HH ever aborts its correct simulation of PP.

That makes as much sense as the logic that

If this statement is true, then Peter Olcott is a Pathological Lyihg Idiot.

proves that you are a Pathological Lying Idiot.

If HH can refer to a hypothetical simulation of a DIFFERENT set of op
codes to determine the correct answer just because that is one way to
interpret the words, your whole logic system falls to the above rule.

YOU FAIL.

HH NEVER DOES a correct simulation of the input, so by that reasoning
there is no corrct answer to the question, so HH is just always WRONG.

We don't need the faulty logic of the above statement, by your own
claims you are proving that you are the Pathological Lying Idiot.

You think that HH can answer about a DIFFERENT input than it was giving,
different because HH treats the HH that it calls as if it was a
different function than it is.

You know this, and by claiming it is correct, you show you are a LIAR.

That you keep repeating it show the Lying is Pathological.

That you seem to expect people to beleive it show you are an IDIOT.

>
>> You analysis looks at a DIFFERENT HH than actually presented, and thus
>> your claim that it "Correctly" simulated the input is just a LIE.
>>
>> HH incorrectly simulates the call to HH as it presumes bhavior
>> different that what actually happens, because it presume a different HH.
>

Re: HH(PP,PP) correctly determines that its input never halts

<tqq6jf$g7v8$1@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10373&group=comp.ai.philosophy#10373

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Date: Tue, 24 Jan 2023 21:10:39 -0600
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <tqq6jf$g7v8$1@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 25 Jan 2023 03:10:39 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="dbd948dae9e615bb193586795239ba78";
logging-data="532456"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/BpmgvdjMPm4odsRcZ2iwE"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.6.1
Cancel-Lock: sha1:Sps/oTQ2XrmzEssdmiDygJS086c=
Content-Language: en-US
In-Reply-To: <r50AL.389317$8_id.40494@fx09.iad>
 by: olcott - Wed, 25 Jan 2023 03:10 UTC

On 1/24/2023 8:03 PM, Richard Damon wrote:
> On 1/24/23 7:26 PM, olcott wrote:
>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>> On 1/24/23 10:41 AM, olcott wrote:
>>>> In computability theory, the halting problem is the problem of
>>>> determining, from a description of an arbitrary computer program and an
>>>> input, whether the program will finish running, or continue to run
>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>> This definition of the halting problem measures correctness in a non-
>>>> pathological way, thus in the same way that ZFC (redefined set theory
>>>> and) eliminated Russell's Paradox the previously "impossible" input
>>>> ceases to be impossible.
>>>>
>>>> In computability theory, the halting problem is the problem of defining
>>>> a machine that correctly determines from a description of an arbitrary
>>>> computer program and an input, whether or not its specified input pair
>>>> would terminate normally by reaching it own final state.
>>>
>>> Right, the Decider must decide if the actual running of the program
>>> described by the input would halt when given the input that is the
>>> rest of that input.
>>>
>>> It is NOT asking if the
>>>
>>>>
>>>> The conventional proofs do not actually show that such a machine cannot
>>>> be defined. HH(PP, PP) does correctly determine that its correctly
>>>> simulated input cannot possibly reach the final state of PP and
>>>> terminate normally. (See pages 5-6 of this paper)
>>>>
>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>
>>>> If the simulation is incorrect then there must a line of the simulation
>>>> that behaves differently than what its corresponding line of machine-
>>>> code specifies.
>>>
>>> No, it is incorrect because it is incomplete.
>>>
>>> You are just usong the INCORRECT definition of "Correct", and since
>>> you have been told this in the past, it just shows that you are a
>>> LIAR about this fact.
>>>
>>> "Correct Simulation" is defined as a simulation that exactly matches
>>> the actual behavior of the machine the input describes.
>>>
>>
>> It turns out that is incorrect. The ultimate measure of a correct
>> simulation is whether or not the simulated input exactly matches the
>> behavior specified by its machine code.
>
> Nope, Sourcd for that claim.
>

Counter-examples cannot possibly exist.
Try and show any correct simulation where the simulator does not
simulate what the machine language specifies.

> Prove it or you are admitting you are lying.

It is dead obvious that I am correct. A simulator is only correct when
it simulates exactly what the machine code specifies and incorrect
otherwise.

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

Re: HH(PP,PP) correctly determines that its input never halts

<0x1AL.136150$PXw7.56787@fx45.iad>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10374&group=comp.ai.philosophy#10374

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx45.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.6.1
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tqq6jf$g7v8$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 112
Message-ID: <0x1AL.136150$PXw7.56787@fx45.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: Tue, 24 Jan 2023 22:40:44 -0500
X-Received-Bytes: 5524
 by: Richard Damon - Wed, 25 Jan 2023 03:40 UTC

On 1/24/23 10:10 PM, olcott wrote:
> On 1/24/2023 8:03 PM, Richard Damon wrote:
>> On 1/24/23 7:26 PM, olcott wrote:
>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>> In computability theory, the halting problem is the problem of
>>>>> determining, from a description of an arbitrary computer program
>>>>> and an
>>>>> input, whether the program will finish running, or continue to run
>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>
>>>>> This definition of the halting problem measures correctness in a non-
>>>>> pathological way, thus in the same way that ZFC (redefined set theory
>>>>> and) eliminated Russell's Paradox the previously "impossible" input
>>>>> ceases to be impossible.
>>>>>
>>>>> In computability theory, the halting problem is the problem of
>>>>> defining
>>>>> a machine that correctly determines from a description of an arbitrary
>>>>> computer program and an input, whether or not its specified input pair
>>>>> would terminate normally by reaching it own final state.
>>>>
>>>> Right, the Decider must decide if the actual running of the program
>>>> described by the input would halt when given the input that is the
>>>> rest of that input.
>>>>
>>>> It is NOT asking if the
>>>>
>>>>>
>>>>> The conventional proofs do not actually show that such a machine
>>>>> cannot
>>>>> be defined. HH(PP, PP) does correctly determine that its correctly
>>>>> simulated input cannot possibly reach the final state of PP and
>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>
>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>
>>>>> If the simulation is incorrect then there must a line of the
>>>>> simulation
>>>>> that behaves differently than what its corresponding line of machine-
>>>>> code specifies.
>>>>
>>>> No, it is incorrect because it is incomplete.
>>>>
>>>> You are just usong the INCORRECT definition of "Correct", and since
>>>> you have been told this in the past, it just shows that you are a
>>>> LIAR about this fact.
>>>>
>>>> "Correct Simulation" is defined as a simulation that exactly matches
>>>> the actual behavior of the machine the input describes.
>>>>
>>>
>>> It turns out that is incorrect. The ultimate measure of a correct
>>> simulation is whether or not the simulated input exactly matches the
>>> behavior specified by its machine code.
>>
>> Nope, Sourcd for that claim.
>>
>
> Counter-examples cannot possibly exist.
> Try and show any correct simulation where the simulator does not
> simulate what the machine language specifies.

This is the counter example.

Since the direct eecution of the machine language of PP(PP) will Halt,
the correct simulation of it must match.

Since HH deterines that the call HH(PP,PP) will not return, it has
INCORRECTLY simulated that instruction,

Perhaps by NOT actually simulating it but using faulty logic, and thus
making an error.

>
>> Prove it or you are admitting you are lying.
>
> It is dead obvious that I am correct. A simulator is only correct when
> it simulates exactly what the machine code specifies and incorrect
> otherwise.
>

No, it is obviouys that you are wrong.

BY YOUR OWN DEFINITION at the begining, the CORRECT answer for the Halt
Decider is what the program actually does.

Since you stipulate that HH(PP,PP) will "correctly" return 0, you have
stipulated that it DOES return 0 (the correctly can be ignored, as you
can not stipulate correctness).

SInce H(H(PP,PP) returns 0, by trivial inspection of PP(PP) we see that
it will return, and thus BY THE DEFINITION of a halt decider, the
correct answer is Halting, so HH returning 0 is incorrect.

If you want to claim that the "correct simulation" of the input to
HH(PP,PP) and the direct execution of PP(PP) can differ, please show the
exact assembly instruction correctly simulated and executed where they
do differ.

Note, you have to show where that difference occurs for an actually
exucted and simulated instruction, of exactly the same assembly code
difffer.

You have a mental defect where you seem to not be able to distinguish
when to things are different. This is one definition of Insanity.

Your claim "eqivalent" rule is not equivalent and you insistance that
they are even though they give different answers shows this problem.

GET HELP.

Re: HH(PP,PP) correctly determines that its input never halts

<tqq90e$gh3t$1@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10375&group=comp.ai.philosophy#10375

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Date: Tue, 24 Jan 2023 21:51:42 -0600
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <tqq90e$gh3t$1@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 25 Jan 2023 03:51:42 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="dbd948dae9e615bb193586795239ba78";
logging-data="541821"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/vJWqtt5aSIYMehFUExGl+"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.6.1
Cancel-Lock: sha1:skNdO6UqTOqBW2Eb3Dz1nNT1pNk=
Content-Language: en-US
In-Reply-To: <0x1AL.136150$PXw7.56787@fx45.iad>
 by: olcott - Wed, 25 Jan 2023 03:51 UTC

On 1/24/2023 9:40 PM, Richard Damon wrote:
> On 1/24/23 10:10 PM, olcott wrote:
>> On 1/24/2023 8:03 PM, Richard Damon wrote:
>>> On 1/24/23 7:26 PM, olcott wrote:
>>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>>> In computability theory, the halting problem is the problem of
>>>>>> determining, from a description of an arbitrary computer program
>>>>>> and an
>>>>>> input, whether the program will finish running, or continue to run
>>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>>
>>>>>> This definition of the halting problem measures correctness in a non-
>>>>>> pathological way, thus in the same way that ZFC (redefined set theory
>>>>>> and) eliminated Russell's Paradox the previously "impossible" input
>>>>>> ceases to be impossible.
>>>>>>
>>>>>> In computability theory, the halting problem is the problem of
>>>>>> defining
>>>>>> a machine that correctly determines from a description of an
>>>>>> arbitrary
>>>>>> computer program and an input, whether or not its specified input
>>>>>> pair
>>>>>> would terminate normally by reaching it own final state.
>>>>>
>>>>> Right, the Decider must decide if the actual running of the program
>>>>> described by the input would halt when given the input that is the
>>>>> rest of that input.
>>>>>
>>>>> It is NOT asking if the
>>>>>
>>>>>>
>>>>>> The conventional proofs do not actually show that such a machine
>>>>>> cannot
>>>>>> be defined. HH(PP, PP) does correctly determine that its correctly
>>>>>> simulated input cannot possibly reach the final state of PP and
>>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>>
>>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>>
>>>>>> If the simulation is incorrect then there must a line of the
>>>>>> simulation
>>>>>> that behaves differently than what its corresponding line of machine-
>>>>>> code specifies.
>>>>>
>>>>> No, it is incorrect because it is incomplete.
>>>>>
>>>>> You are just usong the INCORRECT definition of "Correct", and since
>>>>> you have been told this in the past, it just shows that you are a
>>>>> LIAR about this fact.
>>>>>
>>>>> "Correct Simulation" is defined as a simulation that exactly
>>>>> matches the actual behavior of the machine the input describes.
>>>>>
>>>>
>>>> It turns out that is incorrect. The ultimate measure of a correct
>>>> simulation is whether or not the simulated input exactly matches the
>>>> behavior specified by its machine code.
>>>
>>> Nope, Sourcd for that claim.
>>>
>>
>> Counter-examples cannot possibly exist.
>> Try and show any correct simulation where the simulator does not
>> simulate what the machine language specifies.
>
> This is the counter example.
>
> Since the direct eecution of the machine language of PP(PP) will Halt,
> the correct simulation of it must match.
>

That is merely a provably false assumption.

Try and provide a 100% specific counter-example where you show a line of
machine code such as [mov eax, 1] and the simulator simulates another
different line instead such as [push ebx] and the simulator is correct.

If no such counter-example exists then it is proven that the ultimate
measure of correct simulation is that the simulator simulates line-by-
line exactly what the machine code specifies.

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

Re: HH(PP,PP) correctly determines that its input never halts

<cY1AL.308016$Tcw8.270142@fx10.iad>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10376&group=comp.ai.philosophy#10376

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx10.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.6.1
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tqq90e$gh3t$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 117
Message-ID: <cY1AL.308016$Tcw8.270142@fx10.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: Tue, 24 Jan 2023 23:09:43 -0500
X-Received-Bytes: 5535
 by: Richard Damon - Wed, 25 Jan 2023 04:09 UTC

On 1/24/23 10:51 PM, olcott wrote:
> On 1/24/2023 9:40 PM, Richard Damon wrote:
>> On 1/24/23 10:10 PM, olcott wrote:
>>> On 1/24/2023 8:03 PM, Richard Damon wrote:
>>>> On 1/24/23 7:26 PM, olcott wrote:
>>>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>> determining, from a description of an arbitrary computer program
>>>>>>> and an
>>>>>>> input, whether the program will finish running, or continue to run
>>>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>
>>>>>>> This definition of the halting problem measures correctness in a
>>>>>>> non-
>>>>>>> pathological way, thus in the same way that ZFC (redefined set
>>>>>>> theory
>>>>>>> and) eliminated Russell's Paradox the previously "impossible" input
>>>>>>> ceases to be impossible.
>>>>>>>
>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>> defining
>>>>>>> a machine that correctly determines from a description of an
>>>>>>> arbitrary
>>>>>>> computer program and an input, whether or not its specified input
>>>>>>> pair
>>>>>>> would terminate normally by reaching it own final state.
>>>>>>
>>>>>> Right, the Decider must decide if the actual running of the
>>>>>> program described by the input would halt when given the input
>>>>>> that is the rest of that input.
>>>>>>
>>>>>> It is NOT asking if the
>>>>>>
>>>>>>>
>>>>>>> The conventional proofs do not actually show that such a machine
>>>>>>> cannot
>>>>>>> be defined. HH(PP, PP) does correctly determine that its correctly
>>>>>>> simulated input cannot possibly reach the final state of PP and
>>>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>>>
>>>>>>> If the simulation is incorrect then there must a line of the
>>>>>>> simulation
>>>>>>> that behaves differently than what its corresponding line of
>>>>>>> machine-
>>>>>>> code specifies.
>>>>>>
>>>>>> No, it is incorrect because it is incomplete.
>>>>>>
>>>>>> You are just usong the INCORRECT definition of "Correct", and
>>>>>> since you have been told this in the past, it just shows that you
>>>>>> are a LIAR about this fact.
>>>>>>
>>>>>> "Correct Simulation" is defined as a simulation that exactly
>>>>>> matches the actual behavior of the machine the input describes.
>>>>>>
>>>>>
>>>>> It turns out that is incorrect. The ultimate measure of a correct
>>>>> simulation is whether or not the simulated input exactly matches the
>>>>> behavior specified by its machine code.
>>>>
>>>> Nope, Sourcd for that claim.
>>>>
>>>
>>> Counter-examples cannot possibly exist.
>>> Try and show any correct simulation where the simulator does not
>>> simulate what the machine language specifies.
>>
>> This is the counter example.
>>
>> Since the direct eecution of the machine language of PP(PP) will Halt,
>> the correct simulation of it must match.
>>
>
> That is merely a provably false assumption.

Then do so.

Remember, your HH has been admitted to return 0 from HH(PP,PP), and to
be a computation, it must do the same to EVERY call.

YOU have posted the execution trace of the direct execution of the
equivalent to PP, which shows it halts.

Are you admitting you are a liar?

>
> Try and provide a 100% specific counter-example where you show a line of
> machine code such as [mov eax, 1] and the simulator simulates another
> different line instead such as [push ebx] and the simulator is correct.

You simulation of the call HH says it will not return.

The actual execution of the program shows it does.

QED, the simulation is WRONG.
'

>
> If no such counter-example exists then it is proven that the ultimate
> measure of correct simulation is that the simulator simulates line-by-
> line exactly what the machine code specifies.
>

Nope, in fact making such a claim shows you are a hypocrite, dooed to go
to Hell (by your own quotes).

To be true, you need to show an actual coneection to the truth maker
axioms of the system.

You know, thing like you DEFINIION of what a Halt decider is, that the
correct answer is based on the actual execution.

You are just proving that you are a DOOM PATHALOGICAL LYING IDIOT.

Re: HH(PP,PP) correctly determines that its input never halts

<082AL.308017$Tcw8.209243@fx10.iad>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10377&group=comp.ai.philosophy#10377

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx10.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.6.1
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tqq90e$gh3t$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 21
Message-ID: <082AL.308017$Tcw8.209243@fx10.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: Tue, 24 Jan 2023 23:22:19 -0500
X-Received-Bytes: 1664
 by: Richard Damon - Wed, 25 Jan 2023 04:22 UTC

On 1/24/23 10:51 PM, olcott wrote:
> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>
>> Since the direct eecution of the machine language of PP(PP) will Halt,
>> the correct simulation of it must match.
>>
>
> That is merely a provably false assumption.

Simple question for a counter.

You seem to be saying that when PP calls HH(PP,PP) then HH will not
return, but when main call HH(PP,PP) it will

Please show the first assembly instruction of these two exectution paths
that differ in operation.

Failure to provide this shows you are just a pathological liar.

Re: HH(PP,PP) correctly determines that its input never halts

<tqqdpl$hcci$1@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10378&group=comp.ai.philosophy#10378

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Date: Tue, 24 Jan 2023 23:13:25 -0600
Organization: A noiseless patient Spider
Lines: 114
Message-ID: <tqqdpl$hcci$1@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 25 Jan 2023 05:13:25 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="dbd948dae9e615bb193586795239ba78";
logging-data="569746"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+7kuJdHBMM0xqvW09RcbdY"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.6.1
Cancel-Lock: sha1:M3u90LIqpZu5TAV1gshChU8rcf8=
Content-Language: en-US
In-Reply-To: <cY1AL.308016$Tcw8.270142@fx10.iad>
 by: olcott - Wed, 25 Jan 2023 05:13 UTC

On 1/24/2023 10:09 PM, Richard Damon wrote:
> On 1/24/23 10:51 PM, olcott wrote:
>> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>> On 1/24/23 10:10 PM, olcott wrote:
>>>> On 1/24/2023 8:03 PM, Richard Damon wrote:
>>>>> On 1/24/23 7:26 PM, olcott wrote:
>>>>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>> determining, from a description of an arbitrary computer program
>>>>>>>> and an
>>>>>>>> input, whether the program will finish running, or continue to run
>>>>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>
>>>>>>>> This definition of the halting problem measures correctness in a
>>>>>>>> non-
>>>>>>>> pathological way, thus in the same way that ZFC (redefined set
>>>>>>>> theory
>>>>>>>> and) eliminated Russell's Paradox the previously "impossible" input
>>>>>>>> ceases to be impossible.
>>>>>>>>
>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>> defining
>>>>>>>> a machine that correctly determines from a description of an
>>>>>>>> arbitrary
>>>>>>>> computer program and an input, whether or not its specified
>>>>>>>> input pair
>>>>>>>> would terminate normally by reaching it own final state.
>>>>>>>
>>>>>>> Right, the Decider must decide if the actual running of the
>>>>>>> program described by the input would halt when given the input
>>>>>>> that is the rest of that input.
>>>>>>>
>>>>>>> It is NOT asking if the
>>>>>>>
>>>>>>>>
>>>>>>>> The conventional proofs do not actually show that such a machine
>>>>>>>> cannot
>>>>>>>> be defined. HH(PP, PP) does correctly determine that its correctly
>>>>>>>> simulated input cannot possibly reach the final state of PP and
>>>>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>>>>
>>>>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>>>>
>>>>>>>> If the simulation is incorrect then there must a line of the
>>>>>>>> simulation
>>>>>>>> that behaves differently than what its corresponding line of
>>>>>>>> machine-
>>>>>>>> code specifies.
>>>>>>>
>>>>>>> No, it is incorrect because it is incomplete.
>>>>>>>
>>>>>>> You are just usong the INCORRECT definition of "Correct", and
>>>>>>> since you have been told this in the past, it just shows that you
>>>>>>> are a LIAR about this fact.
>>>>>>>
>>>>>>> "Correct Simulation" is defined as a simulation that exactly
>>>>>>> matches the actual behavior of the machine the input describes.
>>>>>>>
>>>>>>
>>>>>> It turns out that is incorrect. The ultimate measure of a correct
>>>>>> simulation is whether or not the simulated input exactly matches the
>>>>>> behavior specified by its machine code.
>>>>>
>>>>> Nope, Sourcd for that claim.
>>>>>
>>>>
>>>> Counter-examples cannot possibly exist.
>>>> Try and show any correct simulation where the simulator does not
>>>> simulate what the machine language specifies.
>>>
>>> This is the counter example.
>>>
>>> Since the direct eecution of the machine language of PP(PP) will
>>> Halt, the correct simulation of it must match.
>>>
>>
>> That is merely a provably false assumption.
>
> Then do so.
>
> Remember, your HH has been admitted to return 0 from HH(PP,PP), and to
> be a computation, it must do the same to EVERY call.
>
> YOU have posted the execution trace of the direct execution of the
> equivalent to PP, which shows it halts.
>

You can see on pages 5-6 that PP correctly simulated by HH cannot
possibly reach it own final state.

https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem

> Are you admitting you are a liar?

You should be smart enough to determine that I am not a Liar.
A mere Liar could not stay motivated for this long.
A mere liar would not have created an operating system.

>
>>
>> Try and provide a 100% specific counter-example where you show a line of
>> machine code such as [mov eax, 1] and the simulator simulates another
>> different line instead such as [push ebx] and the simulator is correct.
>
> You simulation of the call HH says it will not return.
>
> The actual execution of the program shows it does.
> --
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

Re: HH(PP,PP) correctly determines that its input never halts

<BE8AL.276573$gGD7.12810@fx11.iad>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10379&group=comp.ai.philosophy#10379

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!tr1.eu1.usenetexpress.com!81.171.65.16.MISMATCH!peer03.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx11.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad> <tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad> <tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad> <tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad> <tqqdpl$hcci$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
Content-Language: en-US
In-Reply-To: <tqqdpl$hcci$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 162
Message-ID: <BE8AL.276573$gGD7.12810@fx11.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 25 Jan 2023 06:46:40 -0500
X-Received-Bytes: 7864
 by: Richard Damon - Wed, 25 Jan 2023 11:46 UTC

On 1/25/23 12:13 AM, olcott wrote:
> On 1/24/2023 10:09 PM, Richard Damon wrote:
>> On 1/24/23 10:51 PM, olcott wrote:
>>> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>>> On 1/24/23 10:10 PM, olcott wrote:
>>>>> On 1/24/2023 8:03 PM, Richard Damon wrote:
>>>>>> On 1/24/23 7:26 PM, olcott wrote:
>>>>>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>>>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>> program and an
>>>>>>>>> input, whether the program will finish running, or continue to run
>>>>>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>
>>>>>>>>> This definition of the halting problem measures correctness in
>>>>>>>>> a non-
>>>>>>>>> pathological way, thus in the same way that ZFC (redefined set
>>>>>>>>> theory
>>>>>>>>> and) eliminated Russell's Paradox the previously "impossible"
>>>>>>>>> input
>>>>>>>>> ceases to be impossible.
>>>>>>>>>
>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>> defining
>>>>>>>>> a machine that correctly determines from a description of an
>>>>>>>>> arbitrary
>>>>>>>>> computer program and an input, whether or not its specified
>>>>>>>>> input pair
>>>>>>>>> would terminate normally by reaching it own final state.
>>>>>>>>
>>>>>>>> Right, the Decider must decide if the actual running of the
>>>>>>>> program described by the input would halt when given the input
>>>>>>>> that is the rest of that input.
>>>>>>>>
>>>>>>>> It is NOT asking if the
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The conventional proofs do not actually show that such a
>>>>>>>>> machine cannot
>>>>>>>>> be defined. HH(PP, PP) does correctly determine that its correctly
>>>>>>>>> simulated input cannot possibly reach the final state of PP and
>>>>>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>>>>>
>>>>>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>>>>>
>>>>>>>>> If the simulation is incorrect then there must a line of the
>>>>>>>>> simulation
>>>>>>>>> that behaves differently than what its corresponding line of
>>>>>>>>> machine-
>>>>>>>>> code specifies.
>>>>>>>>
>>>>>>>> No, it is incorrect because it is incomplete.
>>>>>>>>
>>>>>>>> You are just usong the INCORRECT definition of "Correct", and
>>>>>>>> since you have been told this in the past, it just shows that
>>>>>>>> you are a LIAR about this fact.
>>>>>>>>
>>>>>>>> "Correct Simulation" is defined as a simulation that exactly
>>>>>>>> matches the actual behavior of the machine the input describes.
>>>>>>>>
>>>>>>>
>>>>>>> It turns out that is incorrect. The ultimate measure of a correct
>>>>>>> simulation is whether or not the simulated input exactly matches the
>>>>>>> behavior specified by its machine code.
>>>>>>
>>>>>> Nope, Sourcd for that claim.
>>>>>>
>>>>>
>>>>> Counter-examples cannot possibly exist.
>>>>> Try and show any correct simulation where the simulator does not
>>>>> simulate what the machine language specifies.
>>>>
>>>> This is the counter example.
>>>>
>>>> Since the direct eecution of the machine language of PP(PP) will
>>>> Halt, the correct simulation of it must match.
>>>>
>>>
>>> That is merely a provably false assumption.
>>
>> Then do so.
>>
>> Remember, your HH has been admitted to return 0 from HH(PP,PP), and to
>> be a computation, it must do the same to EVERY call.
>>
>> YOU have posted the execution trace of the direct execution of the
>> equivalent to PP, which shows it halts.
>>
>
> You can see on pages 5-6 that PP correctly simulated by HH cannot
> possibly reach it own final state.

But that isn't the questipon, since that question, like the Liar's
paradox has no answer.

The question, as you stated at the begining is what does the execution
of the program at the input do? (It Halts since HH(PP,PPP) is said to
return 0)

Which by the definition of a UTM, what does the simulation of a UTM of
this input do? (Which Halts, since HH(PP,PP) is said to return 0).

Since an actual Correct Simulation of this input Halts, any simulation
done by HH, if it was "Correct" needs to say the input will Halt.

Since HH's simulation, by your claims, says it doesn't halt, it, BY
DEFINNITION, can't be correct.

We can see the "error" in several ways:

1) First, the idea that the fact that a partial simulation being
"correct" by just matching the leading subset of the actual behaivor is,
by itself, enough to tell what the final results of the behavior, is
just an insaine idea. That is like saying you can tell how long a trail
is by walking the first 50 feet of it.

2) The idea that you have gathered enough information from the partial
simulation of PP up to the call to HH to predict is absurd. Since you
haven't traced into HH, you can't tell from the trace, what its behavior
will be, so you don't can't actually tell what will happen. If you use
the knowledge that it is matching yourself, then you need to use logic
that says it WILL do what you will do, so if you abort, it will abort,
so you can't just assume it will go on forevrer, unless you will do that.

This has been explained to you many times, your failure to see shows
your self imposed ignorance, and utter stupidity,

>
> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>
>
>> Are you admitting you are a liar?
>
> You should be smart enough to determine that I am not a Liar.
> A mere Liar could not stay motivated for this long.
> A mere liar would not have created an operating system.

No, you aren't a mere liar, you are a Pathological Lying Idiot.

You admit this because you didn't answer the question I put in my other
post.

You have just proved you can't tell the difference between same and
different.
>
>>
>>>
>>> Try and provide a 100% specific counter-example where you show a line of
>>> machine code such as [mov eax, 1] and the simulator simulates another
>>> different line instead such as [push ebx] and the simulator is correct.
>>
>> You simulation of the call HH says it will not return.
>>
>> The actual execution of the program shows it does.
>> --
> Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
> hits a target no one else can see." Arthur Schopenhauer
>

And an insane person tries to hit targets that are not there.

Re: HH(PP,PP) correctly determines that its input never halts

<tqrlbh$o3id$1@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10380&group=comp.ai.philosophy#10380

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Date: Wed, 25 Jan 2023 10:28:32 -0600
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <tqrlbh$o3id$1@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <082AL.308017$Tcw8.209243@fx10.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 25 Jan 2023 16:28:33 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="dbd948dae9e615bb193586795239ba78";
logging-data="790093"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+bDDIfu5AcoI0DA82qCJ9X"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.6.1
Cancel-Lock: sha1:QQPuI9Rtsutvgmx8M8WaZ+uIOjI=
Content-Language: en-US
In-Reply-To: <082AL.308017$Tcw8.209243@fx10.iad>
 by: olcott - Wed, 25 Jan 2023 16:28 UTC

On 1/24/2023 10:22 PM, Richard Damon wrote:
> On 1/24/23 10:51 PM, olcott wrote:
>> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>>
>>> Since the direct eecution of the machine language of PP(PP) will
>>> Halt, the correct simulation of it must match.
>>>
>>
>> That is merely a provably false assumption.
>
> Simple question for a counter.
>
> You seem to be saying that when PP calls HH(PP,PP) then HH will not
> return, but when main call HH(PP,PP) it will
>

Whenever a simulated P calls a simulated H, this simulated P cannot
possibly reach its final state.

Whenever a directly executed P calls a directly executed H, this
directly executed P reaches its final state.

>
> Please show the first assembly instruction of these two exectution paths
> that differ in operation.
>

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

On page 5 there are three calls to H(P,P) from P(P):
(1) The first one from directly executed P(P) eventually returns to
12f7.

(2) The second one causes the simulated P(P) to be simulated again.

(3) The third one from the second simulated P(P) would cause the
simulated P(P) to be simulated a third time is aborted.

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

Re: HH(PP,PP) correctly determines that its input never halts

<tqrmnb$ob0i$1@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10381&group=comp.ai.philosophy#10381

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Date: Wed, 25 Jan 2023 10:51:53 -0600
Organization: A noiseless patient Spider
Lines: 149
Message-ID: <tqrmnb$ob0i$1@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
<tqqdpl$hcci$1@dont-email.me> <BE8AL.276573$gGD7.12810@fx11.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 25 Jan 2023 16:51:55 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="dbd948dae9e615bb193586795239ba78";
logging-data="797714"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/3EIEN5rC3EcVq9A1gqP5Y"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.6.1
Cancel-Lock: sha1:4ZOGGu5GeiZPNhSqi63LH7LpBu8=
In-Reply-To: <BE8AL.276573$gGD7.12810@fx11.iad>
Content-Language: en-US
 by: olcott - Wed, 25 Jan 2023 16:51 UTC

On 1/25/2023 5:46 AM, Richard Damon wrote:
> On 1/25/23 12:13 AM, olcott wrote:
>> On 1/24/2023 10:09 PM, Richard Damon wrote:
>>> On 1/24/23 10:51 PM, olcott wrote:
>>>> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>>>> On 1/24/23 10:10 PM, olcott wrote:
>>>>>> On 1/24/2023 8:03 PM, Richard Damon wrote:
>>>>>>> On 1/24/23 7:26 PM, olcott wrote:
>>>>>>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>>>>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>>> program and an
>>>>>>>>>> input, whether the program will finish running, or continue to
>>>>>>>>>> run
>>>>>>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>
>>>>>>>>>> This definition of the halting problem measures correctness in
>>>>>>>>>> a non-
>>>>>>>>>> pathological way, thus in the same way that ZFC (redefined set
>>>>>>>>>> theory
>>>>>>>>>> and) eliminated Russell's Paradox the previously "impossible"
>>>>>>>>>> input
>>>>>>>>>> ceases to be impossible.
>>>>>>>>>>
>>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>>> defining
>>>>>>>>>> a machine that correctly determines from a description of an
>>>>>>>>>> arbitrary
>>>>>>>>>> computer program and an input, whether or not its specified
>>>>>>>>>> input pair
>>>>>>>>>> would terminate normally by reaching it own final state.
>>>>>>>>>
>>>>>>>>> Right, the Decider must decide if the actual running of the
>>>>>>>>> program described by the input would halt when given the input
>>>>>>>>> that is the rest of that input.
>>>>>>>>>
>>>>>>>>> It is NOT asking if the
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The conventional proofs do not actually show that such a
>>>>>>>>>> machine cannot
>>>>>>>>>> be defined. HH(PP, PP) does correctly determine that its
>>>>>>>>>> correctly
>>>>>>>>>> simulated input cannot possibly reach the final state of PP and
>>>>>>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>>>>>>
>>>>>>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>>>>>>
>>>>>>>>>> If the simulation is incorrect then there must a line of the
>>>>>>>>>> simulation
>>>>>>>>>> that behaves differently than what its corresponding line of
>>>>>>>>>> machine-
>>>>>>>>>> code specifies.
>>>>>>>>>
>>>>>>>>> No, it is incorrect because it is incomplete.
>>>>>>>>>
>>>>>>>>> You are just usong the INCORRECT definition of "Correct", and
>>>>>>>>> since you have been told this in the past, it just shows that
>>>>>>>>> you are a LIAR about this fact.
>>>>>>>>>
>>>>>>>>> "Correct Simulation" is defined as a simulation that exactly
>>>>>>>>> matches the actual behavior of the machine the input describes.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It turns out that is incorrect. The ultimate measure of a correct
>>>>>>>> simulation is whether or not the simulated input exactly matches
>>>>>>>> the
>>>>>>>> behavior specified by its machine code.
>>>>>>>
>>>>>>> Nope, Sourcd for that claim.
>>>>>>>
>>>>>>
>>>>>> Counter-examples cannot possibly exist.
>>>>>> Try and show any correct simulation where the simulator does not
>>>>>> simulate what the machine language specifies.
>>>>>
>>>>> This is the counter example.
>>>>>
>>>>> Since the direct eecution of the machine language of PP(PP) will
>>>>> Halt, the correct simulation of it must match.
>>>>>
>>>>
>>>> That is merely a provably false assumption.
>>>
>>> Then do so.
>>>
>>> Remember, your HH has been admitted to return 0 from HH(PP,PP), and
>>> to be a computation, it must do the same to EVERY call.
>>>
>>> YOU have posted the execution trace of the direct execution of the
>>> equivalent to PP, which shows it halts.
>>>
>>
>> You can see on pages 5-6 that PP correctly simulated by HH cannot
>> possibly reach it own final state.
>
> But that isn't the questipon, since that question, like the Liar's
> paradox has no answer.
>
That makes the Halting Problem ill-defined:

In the study of problem solving, any problem in which the initial state
or starting position, the allowable operations, and the goal state are
clearly specified, *and a unique solution can be shown to exist*

https://www.oxfordreference.com/display/10.1093/oi/authority.20110803121717729;jsessionid=DAD4AA6FA046509B2E4564A52201A947

Now finally Oxford agrees with me on this 8 years later:
Feb 20, 2015, 11:38:48 AM sci.lang
The logical law of polar questions

When posed to a man whom has never been married,
the question: Have you stopped beating your wife?
Is an incorrect polar question because neither yes nor
no is a correct answer.

All polar questions (including incorrect polar questions)
have exactly one answer from the following:
1) No
2) Yes
3) Neither // Only applies to incorrect polar questions
Copyright Olcott 2015
https://groups.google.com/g/sci.lang/c/AO5Vlupeelo/m/nxJy7N2vULwJ

In the same way that ZFC eliminated Russell's Paradox by redefining set
theory to eliminate a key element of Russell's Paradox a set as a member
of itself, the Halting Problem is redefined eliminating its pathology.

The halting problem is the problem of defining a machine that correctly
determines from a description of an arbitrary computer program and an
input, whether or not its specified input pair would terminate normally
by reaching it own final state on the basis of its correct simulation of
this input pair.

MIT Professor Michael Sipser has agreed that the following verbatim
paragraph is correct (he has not reviewed or agreed to anything else):
If simulating halt decider H correctly simulates its input D until
H correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly
report that D specifies a non-halting sequence of configurations.

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

Re: HH(PP,PP) correctly determines that its input never halts

<mKiAL.355627$MVg8.158433@fx12.iad>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10382&group=comp.ai.philosophy#10382

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx12.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.6.1
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
<tqqdpl$hcci$1@dont-email.me> <BE8AL.276573$gGD7.12810@fx11.iad>
<tqrmnb$ob0i$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
Content-Language: en-US
In-Reply-To: <tqrmnb$ob0i$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 202
Message-ID: <mKiAL.355627$MVg8.158433@fx12.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 25 Jan 2023 18:15:30 -0500
X-Received-Bytes: 9575
 by: Richard Damon - Wed, 25 Jan 2023 23:15 UTC

On 1/25/23 11:51 AM, olcott wrote:
> On 1/25/2023 5:46 AM, Richard Damon wrote:
>> On 1/25/23 12:13 AM, olcott wrote:
>>> On 1/24/2023 10:09 PM, Richard Damon wrote:
>>>> On 1/24/23 10:51 PM, olcott wrote:
>>>>> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>>>>> On 1/24/23 10:10 PM, olcott wrote:
>>>>>>> On 1/24/2023 8:03 PM, Richard Damon wrote:
>>>>>>>> On 1/24/23 7:26 PM, olcott wrote:
>>>>>>>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>>>>>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>>>> program and an
>>>>>>>>>>> input, whether the program will finish running, or continue
>>>>>>>>>>> to run
>>>>>>>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>
>>>>>>>>>>> This definition of the halting problem measures correctness
>>>>>>>>>>> in a non-
>>>>>>>>>>> pathological way, thus in the same way that ZFC (redefined
>>>>>>>>>>> set theory
>>>>>>>>>>> and) eliminated Russell's Paradox the previously "impossible"
>>>>>>>>>>> input
>>>>>>>>>>> ceases to be impossible.
>>>>>>>>>>>
>>>>>>>>>>> In computability theory, the halting problem is the problem
>>>>>>>>>>> of defining
>>>>>>>>>>> a machine that correctly determines from a description of an
>>>>>>>>>>> arbitrary
>>>>>>>>>>> computer program and an input, whether or not its specified
>>>>>>>>>>> input pair
>>>>>>>>>>> would terminate normally by reaching it own final state.
>>>>>>>>>>
>>>>>>>>>> Right, the Decider must decide if the actual running of the
>>>>>>>>>> program described by the input would halt when given the input
>>>>>>>>>> that is the rest of that input.
>>>>>>>>>>
>>>>>>>>>> It is NOT asking if the
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The conventional proofs do not actually show that such a
>>>>>>>>>>> machine cannot
>>>>>>>>>>> be defined. HH(PP, PP) does correctly determine that its
>>>>>>>>>>> correctly
>>>>>>>>>>> simulated input cannot possibly reach the final state of PP and
>>>>>>>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>>>>>>>
>>>>>>>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>>>>>>>
>>>>>>>>>>> If the simulation is incorrect then there must a line of the
>>>>>>>>>>> simulation
>>>>>>>>>>> that behaves differently than what its corresponding line of
>>>>>>>>>>> machine-
>>>>>>>>>>> code specifies.
>>>>>>>>>>
>>>>>>>>>> No, it is incorrect because it is incomplete.
>>>>>>>>>>
>>>>>>>>>> You are just usong the INCORRECT definition of "Correct", and
>>>>>>>>>> since you have been told this in the past, it just shows that
>>>>>>>>>> you are a LIAR about this fact.
>>>>>>>>>>
>>>>>>>>>> "Correct Simulation" is defined as a simulation that exactly
>>>>>>>>>> matches the actual behavior of the machine the input describes.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It turns out that is incorrect. The ultimate measure of a correct
>>>>>>>>> simulation is whether or not the simulated input exactly
>>>>>>>>> matches the
>>>>>>>>> behavior specified by its machine code.
>>>>>>>>
>>>>>>>> Nope, Sourcd for that claim.
>>>>>>>>
>>>>>>>
>>>>>>> Counter-examples cannot possibly exist.
>>>>>>> Try and show any correct simulation where the simulator does not
>>>>>>> simulate what the machine language specifies.
>>>>>>
>>>>>> This is the counter example.
>>>>>>
>>>>>> Since the direct eecution of the machine language of PP(PP) will
>>>>>> Halt, the correct simulation of it must match.
>>>>>>
>>>>>
>>>>> That is merely a provably false assumption.
>>>>
>>>> Then do so.
>>>>
>>>> Remember, your HH has been admitted to return 0 from HH(PP,PP), and
>>>> to be a computation, it must do the same to EVERY call.
>>>>
>>>> YOU have posted the execution trace of the direct execution of the
>>>> equivalent to PP, which shows it halts.
>>>>
>>>
>>> You can see on pages 5-6 that PP correctly simulated by HH cannot
>>> possibly reach it own final state.
>>
>> But that isn't the questipon, since that question, like the Liar's
>> paradox has no answer.
>>
> That makes the Halting Problem ill-defined:

No, your RESTATEMENT is ill-defined. The behavior of P is well defined
given a proper definition of H

H(P,P) can do one of 4 things, and can't do anything else.

1) H(P,P) can return 0, in which case P(P) will halt, and H is shown to
be wrong. This is what you claim your H does when directly called.

2) H(P,P) can retrun 1, in which case, P(P) will go into an infinite
loop, and H is shown to be wrong.

3) H(P,P) can just dies and halt and not return an answer, in which case
H fails to be the needed halt decider, and P(P) will be halting.

4) H(P,P) can get stuck in an infinte loop, and never return an answer,
in which case H fails to be the needed halt decider, and P(P) will be
non-halting. This is what you seem to claim is what H does when
simulated inside P.

>
> In the study of problem solving, any problem in which the initial state
> or starting position, the allowable operations, and the goal state are
> clearly specified, *and a unique solution can be shown to exist*

Right, and given an actual definition of the complete algorithm of H
(and 'Get the right answer' is NOT an complete algorithm) there is a
precise correct answer to the problem.

Unfortunately of H, H can never give that answer.

>
> https://www.oxfordreference.com/display/10.1093/oi/authority.20110803121717729;jsessionid=DAD4AA6FA046509B2E4564A52201A947
>
>
> Now finally Oxford agrees with me on this 8 years later:
> Feb 20, 2015, 11:38:48 AM  sci.lang
> The logical law of polar questions
>
> When posed to a man whom has never been married,
> the question: Have you stopped beating your wife?
> Is an incorrect polar question because neither yes nor
> no is a correct answer.

But That isn't what the halting problem is.

>
> All polar questions (including incorrect polar questions)
> have exactly one answer from the following:
> 1) No
> 2) Yes
> 3) Neither // Only applies to incorrect polar questions
> Copyright Olcott 2015
> https://groups.google.com/g/sci.lang/c/AO5Vlupeelo/m/nxJy7N2vULwJ
>

And the correct answer to the Halting Problem is always Yes or No.

The Polar question that yoyu are mistakenly replacing the halting
problem questiono is what answer should H give, that is NOT the actual
question.

>
> In the same way that ZFC eliminated Russell's Paradox by redefining set
> theory to eliminate a key element of Russell's Paradox a set as a member
> of itself, the Halting Problem is redefined eliminating its pathology.
>
> The halting problem is the problem of defining a machine that correctly
> determines from a description of an arbitrary computer program and an
> input, whether or not its specified input pair would terminate normally
> by reaching it own final state on the basis of its correct simulation of
> this input pair.


Click here to read the complete article
Re: HH(PP,PP) correctly determines that its input never halts

<pKiAL.355628$MVg8.306977@fx12.iad>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10383&group=comp.ai.philosophy#10383

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx12.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.6.1
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <082AL.308017$Tcw8.209243@fx10.iad>
<tqrlbh$o3id$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tqrlbh$o3id$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 79
Message-ID: <pKiAL.355628$MVg8.306977@fx12.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 25 Jan 2023 18:15:33 -0500
X-Received-Bytes: 3861
 by: Richard Damon - Wed, 25 Jan 2023 23:15 UTC

On 1/25/23 11:28 AM, olcott wrote:
> On 1/24/2023 10:22 PM, Richard Damon wrote:
>> On 1/24/23 10:51 PM, olcott wrote:
>>> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>>>
>>>> Since the direct eecution of the machine language of PP(PP) will
>>>> Halt, the correct simulation of it must match.
>>>>
>>>
>>> That is merely a provably false assumption.
>>
>> Simple question for a counter.
>>
>> You seem to be saying that when PP calls HH(PP,PP) then HH will not
>> return, but when main call HH(PP,PP) it will
>>
>
> Whenever a simulated P calls a simulated H, this simulated P cannot
> possibly reach its final state.

Why, a proper simulation of the H will see that it aborts its processing
are return non-halting.

H can't show that because H can't correctly simulate itself.

This is basically the same issue as a statement trying to assert about
its own truth.

>
> Whenever a directly executed P calls a directly executed H, this
> directly executed P reaches its final state.

Which shows that the simulation done by H is incorrect.

>
>>
>> Please show the first assembly instruction of these two exectution
>> paths that differ in operation.
>>
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
> On page 5 there are three calls to H(P,P) from P(P):
> (1) The first one from directly executed P(P) eventually returns to
>     12f7.
>
> (2) The second one causes the simulated P(P) to be simulated again.
>
> (3) The third one from the second simulated P(P) would cause the
>     simulated P(P) to be simulated a third time is aborted.
>

And why do they behave "Differently"?

The CORRECT behavior, is what happens when main call P(P) which calls
H(P,P) which will go into the code of HH and eventally returs to
000012F7 and PP thus halts, This is your (1)

In (2) Why does the call the H(P,P) immediately cause P(P) to be
simulated again. That is NOT what happened in (1), so H is INCORRECT in
this simulation.

In (3) your describe behavior is again NOT what happened ib (1), so is
also incorrect. Yes, it is consistet which H's error of thinking that a
call to H(P,P) just immediately doing a call to P(P), but that isn't
what it actually dooes.

Thus NONE of H's simulation of calls to H(P,P) were correct, which is
why H gets the worn answer.

So you haven't actually shown what instruction CORRECTLY
executed/simulated differed, you have show that H doesn't correctly
simulate its input.

Remember, the code of H that P calls is part of the program P that H
needs to analyse/simulate.

YOU HAVE SHOWN YOU HAVE FAILED.

Re: HH(PP,PP) correctly determines that its input never halts

<tqse0s$s42e$1@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10384&group=comp.ai.philosophy#10384

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Date: Wed, 25 Jan 2023 17:29:31 -0600
Organization: A noiseless patient Spider
Lines: 142
Message-ID: <tqse0s$s42e$1@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
<tqqdpl$hcci$1@dont-email.me> <BE8AL.276573$gGD7.12810@fx11.iad>
<tqrmnb$ob0i$1@dont-email.me> <mKiAL.355627$MVg8.158433@fx12.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 25 Jan 2023 23:29:32 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="0fda4ea1a7e80c67f7531f48811f9cf1";
logging-data="921678"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+6Mefq4dphH1fQrKEZqoLg"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.6.1
Cancel-Lock: sha1:KOMluEUttKao9C900kccUP3Puh4=
In-Reply-To: <mKiAL.355627$MVg8.158433@fx12.iad>
Content-Language: en-US
 by: olcott - Wed, 25 Jan 2023 23:29 UTC

On 1/25/2023 5:15 PM, Richard Damon wrote:
> On 1/25/23 11:51 AM, olcott wrote:
>> On 1/25/2023 5:46 AM, Richard Damon wrote:
>>> On 1/25/23 12:13 AM, olcott wrote:
>>>> On 1/24/2023 10:09 PM, Richard Damon wrote:
>>>>> On 1/24/23 10:51 PM, olcott wrote:
>>>>>> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>>>>>> On 1/24/23 10:10 PM, olcott wrote:
>>>>>>>> On 1/24/2023 8:03 PM, Richard Damon wrote:
>>>>>>>>> On 1/24/23 7:26 PM, olcott wrote:
>>>>>>>>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>>>>> program and an
>>>>>>>>>>>> input, whether the program will finish running, or continue
>>>>>>>>>>>> to run
>>>>>>>>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>
>>>>>>>>>>>> This definition of the halting problem measures correctness
>>>>>>>>>>>> in a non-
>>>>>>>>>>>> pathological way, thus in the same way that ZFC (redefined
>>>>>>>>>>>> set theory
>>>>>>>>>>>> and) eliminated Russell's Paradox the previously
>>>>>>>>>>>> "impossible" input
>>>>>>>>>>>> ceases to be impossible.
>>>>>>>>>>>>
>>>>>>>>>>>> In computability theory, the halting problem is the problem
>>>>>>>>>>>> of defining
>>>>>>>>>>>> a machine that correctly determines from a description of an
>>>>>>>>>>>> arbitrary
>>>>>>>>>>>> computer program and an input, whether or not its specified
>>>>>>>>>>>> input pair
>>>>>>>>>>>> would terminate normally by reaching it own final state.
>>>>>>>>>>>
>>>>>>>>>>> Right, the Decider must decide if the actual running of the
>>>>>>>>>>> program described by the input would halt when given the
>>>>>>>>>>> input that is the rest of that input.
>>>>>>>>>>>
>>>>>>>>>>> It is NOT asking if the
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The conventional proofs do not actually show that such a
>>>>>>>>>>>> machine cannot
>>>>>>>>>>>> be defined. HH(PP, PP) does correctly determine that its
>>>>>>>>>>>> correctly
>>>>>>>>>>>> simulated input cannot possibly reach the final state of PP and
>>>>>>>>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>>>>>>>>
>>>>>>>>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>>>>>>>>
>>>>>>>>>>>> If the simulation is incorrect then there must a line of the
>>>>>>>>>>>> simulation
>>>>>>>>>>>> that behaves differently than what its corresponding line of
>>>>>>>>>>>> machine-
>>>>>>>>>>>> code specifies.
>>>>>>>>>>>
>>>>>>>>>>> No, it is incorrect because it is incomplete.
>>>>>>>>>>>
>>>>>>>>>>> You are just usong the INCORRECT definition of "Correct", and
>>>>>>>>>>> since you have been told this in the past, it just shows that
>>>>>>>>>>> you are a LIAR about this fact.
>>>>>>>>>>>
>>>>>>>>>>> "Correct Simulation" is defined as a simulation that exactly
>>>>>>>>>>> matches the actual behavior of the machine the input describes.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It turns out that is incorrect. The ultimate measure of a correct
>>>>>>>>>> simulation is whether or not the simulated input exactly
>>>>>>>>>> matches the
>>>>>>>>>> behavior specified by its machine code.
>>>>>>>>>
>>>>>>>>> Nope, Sourcd for that claim.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Counter-examples cannot possibly exist.
>>>>>>>> Try and show any correct simulation where the simulator does not
>>>>>>>> simulate what the machine language specifies.
>>>>>>>
>>>>>>> This is the counter example.
>>>>>>>
>>>>>>> Since the direct eecution of the machine language of PP(PP) will
>>>>>>> Halt, the correct simulation of it must match.
>>>>>>>
>>>>>>
>>>>>> That is merely a provably false assumption.
>>>>>
>>>>> Then do so.
>>>>>
>>>>> Remember, your HH has been admitted to return 0 from HH(PP,PP), and
>>>>> to be a computation, it must do the same to EVERY call.
>>>>>
>>>>> YOU have posted the execution trace of the direct execution of the
>>>>> equivalent to PP, which shows it halts.
>>>>>
>>>>
>>>> You can see on pages 5-6 that PP correctly simulated by HH cannot
>>>> possibly reach it own final state.
>>>
>>> But that isn't the questipon, since that question, like the Liar's
>>> paradox has no answer.
>>>
>> That makes the Halting Problem ill-defined:
>
> No, your RESTATEMENT is ill-defined. The behavior of P is well defined
> given a proper definition of H
>
> H(P,P) can do one of 4 things, and can't do anything else.
>
> 1) H(P,P) can return 0, in which case P(P) will halt, and H is shown to
> be wrong. This is what you claim your H does when directly called.
>
> 2) H(P,P) can retrun 1, in which case, P(P) will go into an infinite
> loop, and H is shown to be wrong.
>
> 3) H(P,P) can just dies and halt and not return an answer, in which case
> H fails to be the needed halt decider, and P(P) will be halting.
>
> 4) H(P,P) can get stuck in an infinte loop, and never return an answer,
> in which case H fails to be the needed halt decider, and P(P) will be
> non-halting. This is what you seem to claim is what H does when
> simulated inside P.
>
>>
>> In the study of problem solving, any problem in which the initial
>> state or starting position, the allowable operations, and the goal
>> state are clearly specified, *and a unique solution can be shown to
>> exist*
>
> Right, and given an actual definition of the complete algorithm of H
> (and 'Get the right answer' is NOT an complete algorithm) there is a
> precise correct answer to the problem.
>
> Unfortunately of H, H can never give that answer.

Thus making the halting problem ill-defined.

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

Re: HH(PP,PP) correctly determines that its input never halts

<tqsf9v$s42e$2@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10385&group=comp.ai.philosophy#10385

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Date: Wed, 25 Jan 2023 17:51:27 -0600
Organization: A noiseless patient Spider
Lines: 155
Message-ID: <tqsf9v$s42e$2@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
<tqqdpl$hcci$1@dont-email.me> <BE8AL.276573$gGD7.12810@fx11.iad>
<tqrmnb$ob0i$1@dont-email.me> <mKiAL.355627$MVg8.158433@fx12.iad>
<tqse0s$s42e$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 25 Jan 2023 23:51:27 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="0fda4ea1a7e80c67f7531f48811f9cf1";
logging-data="921678"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+SeAtM4JL5UHLeLrtySHhP"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.6.1
Cancel-Lock: sha1:+W3+Orx84QGrsw8Q198+iueU9XE=
In-Reply-To: <tqse0s$s42e$1@dont-email.me>
Content-Language: en-US
 by: olcott - Wed, 25 Jan 2023 23:51 UTC

On 1/25/2023 5:29 PM, olcott wrote:
> On 1/25/2023 5:15 PM, Richard Damon wrote:
>> On 1/25/23 11:51 AM, olcott wrote:
>>> On 1/25/2023 5:46 AM, Richard Damon wrote:
>>>> On 1/25/23 12:13 AM, olcott wrote:
>>>>> On 1/24/2023 10:09 PM, Richard Damon wrote:
>>>>>> On 1/24/23 10:51 PM, olcott wrote:
>>>>>>> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>>>>>>> On 1/24/23 10:10 PM, olcott wrote:
>>>>>>>>> On 1/24/2023 8:03 PM, Richard Damon wrote:
>>>>>>>>>> On 1/24/23 7:26 PM, olcott wrote:
>>>>>>>>>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>>>>>> program and an
>>>>>>>>>>>>> input, whether the program will finish running, or continue
>>>>>>>>>>>>> to run
>>>>>>>>>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>
>>>>>>>>>>>>> This definition of the halting problem measures correctness
>>>>>>>>>>>>> in a non-
>>>>>>>>>>>>> pathological way, thus in the same way that ZFC (redefined
>>>>>>>>>>>>> set theory
>>>>>>>>>>>>> and) eliminated Russell's Paradox the previously
>>>>>>>>>>>>> "impossible" input
>>>>>>>>>>>>> ceases to be impossible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In computability theory, the halting problem is the problem
>>>>>>>>>>>>> of defining
>>>>>>>>>>>>> a machine that correctly determines from a description of
>>>>>>>>>>>>> an arbitrary
>>>>>>>>>>>>> computer program and an input, whether or not its specified
>>>>>>>>>>>>> input pair
>>>>>>>>>>>>> would terminate normally by reaching it own final state.
>>>>>>>>>>>>
>>>>>>>>>>>> Right, the Decider must decide if the actual running of the
>>>>>>>>>>>> program described by the input would halt when given the
>>>>>>>>>>>> input that is the rest of that input.
>>>>>>>>>>>>
>>>>>>>>>>>> It is NOT asking if the
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The conventional proofs do not actually show that such a
>>>>>>>>>>>>> machine cannot
>>>>>>>>>>>>> be defined. HH(PP, PP) does correctly determine that its
>>>>>>>>>>>>> correctly
>>>>>>>>>>>>> simulated input cannot possibly reach the final state of PP
>>>>>>>>>>>>> and
>>>>>>>>>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the simulation is incorrect then there must a line of
>>>>>>>>>>>>> the simulation
>>>>>>>>>>>>> that behaves differently than what its corresponding line
>>>>>>>>>>>>> of machine-
>>>>>>>>>>>>> code specifies.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it is incorrect because it is incomplete.
>>>>>>>>>>>>
>>>>>>>>>>>> You are just usong the INCORRECT definition of "Correct",
>>>>>>>>>>>> and since you have been told this in the past, it just shows
>>>>>>>>>>>> that you are a LIAR about this fact.
>>>>>>>>>>>>
>>>>>>>>>>>> "Correct Simulation" is defined as a simulation that exactly
>>>>>>>>>>>> matches the actual behavior of the machine the input describes.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It turns out that is incorrect. The ultimate measure of a
>>>>>>>>>>> correct
>>>>>>>>>>> simulation is whether or not the simulated input exactly
>>>>>>>>>>> matches the
>>>>>>>>>>> behavior specified by its machine code.
>>>>>>>>>>
>>>>>>>>>> Nope, Sourcd for that claim.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Counter-examples cannot possibly exist.
>>>>>>>>> Try and show any correct simulation where the simulator does
>>>>>>>>> not simulate what the machine language specifies.
>>>>>>>>
>>>>>>>> This is the counter example.
>>>>>>>>
>>>>>>>> Since the direct eecution of the machine language of PP(PP) will
>>>>>>>> Halt, the correct simulation of it must match.
>>>>>>>>
>>>>>>>
>>>>>>> That is merely a provably false assumption.
>>>>>>
>>>>>> Then do so.
>>>>>>
>>>>>> Remember, your HH has been admitted to return 0 from HH(PP,PP),
>>>>>> and to be a computation, it must do the same to EVERY call.
>>>>>>
>>>>>> YOU have posted the execution trace of the direct execution of the
>>>>>> equivalent to PP, which shows it halts.
>>>>>>
>>>>>
>>>>> You can see on pages 5-6 that PP correctly simulated by HH cannot
>>>>> possibly reach it own final state.
>>>>
>>>> But that isn't the questipon, since that question, like the Liar's
>>>> paradox has no answer.
>>>>
>>> That makes the Halting Problem ill-defined:
>>
>> No, your RESTATEMENT is ill-defined. The behavior of P is well defined
>> given a proper definition of H
>>
>> H(P,P) can do one of 4 things, and can't do anything else.
>>
>> 1) H(P,P) can return 0, in which case P(P) will halt, and H is shown
>> to be wrong. This is what you claim your H does when directly called.
>>
>> 2) H(P,P) can retrun 1, in which case, P(P) will go into an infinite
>> loop, and H is shown to be wrong.
>>
>> 3) H(P,P) can just dies and halt and not return an answer, in which
>> case H fails to be the needed halt decider, and P(P) will be halting.
>>
>> 4) H(P,P) can get stuck in an infinte loop, and never return an
>> answer, in which case H fails to be the needed halt decider, and P(P)
>> will be non-halting. This is what you seem to claim is what H does
>> when simulated inside P.
>>
>>>
>>> In the study of problem solving, any problem in which the initial
>>> state or starting position, the allowable operations, and the goal
>>> state are clearly specified, *and a unique solution can be shown to
>>> exist*
>>
>> Right, and given an actual definition of the complete algorithm of H
>> (and 'Get the right answer' is NOT an complete algorithm) there is a
>> precise correct answer to the problem.
>>
>> Unfortunately of H, H can never give that answer.
>
> Thus making the halting problem ill-defined.

No machine can possibly be defined that divides all pairs of finite
strings into those that represent machines would halt on their input
when directly executed and those that do not in the same way and for the
same reason that there is no barber that shaves all and only those that
do not shave themselves. ZFC eliminated this problem by declaring it is
erroneous.


Click here to read the complete article
Re: HH(PP,PP) correctly determines that its input never halts

<tqsg4l$sem7$1@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10386&group=comp.ai.philosophy#10386

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pyt...@invalid.org (Python)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Date: Thu, 26 Jan 2023 01:05:41 +0100
Organization: A noiseless patient Spider
Lines: 21
Message-ID: <tqsg4l$sem7$1@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
<tqqdpl$hcci$1@dont-email.me> <BE8AL.276573$gGD7.12810@fx11.iad>
<tqrmnb$ob0i$1@dont-email.me> <mKiAL.355627$MVg8.158433@fx12.iad>
<tqse0s$s42e$1@dont-email.me> <tqsf9v$s42e$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 26 Jan 2023 00:05:41 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="54900c0f4e391a463d5b45b1ba11a7f1";
logging-data="932551"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18df1gJYIuuifnYUHYy9f4E"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.3.3
Cancel-Lock: sha1:nH6LSla6ZuOdRx8N006ZCA0VK8Y=
Content-Language: en-US
In-Reply-To: <tqsf9v$s42e$2@dont-email.me>
 by: Python - Thu, 26 Jan 2023 00:05 UTC

Peter Olcott wrote:
....
> No machine can possibly be defined that divides all pairs of finite
> strings into those that represent machines would halt on their input
> when directly executed and those that do not

So at least you admit that there no program can be written that
is an halt decider! It took time for you to abandon your delusions!

All these years pretending you have written one... You should feel
sad, right? You shouldn't, at end you've admitted the obvious
truth.

Note that a function that is an halt decider is perfectly well
defined. So no, the "problem" is NOT ill-defined (whatever that
means).

Re: HH(PP,PP) correctly determines that its input never halts

<PJjAL.437312$iS99.256703@fx16.iad>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10387&group=comp.ai.philosophy#10387

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.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:102.0)
Gecko/20100101 Thunderbird/102.6.1
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
<tqqdpl$hcci$1@dont-email.me> <BE8AL.276573$gGD7.12810@fx11.iad>
<tqrmnb$ob0i$1@dont-email.me> <mKiAL.355627$MVg8.158433@fx12.iad>
<tqse0s$s42e$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tqse0s$s42e$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 156
Message-ID: <PJjAL.437312$iS99.256703@fx16.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 25 Jan 2023 19:23:10 -0500
X-Received-Bytes: 7726
 by: Richard Damon - Thu, 26 Jan 2023 00:23 UTC

On 1/25/23 6:29 PM, olcott wrote:
> On 1/25/2023 5:15 PM, Richard Damon wrote:
>> On 1/25/23 11:51 AM, olcott wrote:
>>> On 1/25/2023 5:46 AM, Richard Damon wrote:
>>>> On 1/25/23 12:13 AM, olcott wrote:
>>>>> On 1/24/2023 10:09 PM, Richard Damon wrote:
>>>>>> On 1/24/23 10:51 PM, olcott wrote:
>>>>>>> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>>>>>>> On 1/24/23 10:10 PM, olcott wrote:
>>>>>>>>> On 1/24/2023 8:03 PM, Richard Damon wrote:
>>>>>>>>>> On 1/24/23 7:26 PM, olcott wrote:
>>>>>>>>>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>>>>>> program and an
>>>>>>>>>>>>> input, whether the program will finish running, or continue
>>>>>>>>>>>>> to run
>>>>>>>>>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>
>>>>>>>>>>>>> This definition of the halting problem measures correctness
>>>>>>>>>>>>> in a non-
>>>>>>>>>>>>> pathological way, thus in the same way that ZFC (redefined
>>>>>>>>>>>>> set theory
>>>>>>>>>>>>> and) eliminated Russell's Paradox the previously
>>>>>>>>>>>>> "impossible" input
>>>>>>>>>>>>> ceases to be impossible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In computability theory, the halting problem is the problem
>>>>>>>>>>>>> of defining
>>>>>>>>>>>>> a machine that correctly determines from a description of
>>>>>>>>>>>>> an arbitrary
>>>>>>>>>>>>> computer program and an input, whether or not its specified
>>>>>>>>>>>>> input pair
>>>>>>>>>>>>> would terminate normally by reaching it own final state.
>>>>>>>>>>>>
>>>>>>>>>>>> Right, the Decider must decide if the actual running of the
>>>>>>>>>>>> program described by the input would halt when given the
>>>>>>>>>>>> input that is the rest of that input.
>>>>>>>>>>>>
>>>>>>>>>>>> It is NOT asking if the
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The conventional proofs do not actually show that such a
>>>>>>>>>>>>> machine cannot
>>>>>>>>>>>>> be defined. HH(PP, PP) does correctly determine that its
>>>>>>>>>>>>> correctly
>>>>>>>>>>>>> simulated input cannot possibly reach the final state of PP
>>>>>>>>>>>>> and
>>>>>>>>>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the simulation is incorrect then there must a line of
>>>>>>>>>>>>> the simulation
>>>>>>>>>>>>> that behaves differently than what its corresponding line
>>>>>>>>>>>>> of machine-
>>>>>>>>>>>>> code specifies.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it is incorrect because it is incomplete.
>>>>>>>>>>>>
>>>>>>>>>>>> You are just usong the INCORRECT definition of "Correct",
>>>>>>>>>>>> and since you have been told this in the past, it just shows
>>>>>>>>>>>> that you are a LIAR about this fact.
>>>>>>>>>>>>
>>>>>>>>>>>> "Correct Simulation" is defined as a simulation that exactly
>>>>>>>>>>>> matches the actual behavior of the machine the input describes.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It turns out that is incorrect. The ultimate measure of a
>>>>>>>>>>> correct
>>>>>>>>>>> simulation is whether or not the simulated input exactly
>>>>>>>>>>> matches the
>>>>>>>>>>> behavior specified by its machine code.
>>>>>>>>>>
>>>>>>>>>> Nope, Sourcd for that claim.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Counter-examples cannot possibly exist.
>>>>>>>>> Try and show any correct simulation where the simulator does
>>>>>>>>> not simulate what the machine language specifies.
>>>>>>>>
>>>>>>>> This is the counter example.
>>>>>>>>
>>>>>>>> Since the direct eecution of the machine language of PP(PP) will
>>>>>>>> Halt, the correct simulation of it must match.
>>>>>>>>
>>>>>>>
>>>>>>> That is merely a provably false assumption.
>>>>>>
>>>>>> Then do so.
>>>>>>
>>>>>> Remember, your HH has been admitted to return 0 from HH(PP,PP),
>>>>>> and to be a computation, it must do the same to EVERY call.
>>>>>>
>>>>>> YOU have posted the execution trace of the direct execution of the
>>>>>> equivalent to PP, which shows it halts.
>>>>>>
>>>>>
>>>>> You can see on pages 5-6 that PP correctly simulated by HH cannot
>>>>> possibly reach it own final state.
>>>>
>>>> But that isn't the questipon, since that question, like the Liar's
>>>> paradox has no answer.
>>>>
>>> That makes the Halting Problem ill-defined:
>>
>> No, your RESTATEMENT is ill-defined. The behavior of P is well defined
>> given a proper definition of H
>>
>> H(P,P) can do one of 4 things, and can't do anything else.
>>
>> 1) H(P,P) can return 0, in which case P(P) will halt, and H is shown
>> to be wrong. This is what you claim your H does when directly called.
>>
>> 2) H(P,P) can retrun 1, in which case, P(P) will go into an infinite
>> loop, and H is shown to be wrong.
>>
>> 3) H(P,P) can just dies and halt and not return an answer, in which
>> case H fails to be the needed halt decider, and P(P) will be halting.
>>
>> 4) H(P,P) can get stuck in an infinte loop, and never return an
>> answer, in which case H fails to be the needed halt decider, and P(P)
>> will be non-halting. This is what you seem to claim is what H does
>> when simulated inside P.
>>
>>>
>>> In the study of problem solving, any problem in which the initial
>>> state or starting position, the allowable operations, and the goal
>>> state are clearly specified, *and a unique solution can be shown to
>>> exist*
>>
>> Right, and given an actual definition of the complete algorithm of H
>> (and 'Get the right answer' is NOT an complete algorithm) there is a
>> precise correct answer to the problem.
>>
>> Unfortunately of H, H can never give that answer.
>
> Thus making the halting problem ill-defined.
>
>


Click here to read the complete article
Re: HH(PP,PP) correctly determines that its input never halts

<1KjAL.437313$iS99.97366@fx16.iad>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10388&group=comp.ai.philosophy#10388

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx16.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.6.1
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
<tqqdpl$hcci$1@dont-email.me> <BE8AL.276573$gGD7.12810@fx11.iad>
<tqrmnb$ob0i$1@dont-email.me> <mKiAL.355627$MVg8.158433@fx12.iad>
<tqse0s$s42e$1@dont-email.me> <tqsf9v$s42e$2@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tqsf9v$s42e$2@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 166
Message-ID: <1KjAL.437313$iS99.97366@fx16.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 25 Jan 2023 19:23:25 -0500
X-Received-Bytes: 8354
 by: Richard Damon - Thu, 26 Jan 2023 00:23 UTC

On 1/25/23 6:51 PM, olcott wrote:
> On 1/25/2023 5:29 PM, olcott wrote:
>> On 1/25/2023 5:15 PM, Richard Damon wrote:
>>> On 1/25/23 11:51 AM, olcott wrote:
>>>> On 1/25/2023 5:46 AM, Richard Damon wrote:
>>>>> On 1/25/23 12:13 AM, olcott wrote:
>>>>>> On 1/24/2023 10:09 PM, Richard Damon wrote:
>>>>>>> On 1/24/23 10:51 PM, olcott wrote:
>>>>>>>> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>>>>>>>> On 1/24/23 10:10 PM, olcott wrote:
>>>>>>>>>> On 1/24/2023 8:03 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/24/23 7:26 PM, olcott wrote:
>>>>>>>>>>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>>>>>>>>>>> In computability theory, the halting problem is the
>>>>>>>>>>>>>> problem of
>>>>>>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>>>>>>> program and an
>>>>>>>>>>>>>> input, whether the program will finish running, or
>>>>>>>>>>>>>> continue to run
>>>>>>>>>>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This definition of the halting problem measures
>>>>>>>>>>>>>> correctness in a non-
>>>>>>>>>>>>>> pathological way, thus in the same way that ZFC (redefined
>>>>>>>>>>>>>> set theory
>>>>>>>>>>>>>> and) eliminated Russell's Paradox the previously
>>>>>>>>>>>>>> "impossible" input
>>>>>>>>>>>>>> ceases to be impossible.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In computability theory, the halting problem is the
>>>>>>>>>>>>>> problem of defining
>>>>>>>>>>>>>> a machine that correctly determines from a description of
>>>>>>>>>>>>>> an arbitrary
>>>>>>>>>>>>>> computer program and an input, whether or not its
>>>>>>>>>>>>>> specified input pair
>>>>>>>>>>>>>> would terminate normally by reaching it own final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, the Decider must decide if the actual running of the
>>>>>>>>>>>>> program described by the input would halt when given the
>>>>>>>>>>>>> input that is the rest of that input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is NOT asking if the
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The conventional proofs do not actually show that such a
>>>>>>>>>>>>>> machine cannot
>>>>>>>>>>>>>> be defined. HH(PP, PP) does correctly determine that its
>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>> simulated input cannot possibly reach the final state of
>>>>>>>>>>>>>> PP and
>>>>>>>>>>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If the simulation is incorrect then there must a line of
>>>>>>>>>>>>>> the simulation
>>>>>>>>>>>>>> that behaves differently than what its corresponding line
>>>>>>>>>>>>>> of machine-
>>>>>>>>>>>>>> code specifies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, it is incorrect because it is incomplete.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are just usong the INCORRECT definition of "Correct",
>>>>>>>>>>>>> and since you have been told this in the past, it just
>>>>>>>>>>>>> shows that you are a LIAR about this fact.
>>>>>>>>>>>>>
>>>>>>>>>>>>> "Correct Simulation" is defined as a simulation that
>>>>>>>>>>>>> exactly matches the actual behavior of the machine the
>>>>>>>>>>>>> input describes.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It turns out that is incorrect. The ultimate measure of a
>>>>>>>>>>>> correct
>>>>>>>>>>>> simulation is whether or not the simulated input exactly
>>>>>>>>>>>> matches the
>>>>>>>>>>>> behavior specified by its machine code.
>>>>>>>>>>>
>>>>>>>>>>> Nope, Sourcd for that claim.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Counter-examples cannot possibly exist.
>>>>>>>>>> Try and show any correct simulation where the simulator does
>>>>>>>>>> not simulate what the machine language specifies.
>>>>>>>>>
>>>>>>>>> This is the counter example.
>>>>>>>>>
>>>>>>>>> Since the direct eecution of the machine language of PP(PP)
>>>>>>>>> will Halt, the correct simulation of it must match.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That is merely a provably false assumption.
>>>>>>>
>>>>>>> Then do so.
>>>>>>>
>>>>>>> Remember, your HH has been admitted to return 0 from HH(PP,PP),
>>>>>>> and to be a computation, it must do the same to EVERY call.
>>>>>>>
>>>>>>> YOU have posted the execution trace of the direct execution of
>>>>>>> the equivalent to PP, which shows it halts.
>>>>>>>
>>>>>>
>>>>>> You can see on pages 5-6 that PP correctly simulated by HH cannot
>>>>>> possibly reach it own final state.
>>>>>
>>>>> But that isn't the questipon, since that question, like the Liar's
>>>>> paradox has no answer.
>>>>>
>>>> That makes the Halting Problem ill-defined:
>>>
>>> No, your RESTATEMENT is ill-defined. The behavior of P is well
>>> defined given a proper definition of H
>>>
>>> H(P,P) can do one of 4 things, and can't do anything else.
>>>
>>> 1) H(P,P) can return 0, in which case P(P) will halt, and H is shown
>>> to be wrong. This is what you claim your H does when directly called.
>>>
>>> 2) H(P,P) can retrun 1, in which case, P(P) will go into an infinite
>>> loop, and H is shown to be wrong.
>>>
>>> 3) H(P,P) can just dies and halt and not return an answer, in which
>>> case H fails to be the needed halt decider, and P(P) will be halting.
>>>
>>> 4) H(P,P) can get stuck in an infinte loop, and never return an
>>> answer, in which case H fails to be the needed halt decider, and P(P)
>>> will be non-halting. This is what you seem to claim is what H does
>>> when simulated inside P.
>>>
>>>>
>>>> In the study of problem solving, any problem in which the initial
>>>> state or starting position, the allowable operations, and the goal
>>>> state are clearly specified, *and a unique solution can be shown to
>>>> exist*
>>>
>>> Right, and given an actual definition of the complete algorithm of H
>>> (and 'Get the right answer' is NOT an complete algorithm) there is a
>>> precise correct answer to the problem.
>>>
>>> Unfortunately of H, H can never give that answer.
>>
>> Thus making the halting problem ill-defined.
>
> No machine can possibly be defined that divides all pairs of finite
> strings into those that represent machines would halt on their input
> when directly executed and those that do not in the same way and for the
> same reason that there is no barber that shaves all and only those that
> do not shave themselves. ZFC eliminated this problem by declaring it is
> erroneous.
>


Click here to read the complete article
Re: HH(PP,PP) correctly determines that its input never halts

<lTjAL.46530$4jN7.9315@fx02.iad>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10389&group=comp.ai.philosophy#10389

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx02.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.6.1
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
<tqqdpl$hcci$1@dont-email.me> <BE8AL.276573$gGD7.12810@fx11.iad>
<tqrmnb$ob0i$1@dont-email.me> <mKiAL.355627$MVg8.158433@fx12.iad>
<tqse0s$s42e$1@dont-email.me> <tqsf9v$s42e$2@dont-email.me>
<1KjAL.437313$iS99.97366@fx16.iad>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <1KjAL.437313$iS99.97366@fx16.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 184
Message-ID: <lTjAL.46530$4jN7.9315@fx02.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 25 Jan 2023 19:33:21 -0500
X-Received-Bytes: 9215
 by: Richard Damon - Thu, 26 Jan 2023 00:33 UTC

On 1/25/23 7:23 PM, Richard Damon wrote:
> On 1/25/23 6:51 PM, olcott wrote:
>> On 1/25/2023 5:29 PM, olcott wrote:
>>> On 1/25/2023 5:15 PM, Richard Damon wrote:
>>>> On 1/25/23 11:51 AM, olcott wrote:
>>>>> On 1/25/2023 5:46 AM, Richard Damon wrote:
>>>>>> On 1/25/23 12:13 AM, olcott wrote:
>>>>>>> On 1/24/2023 10:09 PM, Richard Damon wrote:
>>>>>>>> On 1/24/23 10:51 PM, olcott wrote:
>>>>>>>>> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>>>>>>>>> On 1/24/23 10:10 PM, olcott wrote:
>>>>>>>>>>> On 1/24/2023 8:03 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/24/23 7:26 PM, olcott wrote:
>>>>>>>>>>>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>>>>>>>>>>>> In computability theory, the halting problem is the
>>>>>>>>>>>>>>> problem of
>>>>>>>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>>>>>>>> program and an
>>>>>>>>>>>>>>> input, whether the program will finish running, or
>>>>>>>>>>>>>>> continue to run
>>>>>>>>>>>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This definition of the halting problem measures
>>>>>>>>>>>>>>> correctness in a non-
>>>>>>>>>>>>>>> pathological way, thus in the same way that ZFC
>>>>>>>>>>>>>>> (redefined set theory
>>>>>>>>>>>>>>> and) eliminated Russell's Paradox the previously
>>>>>>>>>>>>>>> "impossible" input
>>>>>>>>>>>>>>> ceases to be impossible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In computability theory, the halting problem is the
>>>>>>>>>>>>>>> problem of defining
>>>>>>>>>>>>>>> a machine that correctly determines from a description of
>>>>>>>>>>>>>>> an arbitrary
>>>>>>>>>>>>>>> computer program and an input, whether or not its
>>>>>>>>>>>>>>> specified input pair
>>>>>>>>>>>>>>> would terminate normally by reaching it own final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, the Decider must decide if the actual running of
>>>>>>>>>>>>>> the program described by the input would halt when given
>>>>>>>>>>>>>> the input that is the rest of that input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is NOT asking if the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The conventional proofs do not actually show that such a
>>>>>>>>>>>>>>> machine cannot
>>>>>>>>>>>>>>> be defined. HH(PP, PP) does correctly determine that its
>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>> simulated input cannot possibly reach the final state of
>>>>>>>>>>>>>>> PP and
>>>>>>>>>>>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If the simulation is incorrect then there must a line of
>>>>>>>>>>>>>>> the simulation
>>>>>>>>>>>>>>> that behaves differently than what its corresponding line
>>>>>>>>>>>>>>> of machine-
>>>>>>>>>>>>>>> code specifies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, it is incorrect because it is incomplete.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are just usong the INCORRECT definition of "Correct",
>>>>>>>>>>>>>> and since you have been told this in the past, it just
>>>>>>>>>>>>>> shows that you are a LIAR about this fact.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "Correct Simulation" is defined as a simulation that
>>>>>>>>>>>>>> exactly matches the actual behavior of the machine the
>>>>>>>>>>>>>> input describes.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It turns out that is incorrect. The ultimate measure of a
>>>>>>>>>>>>> correct
>>>>>>>>>>>>> simulation is whether or not the simulated input exactly
>>>>>>>>>>>>> matches the
>>>>>>>>>>>>> behavior specified by its machine code.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, Sourcd for that claim.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Counter-examples cannot possibly exist.
>>>>>>>>>>> Try and show any correct simulation where the simulator does
>>>>>>>>>>> not simulate what the machine language specifies.
>>>>>>>>>>
>>>>>>>>>> This is the counter example.
>>>>>>>>>>
>>>>>>>>>> Since the direct eecution of the machine language of PP(PP)
>>>>>>>>>> will Halt, the correct simulation of it must match.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That is merely a provably false assumption.
>>>>>>>>
>>>>>>>> Then do so.
>>>>>>>>
>>>>>>>> Remember, your HH has been admitted to return 0 from HH(PP,PP),
>>>>>>>> and to be a computation, it must do the same to EVERY call.
>>>>>>>>
>>>>>>>> YOU have posted the execution trace of the direct execution of
>>>>>>>> the equivalent to PP, which shows it halts.
>>>>>>>>
>>>>>>>
>>>>>>> You can see on pages 5-6 that PP correctly simulated by HH cannot
>>>>>>> possibly reach it own final state.
>>>>>>
>>>>>> But that isn't the questipon, since that question, like the Liar's
>>>>>> paradox has no answer.
>>>>>>
>>>>> That makes the Halting Problem ill-defined:
>>>>
>>>> No, your RESTATEMENT is ill-defined. The behavior of P is well
>>>> defined given a proper definition of H
>>>>
>>>> H(P,P) can do one of 4 things, and can't do anything else.
>>>>
>>>> 1) H(P,P) can return 0, in which case P(P) will halt, and H is shown
>>>> to be wrong. This is what you claim your H does when directly called.
>>>>
>>>> 2) H(P,P) can retrun 1, in which case, P(P) will go into an infinite
>>>> loop, and H is shown to be wrong.
>>>>
>>>> 3) H(P,P) can just dies and halt and not return an answer, in which
>>>> case H fails to be the needed halt decider, and P(P) will be halting.
>>>>
>>>> 4) H(P,P) can get stuck in an infinte loop, and never return an
>>>> answer, in which case H fails to be the needed halt decider, and
>>>> P(P) will be non-halting. This is what you seem to claim is what H
>>>> does when simulated inside P.
>>>>
>>>>>
>>>>> In the study of problem solving, any problem in which the initial
>>>>> state or starting position, the allowable operations, and the goal
>>>>> state are clearly specified, *and a unique solution can be shown to
>>>>> exist*
>>>>
>>>> Right, and given an actual definition of the complete algorithm of H
>>>> (and 'Get the right answer' is NOT an complete algorithm) there is a
>>>> precise correct answer to the problem.
>>>>
>>>> Unfortunately of H, H can never give that answer.
>>>
>>> Thus making the halting problem ill-defined.
>>
>> No machine can possibly be defined that divides all pairs of finite
>> strings into those that represent machines would halt on their input
>> when directly executed and those that do not in the same way and for the
>> same reason that there is no barber that shaves all and only those that
>> do not shave themselves. ZFC eliminated this problem by declaring it is
>> erroneous.
>>
>
> Right, which shows that the Haltng Theorm is CORRECT, that that the
> Halting Function is not computable.
>
> So, you agree with the Theorem that you have been arguing against for 2
> decades?
>
>> Every decision problem where
>> *a unique solution CANNOT be shown to exist*
>> is erroneous.
>>
>
> Nope, just shows that the problem is not computable.
>
> If you think uncompuatable problems are erroneous, then you can't handle
> all of mathematics.


Click here to read the complete article
Re: HH(PP,PP) correctly determines that its input never halts

<tqsi54$snb8$1@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10390&group=comp.ai.philosophy#10390

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Date: Wed, 25 Jan 2023 18:40:04 -0600
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <tqsi54$snb8$1@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
<tqqdpl$hcci$1@dont-email.me> <BE8AL.276573$gGD7.12810@fx11.iad>
<tqrmnb$ob0i$1@dont-email.me> <mKiAL.355627$MVg8.158433@fx12.iad>
<tqse0s$s42e$1@dont-email.me> <tqsf9v$s42e$2@dont-email.me>
<tqsg4l$sem7$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 26 Jan 2023 00:40:04 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="0fda4ea1a7e80c67f7531f48811f9cf1";
logging-data="941416"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+QwKuoiB3MbFqyFkR+7e1u"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.6.1
Cancel-Lock: sha1:pwRKm18QhfNM1EyoLsrRy3Cx5Vg=
In-Reply-To: <tqsg4l$sem7$1@dont-email.me>
Content-Language: en-US
 by: olcott - Thu, 26 Jan 2023 00:40 UTC

On 1/25/2023 6:05 PM, Python wrote:
> Peter Olcott wrote:
> ...
>> No machine can possibly be defined that divides all pairs of finite
>> strings into those that represent machines would halt on their input
>> when directly executed and those that do not
>
> So at least you admit that there no program can be written that
> is an halt decider! It took time for you to abandon your delusions!
>

*I didn't say that* There is a program H that can divide all of its
inputs into halting and non-halting on the basis of the behavior of this
input D correctly simulated by H.

In the study of problem solving, any problem in which the
initial state or starting position, the allowable operations,
and the goal state are clearly specified, and a unique
solution can be shown to exist.

*a unique solution can be shown to exist* or the problem itself is
ill-defined

https://www.oxfordreference.com/display/10.1093/oi/authority.20110803121717729;jsessionid=DAD4AA6FA046509B2E4564A52201A947

When a simulating halt decider H is only required to report on the the
behavior of D correctly simulated by H, then the problem has a solution.

> All these years pretending you have written one... You should feel
> sad, right? You shouldn't, at end you've admitted the obvious
> truth.
>
> Note that a function that is an halt decider is perfectly well
> defined. So no, the "problem" is NOT ill-defined (whatever that
> means).
>

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

Re: HH(PP,PP) correctly determines that its input never halts

<tqsid4$snb8$2@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10391&group=comp.ai.philosophy#10391

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Date: Wed, 25 Jan 2023 18:44:20 -0600
Organization: A noiseless patient Spider
Lines: 186
Message-ID: <tqsid4$snb8$2@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
<tqqdpl$hcci$1@dont-email.me> <BE8AL.276573$gGD7.12810@fx11.iad>
<tqrmnb$ob0i$1@dont-email.me> <mKiAL.355627$MVg8.158433@fx12.iad>
<tqse0s$s42e$1@dont-email.me> <tqsf9v$s42e$2@dont-email.me>
<1KjAL.437313$iS99.97366@fx16.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 26 Jan 2023 00:44:20 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="0fda4ea1a7e80c67f7531f48811f9cf1";
logging-data="941416"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18mqExvVGzu+b/DMviX4LEk"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.6.1
Cancel-Lock: sha1:ICa46/jMQUaeuO30f/HSQBPuTiM=
Content-Language: en-US
In-Reply-To: <1KjAL.437313$iS99.97366@fx16.iad>
 by: olcott - Thu, 26 Jan 2023 00:44 UTC

On 1/25/2023 6:23 PM, Richard Damon wrote:
> On 1/25/23 6:51 PM, olcott wrote:
>> On 1/25/2023 5:29 PM, olcott wrote:
>>> On 1/25/2023 5:15 PM, Richard Damon wrote:
>>>> On 1/25/23 11:51 AM, olcott wrote:
>>>>> On 1/25/2023 5:46 AM, Richard Damon wrote:
>>>>>> On 1/25/23 12:13 AM, olcott wrote:
>>>>>>> On 1/24/2023 10:09 PM, Richard Damon wrote:
>>>>>>>> On 1/24/23 10:51 PM, olcott wrote:
>>>>>>>>> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>>>>>>>>> On 1/24/23 10:10 PM, olcott wrote:
>>>>>>>>>>> On 1/24/2023 8:03 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/24/23 7:26 PM, olcott wrote:
>>>>>>>>>>>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>>>>>>>>>>>> In computability theory, the halting problem is the
>>>>>>>>>>>>>>> problem of
>>>>>>>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>>>>>>>> program and an
>>>>>>>>>>>>>>> input, whether the program will finish running, or
>>>>>>>>>>>>>>> continue to run
>>>>>>>>>>>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This definition of the halting problem measures
>>>>>>>>>>>>>>> correctness in a non-
>>>>>>>>>>>>>>> pathological way, thus in the same way that ZFC
>>>>>>>>>>>>>>> (redefined set theory
>>>>>>>>>>>>>>> and) eliminated Russell's Paradox the previously
>>>>>>>>>>>>>>> "impossible" input
>>>>>>>>>>>>>>> ceases to be impossible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In computability theory, the halting problem is the
>>>>>>>>>>>>>>> problem of defining
>>>>>>>>>>>>>>> a machine that correctly determines from a description of
>>>>>>>>>>>>>>> an arbitrary
>>>>>>>>>>>>>>> computer program and an input, whether or not its
>>>>>>>>>>>>>>> specified input pair
>>>>>>>>>>>>>>> would terminate normally by reaching it own final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, the Decider must decide if the actual running of
>>>>>>>>>>>>>> the program described by the input would halt when given
>>>>>>>>>>>>>> the input that is the rest of that input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is NOT asking if the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The conventional proofs do not actually show that such a
>>>>>>>>>>>>>>> machine cannot
>>>>>>>>>>>>>>> be defined. HH(PP, PP) does correctly determine that its
>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>> simulated input cannot possibly reach the final state of
>>>>>>>>>>>>>>> PP and
>>>>>>>>>>>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If the simulation is incorrect then there must a line of
>>>>>>>>>>>>>>> the simulation
>>>>>>>>>>>>>>> that behaves differently than what its corresponding line
>>>>>>>>>>>>>>> of machine-
>>>>>>>>>>>>>>> code specifies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, it is incorrect because it is incomplete.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are just usong the INCORRECT definition of "Correct",
>>>>>>>>>>>>>> and since you have been told this in the past, it just
>>>>>>>>>>>>>> shows that you are a LIAR about this fact.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "Correct Simulation" is defined as a simulation that
>>>>>>>>>>>>>> exactly matches the actual behavior of the machine the
>>>>>>>>>>>>>> input describes.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It turns out that is incorrect. The ultimate measure of a
>>>>>>>>>>>>> correct
>>>>>>>>>>>>> simulation is whether or not the simulated input exactly
>>>>>>>>>>>>> matches the
>>>>>>>>>>>>> behavior specified by its machine code.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, Sourcd for that claim.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Counter-examples cannot possibly exist.
>>>>>>>>>>> Try and show any correct simulation where the simulator does
>>>>>>>>>>> not simulate what the machine language specifies.
>>>>>>>>>>
>>>>>>>>>> This is the counter example.
>>>>>>>>>>
>>>>>>>>>> Since the direct eecution of the machine language of PP(PP)
>>>>>>>>>> will Halt, the correct simulation of it must match.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That is merely a provably false assumption.
>>>>>>>>
>>>>>>>> Then do so.
>>>>>>>>
>>>>>>>> Remember, your HH has been admitted to return 0 from HH(PP,PP),
>>>>>>>> and to be a computation, it must do the same to EVERY call.
>>>>>>>>
>>>>>>>> YOU have posted the execution trace of the direct execution of
>>>>>>>> the equivalent to PP, which shows it halts.
>>>>>>>>
>>>>>>>
>>>>>>> You can see on pages 5-6 that PP correctly simulated by HH cannot
>>>>>>> possibly reach it own final state.
>>>>>>
>>>>>> But that isn't the questipon, since that question, like the Liar's
>>>>>> paradox has no answer.
>>>>>>
>>>>> That makes the Halting Problem ill-defined:
>>>>
>>>> No, your RESTATEMENT is ill-defined. The behavior of P is well
>>>> defined given a proper definition of H
>>>>
>>>> H(P,P) can do one of 4 things, and can't do anything else.
>>>>
>>>> 1) H(P,P) can return 0, in which case P(P) will halt, and H is shown
>>>> to be wrong. This is what you claim your H does when directly called.
>>>>
>>>> 2) H(P,P) can retrun 1, in which case, P(P) will go into an infinite
>>>> loop, and H is shown to be wrong.
>>>>
>>>> 3) H(P,P) can just dies and halt and not return an answer, in which
>>>> case H fails to be the needed halt decider, and P(P) will be halting.
>>>>
>>>> 4) H(P,P) can get stuck in an infinte loop, and never return an
>>>> answer, in which case H fails to be the needed halt decider, and
>>>> P(P) will be non-halting. This is what you seem to claim is what H
>>>> does when simulated inside P.
>>>>
>>>>>
>>>>> In the study of problem solving, any problem in which the initial
>>>>> state or starting position, the allowable operations, and the goal
>>>>> state are clearly specified, *and a unique solution can be shown to
>>>>> exist*
>>>>
>>>> Right, and given an actual definition of the complete algorithm of H
>>>> (and 'Get the right answer' is NOT an complete algorithm) there is a
>>>> precise correct answer to the problem.
>>>>
>>>> Unfortunately of H, H can never give that answer.
>>>
>>> Thus making the halting problem ill-defined.
>>
>> No machine can possibly be defined that divides all pairs of finite
>> strings into those that represent machines would halt on their input
>> when directly executed and those that do not in the same way and for the
>> same reason that there is no barber that shaves all and only those that
>> do not shave themselves. ZFC eliminated this problem by declaring it is
>> erroneous.
>>
>
> Right, which shows that the Haltng Theorm is CORRECT, that that the
> Halting Function is not computable.
>
> So, you agree with the Theorem that you have been arguing against for 2
> decades?
>
>> Every decision problem where
>> *a unique solution CANNOT be shown to exist*
>> is erroneous.
>>
>
> Nope, just shows that the problem is not computable.
>
In the study of problem solving, any problem in which the initial state
or starting position, the allowable operations, and the goal state are
clearly specified, and a unique solution can be shown to exist.


Click here to read the complete article
Re: HH(PP,PP) correctly determines that its input never halts

<tqsijg$sqcp$1@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10392&group=comp.ai.philosophy#10392

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pyt...@invalid.org (Python)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Date: Thu, 26 Jan 2023 01:47:44 +0100
Organization: A noiseless patient Spider
Lines: 193
Message-ID: <tqsijg$sqcp$1@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
<tqqdpl$hcci$1@dont-email.me> <BE8AL.276573$gGD7.12810@fx11.iad>
<tqrmnb$ob0i$1@dont-email.me> <mKiAL.355627$MVg8.158433@fx12.iad>
<tqse0s$s42e$1@dont-email.me> <tqsf9v$s42e$2@dont-email.me>
<1KjAL.437313$iS99.97366@fx16.iad> <lTjAL.46530$4jN7.9315@fx02.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 26 Jan 2023 00:47:44 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="6ed95862eaeac0de9cc2501ed1302c52";
logging-data="944537"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+T5Gae8LZjgkBu73SW2jP3"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.3.3
Cancel-Lock: sha1:yWTS59L2CiNPm2aKB83LXF/qH8M=
In-Reply-To: <lTjAL.46530$4jN7.9315@fx02.iad>
Content-Language: en-US
 by: Python - Thu, 26 Jan 2023 00:47 UTC

Le 26/01/2023 à 01:33, Richard Damon a écrit :
> On 1/25/23 7:23 PM, Richard Damon wrote:
>> On 1/25/23 6:51 PM, olcott wrote:
>>> On 1/25/2023 5:29 PM, olcott wrote:
>>>> On 1/25/2023 5:15 PM, Richard Damon wrote:
>>>>> On 1/25/23 11:51 AM, olcott wrote:
>>>>>> On 1/25/2023 5:46 AM, Richard Damon wrote:
>>>>>>> On 1/25/23 12:13 AM, olcott wrote:
>>>>>>>> On 1/24/2023 10:09 PM, Richard Damon wrote:
>>>>>>>>> On 1/24/23 10:51 PM, olcott wrote:
>>>>>>>>>> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/24/23 10:10 PM, olcott wrote:
>>>>>>>>>>>> On 1/24/2023 8:03 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/24/23 7:26 PM, olcott wrote:
>>>>>>>>>>>>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>>>>>>>>>>>>> In computability theory, the halting problem is the
>>>>>>>>>>>>>>>> problem of
>>>>>>>>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>>>>>>>>> program and an
>>>>>>>>>>>>>>>> input, whether the program will finish running, or
>>>>>>>>>>>>>>>> continue to run
>>>>>>>>>>>>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This definition of the halting problem measures
>>>>>>>>>>>>>>>> correctness in a non-
>>>>>>>>>>>>>>>> pathological way, thus in the same way that ZFC
>>>>>>>>>>>>>>>> (redefined set theory
>>>>>>>>>>>>>>>> and) eliminated Russell's Paradox the previously
>>>>>>>>>>>>>>>> "impossible" input
>>>>>>>>>>>>>>>> ceases to be impossible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In computability theory, the halting problem is the
>>>>>>>>>>>>>>>> problem of defining
>>>>>>>>>>>>>>>> a machine that correctly determines from a description
>>>>>>>>>>>>>>>> of an arbitrary
>>>>>>>>>>>>>>>> computer program and an input, whether or not its
>>>>>>>>>>>>>>>> specified input pair
>>>>>>>>>>>>>>>> would terminate normally by reaching it own final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right, the Decider must decide if the actual running of
>>>>>>>>>>>>>>> the program described by the input would halt when given
>>>>>>>>>>>>>>> the input that is the rest of that input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is NOT asking if the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The conventional proofs do not actually show that such a
>>>>>>>>>>>>>>>> machine cannot
>>>>>>>>>>>>>>>> be defined. HH(PP, PP) does correctly determine that its
>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>> simulated input cannot possibly reach the final state of
>>>>>>>>>>>>>>>> PP and
>>>>>>>>>>>>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If the simulation is incorrect then there must a line of
>>>>>>>>>>>>>>>> the simulation
>>>>>>>>>>>>>>>> that behaves differently than what its corresponding
>>>>>>>>>>>>>>>> line of machine-
>>>>>>>>>>>>>>>> code specifies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, it is incorrect because it is incomplete.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are just usong the INCORRECT definition of "Correct",
>>>>>>>>>>>>>>> and since you have been told this in the past, it just
>>>>>>>>>>>>>>> shows that you are a LIAR about this fact.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "Correct Simulation" is defined as a simulation that
>>>>>>>>>>>>>>> exactly matches the actual behavior of the machine the
>>>>>>>>>>>>>>> input describes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It turns out that is incorrect. The ultimate measure of a
>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>> simulation is whether or not the simulated input exactly
>>>>>>>>>>>>>> matches the
>>>>>>>>>>>>>> behavior specified by its machine code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, Sourcd for that claim.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Counter-examples cannot possibly exist.
>>>>>>>>>>>> Try and show any correct simulation where the simulator does
>>>>>>>>>>>> not simulate what the machine language specifies.
>>>>>>>>>>>
>>>>>>>>>>> This is the counter example.
>>>>>>>>>>>
>>>>>>>>>>> Since the direct eecution of the machine language of PP(PP)
>>>>>>>>>>> will Halt, the correct simulation of it must match.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That is merely a provably false assumption.
>>>>>>>>>
>>>>>>>>> Then do so.
>>>>>>>>>
>>>>>>>>> Remember, your HH has been admitted to return 0 from HH(PP,PP),
>>>>>>>>> and to be a computation, it must do the same to EVERY call.
>>>>>>>>>
>>>>>>>>> YOU have posted the execution trace of the direct execution of
>>>>>>>>> the equivalent to PP, which shows it halts.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You can see on pages 5-6 that PP correctly simulated by HH
>>>>>>>> cannot possibly reach it own final state.
>>>>>>>
>>>>>>> But that isn't the questipon, since that question, like the
>>>>>>> Liar's paradox has no answer.
>>>>>>>
>>>>>> That makes the Halting Problem ill-defined:
>>>>>
>>>>> No, your RESTATEMENT is ill-defined. The behavior of P is well
>>>>> defined given a proper definition of H
>>>>>
>>>>> H(P,P) can do one of 4 things, and can't do anything else.
>>>>>
>>>>> 1) H(P,P) can return 0, in which case P(P) will halt, and H is
>>>>> shown to be wrong. This is what you claim your H does when directly
>>>>> called.
>>>>>
>>>>> 2) H(P,P) can retrun 1, in which case, P(P) will go into an
>>>>> infinite loop, and H is shown to be wrong.
>>>>>
>>>>> 3) H(P,P) can just dies and halt and not return an answer, in which
>>>>> case H fails to be the needed halt decider, and P(P) will be halting.
>>>>>
>>>>> 4) H(P,P) can get stuck in an infinte loop, and never return an
>>>>> answer, in which case H fails to be the needed halt decider, and
>>>>> P(P) will be non-halting. This is what you seem to claim is what H
>>>>> does when simulated inside P.
>>>>>
>>>>>>
>>>>>> In the study of problem solving, any problem in which the initial
>>>>>> state or starting position, the allowable operations, and the goal
>>>>>> state are clearly specified, *and a unique solution can be shown
>>>>>> to exist*
>>>>>
>>>>> Right, and given an actual definition of the complete algorithm of
>>>>> H (and 'Get the right answer' is NOT an complete algorithm) there
>>>>> is a precise correct answer to the problem.
>>>>>
>>>>> Unfortunately of H, H can never give that answer.
>>>>
>>>> Thus making the halting problem ill-defined.
>>>
>>> No machine can possibly be defined that divides all pairs of finite
>>> strings into those that represent machines would halt on their input
>>> when directly executed and those that do not in the same way and for the
>>> same reason that there is no barber that shaves all and only those that
>>> do not shave themselves. ZFC eliminated this problem by declaring it is
>>> erroneous.
>>>
>>
>> Right, which shows that the Haltng Theorm is CORRECT, that that the
>> Halting Function is not computable.
>>
>> So, you agree with the Theorem that you have been arguing against for
>> 2 decades?
>>
>>> Every decision problem where
>>> *a unique solution CANNOT be shown to exist*
>>> is erroneous.
>>>
>>
>> Nope, just shows that the problem is not computable.
>>
>> If you think uncompuatable problems are erroneous, then you can't
>> handle all of mathematics.
>
> One simple comment that comes to mind that points out the error in your
> thinking:
>
> The number of possible computing machines is a countable infinite,
> because we can express every such machine as a finite string of a finite
> symbol set.
>
> The number of possible deciders that can be defined is an UNCOUNTABLE
> infinite.
>
> Thus, there are deciders that can not be computed, in fact, MOST
> deciders can't be computed. (Admittedly a randomly chosen decider likely
> isn't useful).
>
> I suspect you aren't going to understand this, as you can't seem to
> handle the actual concept of infinity.


Click here to read the complete article
Re: HH(PP,PP) correctly determines that its input never halts

<tqsikg$sqcp$2@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10393&group=comp.ai.philosophy#10393

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pyt...@invalid.org (Python)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Date: Thu, 26 Jan 2023 01:48:16 +0100
Organization: A noiseless patient Spider
Lines: 18
Message-ID: <tqsikg$sqcp$2@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
<tqqdpl$hcci$1@dont-email.me> <BE8AL.276573$gGD7.12810@fx11.iad>
<tqrmnb$ob0i$1@dont-email.me> <mKiAL.355627$MVg8.158433@fx12.iad>
<tqse0s$s42e$1@dont-email.me> <tqsf9v$s42e$2@dont-email.me>
<tqsg4l$sem7$1@dont-email.me> <tqsi54$snb8$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 26 Jan 2023 00:48:16 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="6ed95862eaeac0de9cc2501ed1302c52";
logging-data="944537"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/49bI6LLgh2mSRFZ81JJzj"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.3.3
Cancel-Lock: sha1:JU4V2MWbp6Ljpdq6d1EadwPw+mA=
In-Reply-To: <tqsi54$snb8$1@dont-email.me>
Content-Language: en-US
 by: Python - Thu, 26 Jan 2023 00:48 UTC

Le 26/01/2023 à 01:40, olcott a écrit :
> On 1/25/2023 6:05 PM, Python wrote:
>> Peter Olcott wrote:
>> ...
>>> No machine can possibly be defined that divides all pairs of finite
>>> strings into those that represent machines would halt on their input
>>> when directly executed and those that do not
>>
>> So at least you admit that there no program can be written that
>> is an halt decider! It took time for you to abandon your delusions!
>>
>
> *I didn't say that*

This is exactly what you wrote. For once it was a correct statement.

Re: HH(PP,PP) correctly determines that its input never halts [-countability issue-]

<tqsilj$snb8$3@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10394&group=comp.ai.philosophy#10394

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
[-countability issue-]
Date: Wed, 25 Jan 2023 18:48:51 -0600
Organization: A noiseless patient Spider
Lines: 190
Message-ID: <tqsilj$snb8$3@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
<tqqdpl$hcci$1@dont-email.me> <BE8AL.276573$gGD7.12810@fx11.iad>
<tqrmnb$ob0i$1@dont-email.me> <mKiAL.355627$MVg8.158433@fx12.iad>
<tqse0s$s42e$1@dont-email.me> <tqsf9v$s42e$2@dont-email.me>
<1KjAL.437313$iS99.97366@fx16.iad> <lTjAL.46530$4jN7.9315@fx02.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 26 Jan 2023 00:48:51 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="0fda4ea1a7e80c67f7531f48811f9cf1";
logging-data="941416"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18RYAYrL9psqkGtrC14YLIN"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.6.1
Cancel-Lock: sha1:pZPATXZQwYx7Ea2FM72xbzGL0m4=
In-Reply-To: <lTjAL.46530$4jN7.9315@fx02.iad>
Content-Language: en-US
 by: olcott - Thu, 26 Jan 2023 00:48 UTC

On 1/25/2023 6:33 PM, Richard Damon wrote:
> On 1/25/23 7:23 PM, Richard Damon wrote:
>> On 1/25/23 6:51 PM, olcott wrote:
>>> On 1/25/2023 5:29 PM, olcott wrote:
>>>> On 1/25/2023 5:15 PM, Richard Damon wrote:
>>>>> On 1/25/23 11:51 AM, olcott wrote:
>>>>>> On 1/25/2023 5:46 AM, Richard Damon wrote:
>>>>>>> On 1/25/23 12:13 AM, olcott wrote:
>>>>>>>> On 1/24/2023 10:09 PM, Richard Damon wrote:
>>>>>>>>> On 1/24/23 10:51 PM, olcott wrote:
>>>>>>>>>> On 1/24/2023 9:40 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/24/23 10:10 PM, olcott wrote:
>>>>>>>>>>>> On 1/24/2023 8:03 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/24/23 7:26 PM, olcott wrote:
>>>>>>>>>>>>>> On 1/24/2023 5:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/24/23 10:41 AM, olcott wrote:
>>>>>>>>>>>>>>>> In computability theory, the halting problem is the
>>>>>>>>>>>>>>>> problem of
>>>>>>>>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>>>>>>>>> program and an
>>>>>>>>>>>>>>>> input, whether the program will finish running, or
>>>>>>>>>>>>>>>> continue to run
>>>>>>>>>>>>>>>> forever.  https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This definition of the halting problem measures
>>>>>>>>>>>>>>>> correctness in a non-
>>>>>>>>>>>>>>>> pathological way, thus in the same way that ZFC
>>>>>>>>>>>>>>>> (redefined set theory
>>>>>>>>>>>>>>>> and) eliminated Russell's Paradox the previously
>>>>>>>>>>>>>>>> "impossible" input
>>>>>>>>>>>>>>>> ceases to be impossible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In computability theory, the halting problem is the
>>>>>>>>>>>>>>>> problem of defining
>>>>>>>>>>>>>>>> a machine that correctly determines from a description
>>>>>>>>>>>>>>>> of an arbitrary
>>>>>>>>>>>>>>>> computer program and an input, whether or not its
>>>>>>>>>>>>>>>> specified input pair
>>>>>>>>>>>>>>>> would terminate normally by reaching it own final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right, the Decider must decide if the actual running of
>>>>>>>>>>>>>>> the program described by the input would halt when given
>>>>>>>>>>>>>>> the input that is the rest of that input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is NOT asking if the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The conventional proofs do not actually show that such a
>>>>>>>>>>>>>>>> machine cannot
>>>>>>>>>>>>>>>> be defined. HH(PP, PP) does correctly determine that its
>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>> simulated input cannot possibly reach the final state of
>>>>>>>>>>>>>>>> PP and
>>>>>>>>>>>>>>>> terminate normally. (See pages 5-6 of this paper)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If the simulation is incorrect then there must a line of
>>>>>>>>>>>>>>>> the simulation
>>>>>>>>>>>>>>>> that behaves differently than what its corresponding
>>>>>>>>>>>>>>>> line of machine-
>>>>>>>>>>>>>>>> code specifies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, it is incorrect because it is incomplete.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are just usong the INCORRECT definition of "Correct",
>>>>>>>>>>>>>>> and since you have been told this in the past, it just
>>>>>>>>>>>>>>> shows that you are a LIAR about this fact.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "Correct Simulation" is defined as a simulation that
>>>>>>>>>>>>>>> exactly matches the actual behavior of the machine the
>>>>>>>>>>>>>>> input describes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It turns out that is incorrect. The ultimate measure of a
>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>> simulation is whether or not the simulated input exactly
>>>>>>>>>>>>>> matches the
>>>>>>>>>>>>>> behavior specified by its machine code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, Sourcd for that claim.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Counter-examples cannot possibly exist.
>>>>>>>>>>>> Try and show any correct simulation where the simulator does
>>>>>>>>>>>> not simulate what the machine language specifies.
>>>>>>>>>>>
>>>>>>>>>>> This is the counter example.
>>>>>>>>>>>
>>>>>>>>>>> Since the direct eecution of the machine language of PP(PP)
>>>>>>>>>>> will Halt, the correct simulation of it must match.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That is merely a provably false assumption.
>>>>>>>>>
>>>>>>>>> Then do so.
>>>>>>>>>
>>>>>>>>> Remember, your HH has been admitted to return 0 from HH(PP,PP),
>>>>>>>>> and to be a computation, it must do the same to EVERY call.
>>>>>>>>>
>>>>>>>>> YOU have posted the execution trace of the direct execution of
>>>>>>>>> the equivalent to PP, which shows it halts.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You can see on pages 5-6 that PP correctly simulated by HH
>>>>>>>> cannot possibly reach it own final state.
>>>>>>>
>>>>>>> But that isn't the questipon, since that question, like the
>>>>>>> Liar's paradox has no answer.
>>>>>>>
>>>>>> That makes the Halting Problem ill-defined:
>>>>>
>>>>> No, your RESTATEMENT is ill-defined. The behavior of P is well
>>>>> defined given a proper definition of H
>>>>>
>>>>> H(P,P) can do one of 4 things, and can't do anything else.
>>>>>
>>>>> 1) H(P,P) can return 0, in which case P(P) will halt, and H is
>>>>> shown to be wrong. This is what you claim your H does when directly
>>>>> called.
>>>>>
>>>>> 2) H(P,P) can retrun 1, in which case, P(P) will go into an
>>>>> infinite loop, and H is shown to be wrong.
>>>>>
>>>>> 3) H(P,P) can just dies and halt and not return an answer, in which
>>>>> case H fails to be the needed halt decider, and P(P) will be halting.
>>>>>
>>>>> 4) H(P,P) can get stuck in an infinte loop, and never return an
>>>>> answer, in which case H fails to be the needed halt decider, and
>>>>> P(P) will be non-halting. This is what you seem to claim is what H
>>>>> does when simulated inside P.
>>>>>
>>>>>>
>>>>>> In the study of problem solving, any problem in which the initial
>>>>>> state or starting position, the allowable operations, and the goal
>>>>>> state are clearly specified, *and a unique solution can be shown
>>>>>> to exist*
>>>>>
>>>>> Right, and given an actual definition of the complete algorithm of
>>>>> H (and 'Get the right answer' is NOT an complete algorithm) there
>>>>> is a precise correct answer to the problem.
>>>>>
>>>>> Unfortunately of H, H can never give that answer.
>>>>
>>>> Thus making the halting problem ill-defined.
>>>
>>> No machine can possibly be defined that divides all pairs of finite
>>> strings into those that represent machines would halt on their input
>>> when directly executed and those that do not in the same way and for the
>>> same reason that there is no barber that shaves all and only those that
>>> do not shave themselves. ZFC eliminated this problem by declaring it is
>>> erroneous.
>>>
>>
>> Right, which shows that the Haltng Theorm is CORRECT, that that the
>> Halting Function is not computable.
>>
>> So, you agree with the Theorem that you have been arguing against for
>> 2 decades?
>>
>>> Every decision problem where
>>> *a unique solution CANNOT be shown to exist*
>>> is erroneous.
>>>
>>
>> Nope, just shows that the problem is not computable.
>>
>> If you think uncompuatable problems are erroneous, then you can't
>> handle all of mathematics.
>
> One simple comment that comes to mind that points out the error in your
> thinking:
>
> The number of possible computing machines is a countable infinite,
> because we can express every such machine as a finite string of a finite
> symbol set.
>
> The number of possible deciders that can be defined is an UNCOUNTABLE
> infinite.
>


Click here to read the complete article
Re: HH(PP,PP) correctly determines that its input never halts

<tqsj0h$snb8$4@dont-email.me>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=10395&group=comp.ai.philosophy#10395

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.ai.philosophy
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: HH(PP,PP) correctly determines that its input never halts
Date: Wed, 25 Jan 2023 18:54:41 -0600
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <tqsj0h$snb8$4@dont-email.me>
References: <tqou6f$6pbl$1@dont-email.me> <51_zL.265586$gGD7.147065@fx11.iad>
<tqpsvf$bu1t$1@dont-email.me> <r50AL.389317$8_id.40494@fx09.iad>
<tqq6jf$g7v8$1@dont-email.me> <0x1AL.136150$PXw7.56787@fx45.iad>
<tqq90e$gh3t$1@dont-email.me> <cY1AL.308016$Tcw8.270142@fx10.iad>
<tqqdpl$hcci$1@dont-email.me> <BE8AL.276573$gGD7.12810@fx11.iad>
<tqrmnb$ob0i$1@dont-email.me> <mKiAL.355627$MVg8.158433@fx12.iad>
<tqse0s$s42e$1@dont-email.me> <tqsf9v$s42e$2@dont-email.me>
<tqsg4l$sem7$1@dont-email.me> <tqsi54$snb8$1@dont-email.me>
<tqsikg$sqcp$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 26 Jan 2023 00:54:41 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="0fda4ea1a7e80c67f7531f48811f9cf1";
logging-data="941416"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18vvmNWOwM5oqpPm+wzqWPG"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.6.1
Cancel-Lock: sha1:YIqXuwX/Dqpl1lt4lho/LBX/Ses=
Content-Language: en-US
In-Reply-To: <tqsikg$sqcp$2@dont-email.me>
 by: olcott - Thu, 26 Jan 2023 00:54 UTC

On 1/25/2023 6:48 PM, Python wrote:
> Le 26/01/2023 à 01:40, olcott a écrit :
>> On 1/25/2023 6:05 PM, Python wrote:
>>> Peter Olcott wrote:
>>> ...
>>>> No machine can possibly be defined that divides all pairs of finite
>>>> strings into those that represent machines would halt on their input
>>>> when directly executed and those that do not
>>>
>>> So at least you admit that there no program can be written that
>>> is an halt decider! It took time for you to abandon your delusions!
>>>
>>
>> *I didn't say that*
>
> This is exactly what you wrote. For once it was a correct statement.
>

*This makes the current definition of the halting problem ill-defined*
In the study of problem solving, any problem in which the
initial state or starting position, the allowable operations,
and the goal state are clearly specified, and a unique
solution can be shown to exist.

*a unique solution can be shown to exist* or the problem itself is
ill-defined

https://www.oxfordreference.com/display/10.1093/oi/authority.20110803121717729;jsessionid=DAD4AA6FA046509B2E4564A52201A947

*This corrects the error with the definition of the halting problem*
When a simulating halt decider H is only required to report on the
behavior of D correctly simulated by H, then this problem has a
solution.

*ZFC eliminated Russell's Paradox by redefining the problem*

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

Pages:123456
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor