Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.theory > #37341 > unrolled thread

Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ]

Back to article view | Back to comp.theory

Contents

  Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-30 08:46 -0500
    Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 15:09 +0100
      Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-30 10:40 -0500
        Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 19:27 +0100
          Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-30 13:45 -0500
            Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-07-30 13:28 -0700
            Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 21:47 +0100
              Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-30 16:43 -0500
                Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Richard Damon <news.x.richarddamon@xoxy.net> - 2021-07-30 14:51 -0700
                  Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-30 16:59 -0500
                    Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-07-30 15:21 -0700
                      Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-30 17:45 -0500
                        Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-30 16:32 -0700
                          Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-30 18:44 -0500
                        Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-07-30 17:25 -0700
                Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-31 23:17 +0100
                  Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-31 21:34 -0500
                    Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-01 11:22 +0100
                      Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-08-01 23:07 -0500
                        Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-02 17:32 +0100
                          Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-08-02 13:37 -0500
                            Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-03 01:25 +0100
                              Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-08-02 20:02 -0500
                                Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-03 02:58 +0100
                                  Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-08-02 21:26 -0500
                                    Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-08-03 04:10 +0100
                                      Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-08-02 22:39 -0500
                                        Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-08-02 22:29 -0700
                                    Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-04 19:45 +0100
                            Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-08-02 22:22 -0700
    Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-30 11:06 -0600
      Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-30 12:11 -0500
        Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-30 15:46 -0600
          Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-30 16:53 -0500
            Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-30 16:13 -0600
              Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-30 17:43 -0500
                Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-30 17:01 -0600
                  Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-30 17:18 -0600
                  Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-30 18:34 -0500
                    Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-30 20:05 -0600
                      Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-30 21:33 -0500
                        Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] André G. Isaak <agisaak@gm.invalid> - 2021-07-30 21:09 -0600
                          Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] olcott <NoOne@NoWhere.com> - 2021-07-30 22:23 -0500
                            Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Richard Damon <Richard@Damon-Family.org> - 2021-07-30 20:57 -0700
                              Re: Pathological self-reference(Olcott 2004) decider [ Defeating Rice's Theorem ] Jeff Barnett <jbb@notatt.com> - 2021-07-30 22:26 -0600

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#37501

On 8/2/2021 11:32 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
> 
>> On 8/1/2021 5:22 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/31/2021 5:17 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/30/2021 3:47 PM, Ben Bacarisse wrote:
>>>>>
>>>>>>> It does not matter what the trace shows.  The trace can show some code
>>>>>>> deciding absolutely anything, either correctly or incorrectly, and still
>>>>>>> not refute Rice's theorem.  Rice's theorem is about the decidability of
>>>>>>> sets.
>>>>>>
>>>>>> If there exists no undecidable counter-example showing the Rice's
>>>>>> theorem is true then it would seem that Rice's theorem would have no
>>>>>> basis.
>>>>> There is no such thing as an undecidable example (singular).  But I
>>>>> think you now agree with me: nothing you have posted says anything about
>>>>> the soundness of the theorem.  The "if ... then it would seem..."
>>>>> pattern suggest you know you haven't proved anything.
>>>>
>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>> // Strachey(1965) CPL translated to C
>>>> void P(u32 x)
>>>> {
>>>>     if (H(x, x))
>>>>       HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>     Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> I call the above an HP counter example instance.
>>>
>>> I can't stop you.  Is the fact that a key part of the program is missing
>>> what makes it an "HP counter example instance"?
>>>
>>> What the rest of the world calls "HP instances" are actual programs
>>> (plus any required input).  But as I've said, you are using words to
>>> suggest things, poetically, in the reader's mind, not to communicate a
>>> precise technical meaning.
>>
>> And (according to you) the technical name for this Ĥ ⟨Ĥ⟩ is the cases
>> that Ĥ gets wrong. That sure doesn't seem like a formal defintion to
>> me.
> 
> It's not.  The formal definition of the case Ĥ ⟨Ĥ⟩ is Ĥ ⟨Ĥ⟩.
> 

What is the name of the category where a TM/input pair: (X,Y) is 
undecidable for X? It seems to make the most sense to simply calls this 
an undecidable TM/input pair.

>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>> if M applied to wM halts, and
>>
>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>> if M applied to wM does not halt
> 
> As you keep telling us, for your actual Ĥ,
> 
>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> 
> which is fine.  Nothing contradictory or paradoxical about that result.
> It's just how you've chosen to write Ĥ.  The part you get wrong is
> thinking (and claiming) that your Ĥ says something about Linz's proof.
> For a TM to be like Linz's Ĥ (even for the one case Ĥ ⟨Ĥ⟩) the above
> should happen only
>    
>    if Ĥ applied to ⟨Ĥ⟩ does not halt.
> 
> For the proof to be wrong, you would need to have what you once falsely
> claimed to have: an Ĥ that, at least for this one case, behaves as Linz
> (and everyone else) says is impossible.
> 

As Linz already specifies yet does not encode in his notation there are 
at least three separate and distinct instances of Ĥ.

H[0] means H<sub>0</sub>

H[0] The first one of these instances is the actual Turing machine Ĥ.
H[1] The second one is the TM description ⟨Ĥ⟩ input to Ĥ.
H[2] The third one is the copy of the TM description ⟨Ĥ⟩ input to Ĥ.

If we do not keep track of these distinctions then it seems like Ĥ.qx 
decides that its input never halts and then its input immediately halts. 
This would be an actual contradiction.

When we do keep track of these distinctions then the input: ⟨Ĥ[1]⟩ to 
Ĥ[0] can be understood to never reach its final states Ĥ[1].qy or 
Ĥ[1].qn thus proving that Ĥ[0].qx did correctly decide that its input 
⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ never halts.


-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

[toc] | [prev] | [next] | [standalone]

#37509

olcott <NoOne@NoWhere.com> writes:

> On 8/2/2021 11:32 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> 
>>> On 8/1/2021 5:22 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:

>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>> // Strachey(1965) CPL translated to C
>>>>> void P(u32 x)
>>>>> {
>>>>>     if (H(x, x))
>>>>>       HERE: goto HERE;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>     Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>>
>>>>> I call the above an HP counter example instance.
>>>>
>>>> I can't stop you.  Is the fact that a key part of the program is missing
>>>> what makes it an "HP counter example instance"?
>>>>
>>>> What the rest of the world calls "HP instances" are actual programs
>>>> (plus any required input).  But as I've said, you are using words to
>>>> suggest things, poetically, in the reader's mind, not to communicate a
>>>> precise technical meaning.
>>>
>>> And (according to you) the technical name for this Ĥ ⟨Ĥ⟩ is the cases
>>> that Ĥ gets wrong. That sure doesn't seem like a formal defintion to
>>> me.
>> It's not.  The formal definition of the case Ĥ ⟨Ĥ⟩ is Ĥ ⟨Ĥ⟩.
>
> What is the name of the category where a TM/input pair: (X,Y) is
> undecidable for X? It seems to make the most sense to simply calls
> this an undecidable TM/input pair.

I can't stop you using words like this.  But if you want to write
clearly so that experts can understand you, you would need to learn what
the words you use mean to other people.

But part of me is happy for you keep misusing terms like this.  It makes
it obvious that you don't really know how to say what you mean, so naive
readers are less likely to be taken in.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#37512

On 8/2/2021 7:25 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
> 
>> On 8/2/2021 11:32 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/1/2021 5:22 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
> 
>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>> // Strachey(1965) CPL translated to C
>>>>>> void P(u32 x)
>>>>>> {
>>>>>>      if (H(x, x))
>>>>>>        HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>      Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>> }
>>>>>>
>>>>>> I call the above an HP counter example instance.
>>>>>
>>>>> I can't stop you.  Is the fact that a key part of the program is missing
>>>>> what makes it an "HP counter example instance"?
>>>>>
>>>>> What the rest of the world calls "HP instances" are actual programs
>>>>> (plus any required input).  But as I've said, you are using words to
>>>>> suggest things, poetically, in the reader's mind, not to communicate a
>>>>> precise technical meaning.
>>>>
>>>> And (according to you) the technical name for this Ĥ ⟨Ĥ⟩ is the cases
>>>> that Ĥ gets wrong. That sure doesn't seem like a formal defintion to
>>>> me.
>>> It's not.  The formal definition of the case Ĥ ⟨Ĥ⟩ is Ĥ ⟨Ĥ⟩.
>>
>> What is the name of the category where a TM/input pair: (X,Y) is
>> undecidable for X? It seems to make the most sense to simply calls
>> this an undecidable TM/input pair.
> 
> I can't stop you using words like this.  But if you want to write
> clearly so that experts can understand you, you would need to learn what
> the words you use mean to other people.
> 
> But part of me is happy for you keep misusing terms like this.  It makes
> it obvious that you don't really know how to say what you mean, so naive
> readers are less likely to be taken in.
> 

I asked you for a correction, simply ignoring this request is not an 
honest dialogue.

-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

[toc] | [prev] | [next] | [standalone]

#37514

olcott <NoOne@NoWhere.com> writes:

> On 8/2/2021 7:25 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> 
>>> On 8/2/2021 11:32 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/1/2021 5:22 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>> 
>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>>      if (H(x, x))
>>>>>>>        HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>      Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>> }
>>>>>>>
>>>>>>> I call the above an HP counter example instance.
>>>>>>
>>>>>> I can't stop you.  Is the fact that a key part of the program is missing
>>>>>> what makes it an "HP counter example instance"?
>>>>>>
>>>>>> What the rest of the world calls "HP instances" are actual programs
>>>>>> (plus any required input).  But as I've said, you are using words to
>>>>>> suggest things, poetically, in the reader's mind, not to communicate a
>>>>>> precise technical meaning.
>>>>>
>>>>> And (according to you) the technical name for this Ĥ ⟨Ĥ⟩ is the cases
>>>>> that Ĥ gets wrong. That sure doesn't seem like a formal defintion to
>>>>> me.
>>>> It's not.  The formal definition of the case Ĥ ⟨Ĥ⟩ is Ĥ ⟨Ĥ⟩.
>>>
>>> What is the name of the category where a TM/input pair: (X,Y) is
>>> undecidable for X? It seems to make the most sense to simply calls
>>> this an undecidable TM/input pair.
>> I can't stop you using words like this.  But if you want to write
>> clearly so that experts can understand you, you would need to learn what
>> the words you use mean to other people.
>> But part of me is happy for you keep misusing terms like this.  It makes
>> it obvious that you don't really know how to say what you mean, so naive
>> readers are less likely to be taken in.
>
> I asked you for a correction, simply ignoring this request is not an
> honest dialogue.

You asked me for the name of a category that is, at best, vague for me
because you described the category using technical words in a way that's
not usual.

My best guess for "undecidable TM/input pair for X" is "a halting
problem instance that X gets wrong".  I've given you this alternative
before, but you don't like it.  Maybe you just want a more emotive or
poetic term.  Shall we call them "spawn of the devil inputs for X"?

But step one is for you to read a book so you know what decidable means
(in this context).  Ideally, you will see from the book that the term is
not ideal, and you'll switch to talking about recursive sets.  Shall we
do that?  It might help.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#37516

On 8/2/2021 8:58 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
> 
>> On 8/2/2021 7:25 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/2/2021 11:32 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/1/2021 5:22 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>>       if (H(x, x))
>>>>>>>>         HERE: goto HERE;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>       Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> I call the above an HP counter example instance.
>>>>>>>
>>>>>>> I can't stop you.  Is the fact that a key part of the program is missing
>>>>>>> what makes it an "HP counter example instance"?
>>>>>>>
>>>>>>> What the rest of the world calls "HP instances" are actual programs
>>>>>>> (plus any required input).  But as I've said, you are using words to
>>>>>>> suggest things, poetically, in the reader's mind, not to communicate a
>>>>>>> precise technical meaning.
>>>>>>
>>>>>> And (according to you) the technical name for this Ĥ ⟨Ĥ⟩ is the cases
>>>>>> that Ĥ gets wrong. That sure doesn't seem like a formal defintion to
>>>>>> me.
>>>>> It's not.  The formal definition of the case Ĥ ⟨Ĥ⟩ is Ĥ ⟨Ĥ⟩.
>>>>
>>>> What is the name of the category where a TM/input pair: (X,Y) is
>>>> undecidable for X? It seems to make the most sense to simply calls
>>>> this an undecidable TM/input pair.
>>> I can't stop you using words like this.  But if you want to write
>>> clearly so that experts can understand you, you would need to learn what
>>> the words you use mean to other people.
>>> But part of me is happy for you keep misusing terms like this.  It makes
>>> it obvious that you don't really know how to say what you mean, so naive
>>> readers are less likely to be taken in.
>>
>> I asked you for a correction, simply ignoring this request is not an
>> honest dialogue.
> 
> You asked me for the name of a category that is, at best, vague for me
> because you described the category using technical words in a way that's
> not usual.
> 
> My best guess for "undecidable TM/input pair for X" is "a halting
> problem instance that X gets wrong".  

Surely there is a better way to say it than that.

> I've given you this alternative
> before, but you don't like it.  Maybe you just want a more emotive or
> poetic term.  Shall we call them "spawn of the devil inputs for X"?
> 
> But step one is for you to read a book so you know what decidable means
> (in this context).  Ideally, you will see from the book that the term is
> not ideal, and you'll switch to talking about recursive sets.  Shall we
> do that?  It might help.
> 

It seems to me that saying that it is a TM/input pair such that both 
Boolean values are incorrect final states for the decision criteria gets 
closer to the philosophical underpinnings of the issue.



-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

[toc] | [prev] | [next] | [standalone]

#37517

On 03/08/2021 03:26, olcott wrote:
> On 8/2/2021 8:58 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/2/2021 7:25 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/2/2021 11:32 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/1/2021 5:22 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>>       if (H(x, x))
>>>>>>>>>         HERE: goto HERE;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>       Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I call the above an HP counter example instance.
>>>>>>>>
>>>>>>>> I can't stop you.  Is the fact that a key part of the program is 
>>>>>>>> missing
>>>>>>>> what makes it an "HP counter example instance"?
>>>>>>>>
>>>>>>>> What the rest of the world calls "HP instances" are actual programs
>>>>>>>> (plus any required input).  But as I've said, you are using 
>>>>>>>> words to
>>>>>>>> suggest things, poetically, in the reader's mind, not to 
>>>>>>>> communicate a
>>>>>>>> precise technical meaning.
>>>>>>>
>>>>>>> And (according to you) the technical name for this Ĥ ⟨Ĥ⟩ is the 
>>>>>>> cases
>>>>>>> that Ĥ gets wrong. That sure doesn't seem like a formal defintion to
>>>>>>> me.
>>>>>> It's not.  The formal definition of the case Ĥ ⟨Ĥ⟩ is Ĥ ⟨Ĥ⟩.
>>>>>
>>>>> What is the name of the category where a TM/input pair: (X,Y) is
>>>>> undecidable for X? It seems to make the most sense to simply calls
>>>>> this an undecidable TM/input pair.
>>>> I can't stop you using words like this.  But if you want to write
>>>> clearly so that experts can understand you, you would need to learn 
>>>> what
>>>> the words you use mean to other people.
>>>> But part of me is happy for you keep misusing terms like this.  It 
>>>> makes
>>>> it obvious that you don't really know how to say what you mean, so 
>>>> naive
>>>> readers are less likely to be taken in.
>>>
>>> I asked you for a correction, simply ignoring this request is not an
>>> honest dialogue.
>>
>> You asked me for the name of a category that is, at best, vague for me
>> because you described the category using technical words in a way that's
>> not usual.
>>
>> My best guess for "undecidable TM/input pair for X" is "a halting
>> problem instance that X gets wrong". 
> 
> Surely there is a better way to say it than that.

"Nemesis" inputs...  That should be emotive enough for you, but still 
conveys the impression that the input is constructed to "defeat" the 
potential decider - like pretending that the decider is a superhero and 
every superhero has to have (at least) one nemesis, or things would be 
boring!

But Ben's "inputs the decider gets wrong" is ok too!

> 
>> I've given you this alternative
>> before, but you don't like it.  Maybe you just want a more emotive or
>> poetic term.  Shall we call them "spawn of the devil inputs for X"?
>>
>> But step one is for you to read a book so you know what decidable means
>> (in this context).  Ideally, you will see from the book that the term is
>> not ideal, and you'll switch to talking about recursive sets.  Shall we
>> do that?  It might help.
>>
> 
> It seems to me that saying that it is a TM/input pair such that both 
> Boolean values are incorrect final states for the decision criteria gets 
> closer to the philosophical underpinnings of the issue.
> 
> 
> 

[toc] | [prev] | [next] | [standalone]

#37518

On 8/2/2021 10:10 PM, Mike Terry wrote:
> On 03/08/2021 03:26, olcott wrote:
>> On 8/2/2021 8:58 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/2/2021 7:25 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/2/2021 11:32 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/1/2021 5:22 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>>>>> void P(u32 x)
>>>>>>>>>> {
>>>>>>>>>>       if (H(x, x))
>>>>>>>>>>         HERE: goto HERE;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>>       Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> I call the above an HP counter example instance.
>>>>>>>>>
>>>>>>>>> I can't stop you.  Is the fact that a key part of the program 
>>>>>>>>> is missing
>>>>>>>>> what makes it an "HP counter example instance"?
>>>>>>>>>
>>>>>>>>> What the rest of the world calls "HP instances" are actual 
>>>>>>>>> programs
>>>>>>>>> (plus any required input).  But as I've said, you are using 
>>>>>>>>> words to
>>>>>>>>> suggest things, poetically, in the reader's mind, not to 
>>>>>>>>> communicate a
>>>>>>>>> precise technical meaning.
>>>>>>>>
>>>>>>>> And (according to you) the technical name for this Ĥ ⟨Ĥ⟩ is the 
>>>>>>>> cases
>>>>>>>> that Ĥ gets wrong. That sure doesn't seem like a formal 
>>>>>>>> defintion to
>>>>>>>> me.
>>>>>>> It's not.  The formal definition of the case Ĥ ⟨Ĥ⟩ is Ĥ ⟨Ĥ⟩.
>>>>>>
>>>>>> What is the name of the category where a TM/input pair: (X,Y) is
>>>>>> undecidable for X? It seems to make the most sense to simply calls
>>>>>> this an undecidable TM/input pair.
>>>>> I can't stop you using words like this.  But if you want to write
>>>>> clearly so that experts can understand you, you would need to learn 
>>>>> what
>>>>> the words you use mean to other people.
>>>>> But part of me is happy for you keep misusing terms like this.  It 
>>>>> makes
>>>>> it obvious that you don't really know how to say what you mean, so 
>>>>> naive
>>>>> readers are less likely to be taken in.
>>>>
>>>> I asked you for a correction, simply ignoring this request is not an
>>>> honest dialogue.
>>>
>>> You asked me for the name of a category that is, at best, vague for me
>>> because you described the category using technical words in a way that's
>>> not usual.
>>>
>>> My best guess for "undecidable TM/input pair for X" is "a halting
>>> problem instance that X gets wrong". 
>>
>> Surely there is a better way to say it than that.
> 
> "Nemesis" inputs...  That should be emotive enough for you, but still 
> conveys the impression that the input is constructed to "defeat" the 
> potential decider - like pretending that the decider is a superhero and 
> every superhero has to have (at least) one nemesis, or things would be 
> boring!
> 

Among all philosophical understandings of the formal nature of truth the 
Liar Paradox (upon which the Tarski undefinability theorem is based) has 
fooled all into believing that Truth itself is incoherent:

http://www.liarparadox.org/Tarski_Proof_275_276.pdf

> But Ben's "inputs the decider gets wrong" is ok too!
> 
>>
>>> I've given you this alternative
>>> before, but you don't like it.  Maybe you just want a more emotive or
>>> poetic term.  Shall we call them "spawn of the devil inputs for X"?
>>>
>>> But step one is for you to read a book so you know what decidable means
>>> (in this context).  Ideally, you will see from the book that the term is
>>> not ideal, and you'll switch to talking about recursive sets.  Shall we
>>> do that?  It might help.
>>>
>>
>> It seems to me that saying that it is a TM/input pair such that both 
>> Boolean values are incorrect final states for the decision criteria 
>> gets closer to the philosophical underpinnings of the issue.
>>
>>
>>


-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

[toc] | [prev] | [next] | [standalone]

#37527

On 8/2/21 8:39 PM, olcott wrote:

> Among all philosophical understandings of the formal nature of truth the
> Liar Paradox (upon which the Tarski undefinability theorem is based) has
> fooled all into believing that Truth itself is incoherent:

But the Halting Question doesn't share that property,

For ANY Machine/Input combination, there IS a right answer.

The key is that due to the structure of the ^ template, H can not give
it, as for each H that is created, IT'S H^ will contradict its answer.

That is a logically valid result, as we have no basis to presume that H
has to be right.

[toc] | [prev] | [next] | [standalone]

#37607

olcott <NoOne@NoWhere.com> writes:

> On 8/2/2021 8:58 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> 
>>> On 8/2/2021 7:25 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/2/2021 11:32 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/1/2021 5:22 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>>       if (H(x, x))
>>>>>>>>>         HERE: goto HERE;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>       Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I call the above an HP counter example instance.
>>>>>>>>
>>>>>>>> I can't stop you.  Is the fact that a key part of the program is missing
>>>>>>>> what makes it an "HP counter example instance"?
>>>>>>>>
>>>>>>>> What the rest of the world calls "HP instances" are actual programs
>>>>>>>> (plus any required input).  But as I've said, you are using words to
>>>>>>>> suggest things, poetically, in the reader's mind, not to communicate a
>>>>>>>> precise technical meaning.
>>>>>>>
>>>>>>> And (according to you) the technical name for this Ĥ ⟨Ĥ⟩ is the cases
>>>>>>> that Ĥ gets wrong. That sure doesn't seem like a formal defintion to
>>>>>>> me.
>>>>>> It's not.  The formal definition of the case Ĥ ⟨Ĥ⟩ is Ĥ ⟨Ĥ⟩.
>>>>>
>>>>> What is the name of the category where a TM/input pair: (X,Y) is
>>>>> undecidable for X? It seems to make the most sense to simply calls
>>>>> this an undecidable TM/input pair.
>>>> I can't stop you using words like this.  But if you want to write
>>>> clearly so that experts can understand you, you would need to learn what
>>>> the words you use mean to other people.
>>>> But part of me is happy for you keep misusing terms like this.  It makes
>>>> it obvious that you don't really know how to say what you mean, so naive
>>>> readers are less likely to be taken in.
>>>
>>> I asked you for a correction, simply ignoring this request is not an
>>> honest dialogue.
>> You asked me for the name of a category that is, at best, vague for me
>> because you described the category using technical words in a way that's
>> not usual.
>> My best guess for "undecidable TM/input pair for X" is "a halting
>> problem instance that X gets wrong".  
>
> Surely there is a better way to say it than that.

Since I am not sure what you mean, it's quite possible.  Misusing terms
means that I have trouble knowing what you want me to name for you.  Why
does the name matter so much?  Surely the fact that your H is wrong
about the H^(H^) case is what matters, rather than what you call these
cases?

>> I've given you this alternative
>> before, but you don't like it.  Maybe you just want a more emotive or
>> poetic term.  Shall we call them "spawn of the devil inputs for X"?
>> But step one is for you to read a book so you know what decidable means
>> (in this context).  Ideally, you will see from the book that the term is
>> not ideal, and you'll switch to talking about recursive sets.  Shall we
>> do that?  It might help.
>
> It seems to me that saying that it is a TM/input pair such that both
> Boolean values are incorrect final states for the decision criteria
> gets closer to the philosophical underpinnings of the issue.

No, because you are wrong about that.  You've been wrong about for 17
years or more.  Every instance of the halting problem has a correct
yes/no answer.  "Accept" is the correct final state of the decider only
for those instances that represent halting computations, in all other
cases the decider's final state should be "reject".  The fact that every
single TM gets at least one case wrong does not mean there is not a
correct answer for every halting problem instance.  Baffling, isn't it?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#37524

On 8/2/21 11:37 AM, olcott wrote:

> What is the name of the category where a TM/input pair: (X,Y) is
> undecidable for X? It seems to make the most sense to simply calls this
> an undecidable TM/input pair.
> 

A given TM X when given an input Y will either produce a specific output
or be non-halting.

Remember, if X is a TM, that means its FULL algorithm is defined, and
thus what result it produces is defined for a given input.

In your case, the name is 'Wrong', as H gives the demonstratable wrong
answer.

Your Hypothetical case where you assume H doesn't abort, then H is just
non-Halting which is ALSO a WRONG behavior for a machine defined to be a
decider, or a partial decider that is supposed to handle this case.

You are confusing that fact that NO H can give the provably right answer
for a given H doesn't give the right answer.

For a given H, that does answer H(H^,H^), then the Halting of H^(H^) is
NOT 'undecidable', as it is easy to create a halting decider HH that
provably gets the answer right (it just uses H and returns the opposite
answer), thus H^(H^) is not 'undecidable'

The Linz proof you are working on doesn't really directly say that there
exists halting problems that no machine gets right, THAT is a couple of
steps past this basic proof, which just shows that any given machine has
some problems that it gets wrong.

The key to the wider proof is that since every decider gets some
problems wrong, it might first seem that all you need to do is know
which ones it gets wrong (or might get wrong) and have another decider
that gets those problems right and somehow know which one to use. The
key is that this choosing of which answer to use ALSO boils down to a
decider, and once we think we have it, we can make a ^ machine for that
master decider, at by the proof IT will be wrong, and thus we can't know
which is the right answer. This logic can be extended to show that there
MUST be a machine (or possibly more than one) that we can make a machine
that we KNOW gives the right answer.

It is of course easy to make two machines and know that one of them
gives the right answer, just make one that aways says Halting and
another that always says non-Halting, and we KNOW that exactly one of
them is right, we just don't know which one.

[toc] | [prev] | [next] | [standalone]

#37353

On 2021-07-30 07:46, olcott wrote:

> int Simulate(u32 P, u32 I)
> {
>    ((int(*)(int))P)(I);
>    return 1;
> }

Why is this function called 'Simulate'?

There's nothing remotely resembling simulation going on there. The 
function is simply calling the function pointer that was passed to it. 
That's execution, not simulation.

Which raises all sorts of questions regarding your previous usage of the 
term 'simulate'. Does your 'simulating decider' actually involve 
simulation at all?

André


-- 
To email remove 'invalid' & replace 'gm' with well known Google mail 
service.

[toc] | [prev] | [next] | [standalone]

#37355

On 7/30/2021 12:06 PM, André G. Isaak wrote:
> On 2021-07-30 07:46, olcott wrote:
> 
>> int Simulate(u32 P, u32 I)
>> {
>>    ((int(*)(int))P)(I);
>>    return 1;
>> }
> 
> Why is this function called 'Simulate'?
> 
> There's nothing remotely resembling simulation going on there. The 
> function is simply calling the function pointer that was passed to it. 
> That's execution, not simulation.
> 

It is the simplest possible function that is computationally equivalent 
to a simulation. Since every single instruction of the entire x86utm 
operating system is simulated the name is also literally true.

> Which raises all sorts of questions regarding your previous usage of the 
> term 'simulate'. Does your 'simulating decider' actually involve 
> simulation at all?
> 
> André
> 
> 

The x86utm operating system is based on an x86 emulator that has decades 
of development.

-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

[toc] | [prev] | [next] | [standalone]

#37371

On 2021-07-30 11:11, olcott wrote:
> On 7/30/2021 12:06 PM, André G. Isaak wrote:
>> On 2021-07-30 07:46, olcott wrote:
>>
>>> int Simulate(u32 P, u32 I)
>>> {
>>>    ((int(*)(int))P)(I);
>>>    return 1;
>>> }
>>
>> Why is this function called 'Simulate'?
>>
>> There's nothing remotely resembling simulation going on there. The 
>> function is simply calling the function pointer that was passed to it. 
>> That's execution, not simulation.
>>
> 
> It is the simplest possible function that is computationally equivalent 
> to a simulation. Since every single instruction of the entire x86utm 
> operating system is simulated the name is also literally true.

Well, no, it isn't. The name 'simulator' suggests that this function 
performs simulation. From what you suggest above, 'simulator' is, 
itself, being simulated. That's something altogether different which 
makes the name incredibly misleading.

>> Which raises all sorts of questions regarding your previous usage of 
>> the term 'simulate'. Does your 'simulating decider' actually involve 
>> simulation at all?
>>
>> André
>>
>>
> 
> The x86utm operating system is based on an x86 emulator that has decades 
> of development.

That doesn't answer my question at all (and I don't know why you think 
anyone cares how many decades something has been under development).

You consistently referred to your H as a 'simulating halt decider', but 
every time you present code snippets of H it shows H making a direct 
call to its input rather than invoking any kind of simulator.

So is H actually the thing doing the simulation, or is H simply *being* 
simulated in much the same way as your so-called 'Simulate' function 
above is?

André

-- 
To email remove 'invalid' & replace 'gm' with well known Google mail 
service.

[toc] | [prev] | [next] | [standalone]

#37373

On 7/30/2021 4:46 PM, André G. Isaak wrote:
> On 2021-07-30 11:11, olcott wrote:
>> On 7/30/2021 12:06 PM, André G. Isaak wrote:
>>> On 2021-07-30 07:46, olcott wrote:
>>>
>>>> int Simulate(u32 P, u32 I)
>>>> {
>>>>    ((int(*)(int))P)(I);
>>>>    return 1;
>>>> }
>>>
>>> Why is this function called 'Simulate'?
>>>
>>> There's nothing remotely resembling simulation going on there. The 
>>> function is simply calling the function pointer that was passed to 
>>> it. That's execution, not simulation.
>>>
>>
>> It is the simplest possible function that is computationally 
>> equivalent to a simulation. Since every single instruction of the 
>> entire x86utm operating system is simulated the name is also literally 
>> true.
> 
> Well, no, it isn't. The name 'simulator' suggests that this function 
> performs simulation. From what you suggest above, 'simulator' is, 
> itself, being simulated. That's something altogether different which 
> makes the name incredibly misleading.
> 

Then think of it as being named Big_Freds_Pizza(), the point is that my 
code seems to defeat Rice.

Didn't you make a claim that you could fool it?

>>> Which raises all sorts of questions regarding your previous usage of 
>>> the term 'simulate'. Does your 'simulating decider' actually involve 
>>> simulation at all?
>>>
>>> André
>>>
>>>
>>
>> The x86utm operating system is based on an x86 emulator that has 
>> decades of development.
> 
> That doesn't answer my question at all (and I don't know why you think 
> anyone cares how many decades something has been under development).
> 
> You consistently referred to your H as a 'simulating halt decider', but 
> every time you present code snippets of H it shows H making a direct 
> call to its input rather than invoking any kind of simulator.
> 
> So is H actually the thing doing the simulation, or is H simply *being* 
> simulated in much the same way as your so-called 'Simulate' function 
> above is?
> 
> André
> 

Why can't you seem to stay focused on the key point at hand?
Why do you diverge off on inconsequential trivialities?

If you think that you can fool my Pathological self-reference(Olcott 
2004) decider go ahead any try this. If it is impossible to fool it then 
that proves that it is correct.

-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

[toc] | [prev] | [next] | [standalone]

#37375

On 2021-07-30 15:53, olcott wrote:
> On 7/30/2021 4:46 PM, André G. Isaak wrote:
>> On 2021-07-30 11:11, olcott wrote:
>>> On 7/30/2021 12:06 PM, André G. Isaak wrote:
>>>> On 2021-07-30 07:46, olcott wrote:
>>>>
>>>>> int Simulate(u32 P, u32 I)
>>>>> {
>>>>>    ((int(*)(int))P)(I);
>>>>>    return 1;
>>>>> }
>>>>
>>>> Why is this function called 'Simulate'?
>>>>
>>>> There's nothing remotely resembling simulation going on there. The 
>>>> function is simply calling the function pointer that was passed to 
>>>> it. That's execution, not simulation.
>>>>
>>>
>>> It is the simplest possible function that is computationally 
>>> equivalent to a simulation. Since every single instruction of the 
>>> entire x86utm operating system is simulated the name is also 
>>> literally true.
>>
>> Well, no, it isn't. The name 'simulator' suggests that this function 
>> performs simulation. From what you suggest above, 'simulator' is, 
>> itself, being simulated. That's something altogether different which 
>> makes the name incredibly misleading.
>>
> 
> Then think of it as being named Big_Freds_Pizza(), the point is that my 
> code seems to defeat Rice.
> 
> Didn't you make a claim that you could fool it?
> 
>>>> Which raises all sorts of questions regarding your previous usage of 
>>>> the term 'simulate'. Does your 'simulating decider' actually involve 
>>>> simulation at all?
>>>>
>>>> André
>>>>
>>>>
>>>
>>> The x86utm operating system is based on an x86 emulator that has 
>>> decades of development.
>>
>> That doesn't answer my question at all (and I don't know why you think 
>> anyone cares how many decades something has been under development).
>>
>> You consistently referred to your H as a 'simulating halt decider', 
>> but every time you present code snippets of H it shows H making a 
>> direct call to its input rather than invoking any kind of simulator.
>>
>> So is H actually the thing doing the simulation, or is H simply 
>> *being* simulated in much the same way as your so-called 'Simulate' 
>> function above is?
>>
>> André
>>
> 
> Why can't you seem to stay focused on the key point at hand?
> Why do you diverge off on inconsequential trivialities?

Because it *isn't* an inconsequential triviality. I'm trying to figure 
out the actual architecture of your system, and you are being 
deliberately unhelpful.

Just because you don't understand why a particular question is being 
asked isn't a good reason to refuse to answer it. I can guarantee you 
that if you ever present your work in a *real* academic environment, you 
will be asked all sorts of questions of which you might not immediately 
see the relevance, and you *will* be expected to answer them.

> If you think that you can fool my Pathological self-reference(Olcott 
> 2004) decider go ahead any try this. If it is impossible to fool it then 
> that proves that it is correct.

How can anyone possible answer this?

You've apparently now got two different halt decider, H1 and H2. You 
haven't provided even the vaguest description of what these things do or 
how they differ from one another.

You can't expect people to answer questions about code that you have not 
provided.

André

-- 
To email remove 'invalid' & replace 'gm' with well known Google mail 
service.

[toc] | [prev] | [next] | [standalone]

#37378

On 7/30/2021 5:13 PM, André G. Isaak wrote:
> On 2021-07-30 15:53, olcott wrote:
>> On 7/30/2021 4:46 PM, André G. Isaak wrote:
>>> On 2021-07-30 11:11, olcott wrote:
>>>> On 7/30/2021 12:06 PM, André G. Isaak wrote:
>>>>> On 2021-07-30 07:46, olcott wrote:
>>>>>
>>>>>> int Simulate(u32 P, u32 I)
>>>>>> {
>>>>>>    ((int(*)(int))P)(I);
>>>>>>    return 1;
>>>>>> }
>>>>>
>>>>> Why is this function called 'Simulate'?
>>>>>
>>>>> There's nothing remotely resembling simulation going on there. The 
>>>>> function is simply calling the function pointer that was passed to 
>>>>> it. That's execution, not simulation.
>>>>>
>>>>
>>>> It is the simplest possible function that is computationally 
>>>> equivalent to a simulation. Since every single instruction of the 
>>>> entire x86utm operating system is simulated the name is also 
>>>> literally true.
>>>
>>> Well, no, it isn't. The name 'simulator' suggests that this function 
>>> performs simulation. From what you suggest above, 'simulator' is, 
>>> itself, being simulated. That's something altogether different which 
>>> makes the name incredibly misleading.
>>>
>>
>> Then think of it as being named Big_Freds_Pizza(), the point is that 
>> my code seems to defeat Rice.
>>
>> Didn't you make a claim that you could fool it?
>>
>>>>> Which raises all sorts of questions regarding your previous usage 
>>>>> of the term 'simulate'. Does your 'simulating decider' actually 
>>>>> involve simulation at all?
>>>>>
>>>>> André
>>>>>
>>>>>
>>>>
>>>> The x86utm operating system is based on an x86 emulator that has 
>>>> decades of development.
>>>
>>> That doesn't answer my question at all (and I don't know why you 
>>> think anyone cares how many decades something has been under 
>>> development).
>>>
>>> You consistently referred to your H as a 'simulating halt decider', 
>>> but every time you present code snippets of H it shows H making a 
>>> direct call to its input rather than invoking any kind of simulator.
>>>
>>> So is H actually the thing doing the simulation, or is H simply 
>>> *being* simulated in much the same way as your so-called 'Simulate' 
>>> function above is?
>>>
>>> André
>>>
>>
>> Why can't you seem to stay focused on the key point at hand?
>> Why do you diverge off on inconsequential trivialities?
> 
> Because it *isn't* an inconsequential triviality. I'm trying to figure 
> out the actual architecture of your system, and you are being 
> deliberately unhelpful.
> 
> Just because you don't understand why a particular question is being 
> asked isn't a good reason to refuse to answer it. 

int Simulate(u32 P, u32 I)
{
   ((int(*)(int))P)(I);
   return 1;
}

// H and H2 are partial halt deciders
u32 PSR_Decider(u32 P, u32 I)
{
   u32 Input_Halts1 = H((u32)P, (u32)I);
   u32 Input_Halts2 = H2((u32)Simulate, (u32)P, (u32)I);
   Output("Input_Halts1 = ", Input_Halts1);
   Output("Input_Halts2 = ", Input_Halts2);
   if (Input_Halts1 != Input_Halts2)
     return 1;
   return 0;
}

void P(u32 x)
{
   if (H(x, x))
     HERE: goto HERE;
}

int main()
{
   Output("PSR_Decider = ", PSR_Decider((u32)P, (u32)P));
}

The point of this post is whether or not my PSR_Decider() is correct.
The name that I choose for my functions is not related to that.

> I can guarantee you 
> that if you ever present your work in a *real* academic environment, you 
> will be asked all sorts of questions of which you might not immediately 
> see the relevance, and you *will* be expected to answer them.
> 
>> If you think that you can fool my Pathological self-reference(Olcott 
>> 2004) decider go ahead any try this. If it is impossible to fool it 
>> then that proves that it is correct.
> 
> How can anyone possible answer this?
> 
> You've apparently now got two different halt decider, H1 and H2. You 
> haven't provided even the vaguest description of what these things do or 
> how they differ from one another.
> 

So before you ever read what I say you first make sure to forget 
everything else that we have discussed.

The P of int main(){ P(P); } reaches its final state.
The input to H(P,P) cannot possibly reach its final state.
PSR_Decider() sees this difference.

This difference only occurs when the input to the halt decider 
contradicts whatever the halt decider decides. It picks out all of these 
cases thus refutes Rice.

> You can't expect people to answer questions about code that you have not 
> provided.
> 
> André
> 

Try and do the same sort of trick that fools the halt decider to fool my 
PSR_Decider(), you already claimed that you could do this didn't you?

-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

[toc] | [prev] | [next] | [standalone]

#37380

On 2021-07-30 16:43, olcott wrote:
> On 7/30/2021 5:13 PM, André G. Isaak wrote:
>> On 2021-07-30 15:53, olcott wrote:
>>> On 7/30/2021 4:46 PM, André G. Isaak wrote:
>>>> On 2021-07-30 11:11, olcott wrote:
>>>>> On 7/30/2021 12:06 PM, André G. Isaak wrote:
>>>>>> On 2021-07-30 07:46, olcott wrote:
>>>>>>
>>>>>>> int Simulate(u32 P, u32 I)
>>>>>>> {
>>>>>>>    ((int(*)(int))P)(I);
>>>>>>>    return 1;
>>>>>>> }
>>>>>>
>>>>>> Why is this function called 'Simulate'?
>>>>>>
>>>>>> There's nothing remotely resembling simulation going on there. The 
>>>>>> function is simply calling the function pointer that was passed to 
>>>>>> it. That's execution, not simulation.
>>>>>>
>>>>>
>>>>> It is the simplest possible function that is computationally 
>>>>> equivalent to a simulation. Since every single instruction of the 
>>>>> entire x86utm operating system is simulated the name is also 
>>>>> literally true.
>>>>
>>>> Well, no, it isn't. The name 'simulator' suggests that this function 
>>>> performs simulation. From what you suggest above, 'simulator' is, 
>>>> itself, being simulated. That's something altogether different which 
>>>> makes the name incredibly misleading.
>>>>
>>>
>>> Then think of it as being named Big_Freds_Pizza(), the point is that 
>>> my code seems to defeat Rice.
>>>
>>> Didn't you make a claim that you could fool it?
>>>
>>>>>> Which raises all sorts of questions regarding your previous usage 
>>>>>> of the term 'simulate'. Does your 'simulating decider' actually 
>>>>>> involve simulation at all?
>>>>>>
>>>>>> André
>>>>>>
>>>>>>
>>>>>
>>>>> The x86utm operating system is based on an x86 emulator that has 
>>>>> decades of development.
>>>>
>>>> That doesn't answer my question at all (and I don't know why you 
>>>> think anyone cares how many decades something has been under 
>>>> development).
>>>>
>>>> You consistently referred to your H as a 'simulating halt decider', 
>>>> but every time you present code snippets of H it shows H making a 
>>>> direct call to its input rather than invoking any kind of simulator.
>>>>
>>>> So is H actually the thing doing the simulation, or is H simply 
>>>> *being* simulated in much the same way as your so-called 'Simulate' 
>>>> function above is?
>>>>
>>>> André
>>>>
>>>
>>> Why can't you seem to stay focused on the key point at hand?
>>> Why do you diverge off on inconsequential trivialities?
>>
>> Because it *isn't* an inconsequential triviality. I'm trying to figure 
>> out the actual architecture of your system, and you are being 
>> deliberately unhelpful.
>>
>> Just because you don't understand why a particular question is being 
>> asked isn't a good reason to refuse to answer it. 
> 
> int Simulate(u32 P, u32 I)
> {
>    ((int(*)(int))P)(I);
>    return 1;
> }
> 
> // H and H2 are partial halt deciders
> u32 PSR_Decider(u32 P, u32 I)
> {
>    u32 Input_Halts1 = H((u32)P, (u32)I);
>    u32 Input_Halts2 = H2((u32)Simulate, (u32)P, (u32)I);
>    Output("Input_Halts1 = ", Input_Halts1);
>    Output("Input_Halts2 = ", Input_Halts2);
>    if (Input_Halts1 != Input_Halts2)
>      return 1;
>    return 0;
> }
> 
> void P(u32 x)
> {
>    if (H(x, x))
>      HERE: goto HERE;
> }
> 
> int main()
> {
>    Output("PSR_Decider = ", PSR_Decider((u32)P, (u32)P));
> }
> 
> The point of this post is whether or not my PSR_Decider() is correct.
> The name that I choose for my functions is not related to that.

I'm not asking about the name. I'm asking whether your "simulating halt 
decider" H actually performs any simulation or whether it is simply 
being simulated as you claim that 'Simulate' above is.

And once again you've failed to answer. It's a simple straightforward 
question. It can be answered in a single short sentence. So why not 
simply answer it rather than coming up with excuses for not answering it?

>> I can guarantee you that if you ever present your work in a *real* 
>> academic environment, you will be asked all sorts of questions of 
>> which you might not immediately see the relevance, and you *will* be 
>> expected to answer them.
>>
>>> If you think that you can fool my Pathological self-reference(Olcott 
>>> 2004) decider go ahead any try this. If it is impossible to fool it 
>>> then that proves that it is correct.
>>
>> How can anyone possible answer this?
>>
>> You've apparently now got two different halt decider, H1 and H2. You 
>> haven't provided even the vaguest description of what these things do 
>> or how they differ from one another.
>>
> 
> So before you ever read what I say you first make sure to forget 
> everything else that we have discussed.
> 
> The P of int main(){ P(P); } reaches its final state.
> The input to H(P,P) cannot possibly reach its final state.
> PSR_Decider() sees this difference.

So why are you using a different halt decider for each case? What's the 
different between H1 and H2? And why do you need Simulate at all? Why 
not just call H2(P, P) given that your 'simulate' is no more than a 
wrapper for a function call.

How is it that H2 *correctly* determines that P(P) does halt (or that 
Simulate(P, P) doesn't halt) whereas H1 incorrectly claims that P(P) 
doesn't halt? What's the difference between the criteria they are using?


> This difference only occurs when the input to the halt decider 
> contradicts whatever the halt decider decides. It picks out all of these 

But above that's not what you have. You have one halt decider (H1) 
contradicting some other halt decider (H2) (and on a different input) 
without providing any information about why these two deciders reach 
different conclusions.

André

> cases thus refutes Rice.
> 
>> You can't expect people to answer questions about code that you have 
>> not provided.
>>
>> André
>>
> 
> Try and do the same sort of trick that fools the halt decider to fool my 
> PSR_Decider(), you already claimed that you could do this didn't you?
> 


-- 
To email remove 'invalid' & replace 'gm' with well known Google mail 
service.

[toc] | [prev] | [next] | [standalone]

#37381

On 2021-07-30 17:01, André G. Isaak wrote:

> How is it that H2 *correctly* determines that P(P) does halt (or that 
> Simulate(P, P) doesn't halt) whereas H1 incorrectly claims that P(P) 
                  ^^^^^^^

Typo. That should say 'does'.

> doesn't halt? What's the difference between the criteria they are using?

André


-- 
To email remove 'invalid' & replace 'gm' with well known Google mail 
service.

[toc] | [prev] | [next] | [standalone]

#37383

On 7/30/2021 6:01 PM, André G. Isaak wrote:
> On 2021-07-30 16:43, olcott wrote:
>> On 7/30/2021 5:13 PM, André G. Isaak wrote:
>>> On 2021-07-30 15:53, olcott wrote:
>>>> On 7/30/2021 4:46 PM, André G. Isaak wrote:
>>>>> On 2021-07-30 11:11, olcott wrote:
>>>>>> On 7/30/2021 12:06 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-30 07:46, olcott wrote:
>>>>>>>
>>>>>>>> int Simulate(u32 P, u32 I)
>>>>>>>> {
>>>>>>>>    ((int(*)(int))P)(I);
>>>>>>>>    return 1;
>>>>>>>> }
>>>>>>>
>>>>>>> Why is this function called 'Simulate'?
>>>>>>>
>>>>>>> There's nothing remotely resembling simulation going on there. 
>>>>>>> The function is simply calling the function pointer that was 
>>>>>>> passed to it. That's execution, not simulation.
>>>>>>>
>>>>>>
>>>>>> It is the simplest possible function that is computationally 
>>>>>> equivalent to a simulation. Since every single instruction of the 
>>>>>> entire x86utm operating system is simulated the name is also 
>>>>>> literally true.
>>>>>
>>>>> Well, no, it isn't. The name 'simulator' suggests that this 
>>>>> function performs simulation. From what you suggest above, 
>>>>> 'simulator' is, itself, being simulated. That's something 
>>>>> altogether different which makes the name incredibly misleading.
>>>>>
>>>>
>>>> Then think of it as being named Big_Freds_Pizza(), the point is that 
>>>> my code seems to defeat Rice.
>>>>
>>>> Didn't you make a claim that you could fool it?
>>>>
>>>>>>> Which raises all sorts of questions regarding your previous usage 
>>>>>>> of the term 'simulate'. Does your 'simulating decider' actually 
>>>>>>> involve simulation at all?
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> The x86utm operating system is based on an x86 emulator that has 
>>>>>> decades of development.
>>>>>
>>>>> That doesn't answer my question at all (and I don't know why you 
>>>>> think anyone cares how many decades something has been under 
>>>>> development).
>>>>>
>>>>> You consistently referred to your H as a 'simulating halt decider', 
>>>>> but every time you present code snippets of H it shows H making a 
>>>>> direct call to its input rather than invoking any kind of simulator.
>>>>>
>>>>> So is H actually the thing doing the simulation, or is H simply 
>>>>> *being* simulated in much the same way as your so-called 'Simulate' 
>>>>> function above is?
>>>>>
>>>>> André
>>>>>
>>>>
>>>> Why can't you seem to stay focused on the key point at hand?
>>>> Why do you diverge off on inconsequential trivialities?
>>>
>>> Because it *isn't* an inconsequential triviality. I'm trying to 
>>> figure out the actual architecture of your system, and you are being 
>>> deliberately unhelpful.
>>>
>>> Just because you don't understand why a particular question is being 
>>> asked isn't a good reason to refuse to answer it. 
>>
>> int Simulate(u32 P, u32 I)
>> {
>>    ((int(*)(int))P)(I);
>>    return 1;
>> }
>>
>> // H and H2 are partial halt deciders
>> u32 PSR_Decider(u32 P, u32 I)
>> {
>>    u32 Input_Halts1 = H((u32)P, (u32)I);
>>    u32 Input_Halts2 = H2((u32)Simulate, (u32)P, (u32)I);
>>    Output("Input_Halts1 = ", Input_Halts1);
>>    Output("Input_Halts2 = ", Input_Halts2);
>>    if (Input_Halts1 != Input_Halts2)
>>      return 1;
>>    return 0;
>> }
>>
>> void P(u32 x)
>> {
>>    if (H(x, x))
>>      HERE: goto HERE;
>> }
>>
>> int main()
>> {
>>    Output("PSR_Decider = ", PSR_Decider((u32)P, (u32)P));
>> }
>>
>> The point of this post is whether or not my PSR_Decider() is correct.
>> The name that I choose for my functions is not related to that.
> 
> I'm not asking about the name. I'm asking whether your "simulating halt 
> decider" H actually performs any simulation or whether it is simply 
> being simulated as you claim that 'Simulate' above is.
> 
> And once again you've failed to answer. It's a simple straightforward 
> question. It can be answered in a single short sentence. So why not 
> simply answer it rather than coming up with excuses for not answering it?
> 

I have aready answered this many hundreds of times, asking the same 
quesition again seems quite disingenuous. Here is an additional detail 
that I have only provided about a dozen times:

This is *how* H simulates its slave process one x86 instruction at-a-time.

u32  DebugStep(Registers* master_state,
                Registers* slave_state,
                Decoded_Line_Of_Code* decoded) {}

master_state has the machine register values of H and slave_state has 
the machine register values of P. decoded has the simplified machine 
code that was executed.

>>> I can guarantee you that if you ever present your work in a *real* 
>>> academic environment, you will be asked all sorts of questions of 
>>> which you might not immediately see the relevance, and you *will* be 
>>> expected to answer them.
>>>
>>>> If you think that you can fool my Pathological self-reference(Olcott 
>>>> 2004) decider go ahead any try this. If it is impossible to fool it 
>>>> then that proves that it is correct.
>>>
>>> How can anyone possible answer this?
>>>
>>> You've apparently now got two different halt decider, H1 and H2. You 
>>> haven't provided even the vaguest description of what these things do 
>>> or how they differ from one another.
>>>
>>
>> So before you ever read what I say you first make sure to forget 
>> everything else that we have discussed.
>>
>> The P of int main(){ P(P); } reaches its final state.
>> The input to H(P,P) cannot possibly reach its final state.
>> PSR_Decider() sees this difference.
> 
> So why are you using a different halt decider for each case? What's the 
> different between H1 and H2? And why do you need Simulate at all? Why 
> not just call H2(P, P) given that your 'simulate' is no more than a 
> wrapper for a function call.
> 

H2 take three params so that it can execute the equivalent of
int main(){ P(P); }

> How is it that H2 *correctly* determines that P(P) does halt

P reaches its final state.

> (or that 
> Simulate(P, P) doesn't halt) 

Simulate does halt.

> whereas H1 incorrectly claims that P(P) 
> doesn't halt? 

H1 correctly determines that its input cannot possibly ever halt unless 
H1 aborts its simulation of P, thus perfectly matching the never halts 
criteria.

int main(){ P(P); } does halt.
H(P,P) correctly determines that its P(P) can't possibly halt.

This is like we correctly know for sure that all black cats are not 
black at all even though they are indeed definitely black cats.

> What's the difference between the criteria they are using?
> 

the following corresponds to main(){ P(P); }
 >>    u32 Input_Halts2 = H2((u32)Simulate, (u32)P, (u32)I);

int main(){ P(P); } and the input to H(P,P) are out-of-sync in that they 
exist at different points in the execution trace.

// This is the input to H that can't possibly halt
u32 Input_Halts1 = H((u32)P, (u32)I);

// This is the same as int main(){ P(P); } that halts.
u32 Input_Halts2 = H2((u32)Simulate, (u32)P, (u32)I);


>> This difference only occurs when the input to the halt decider 
>> contradicts whatever the halt decider decides. It picks out all of these 
> 
> But above that's not what you have. 

P does the opposite of whatever the halt decide decides

void P(u32 x)
{
    if (H(x, x))
      HERE: goto HERE;
}

u32 PSR_Decider(u32 P, u32 I); // finds all and only these cases.

> You have one halt decider (H1) 
> contradicting some other halt decider (H2) (and on a different input) 
> without providing any information about why these two deciders reach 
> different conclusions.
> 



> André
> 
>> cases thus refutes Rice.
>>
>>> You can't expect people to answer questions about code that you have 
>>> not provided.
>>>
>>> André
>>>
>>
>> Try and do the same sort of trick that fools the halt decider to fool 
>> my PSR_Decider(), you already claimed that you could do this didn't you?
>>
> 
> 


-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

[toc] | [prev] | [next] | [standalone]

#37391

On 2021-07-30 17:34, olcott wrote:
> On 7/30/2021 6:01 PM, André G. Isaak wrote:
>> On 2021-07-30 16:43, olcott wrote:
>>> On 7/30/2021 5:13 PM, André G. Isaak wrote:
>>>> On 2021-07-30 15:53, olcott wrote:
>>>>> On 7/30/2021 4:46 PM, André G. Isaak wrote:
>>>>>> On 2021-07-30 11:11, olcott wrote:
>>>>>>> On 7/30/2021 12:06 PM, André G. Isaak wrote:
>>>>>>>> On 2021-07-30 07:46, olcott wrote:
>>>>>>>>
>>>>>>>>> int Simulate(u32 P, u32 I)
>>>>>>>>> {
>>>>>>>>>    ((int(*)(int))P)(I);
>>>>>>>>>    return 1;
>>>>>>>>> }
>>>>>>>>
>>>>>>>> Why is this function called 'Simulate'?
>>>>>>>>
>>>>>>>> There's nothing remotely resembling simulation going on there. 
>>>>>>>> The function is simply calling the function pointer that was 
>>>>>>>> passed to it. That's execution, not simulation.
>>>>>>>>
>>>>>>>
>>>>>>> It is the simplest possible function that is computationally 
>>>>>>> equivalent to a simulation. Since every single instruction of the 
>>>>>>> entire x86utm operating system is simulated the name is also 
>>>>>>> literally true.
>>>>>>
>>>>>> Well, no, it isn't. The name 'simulator' suggests that this 
>>>>>> function performs simulation. From what you suggest above, 
>>>>>> 'simulator' is, itself, being simulated. That's something 
>>>>>> altogether different which makes the name incredibly misleading.
>>>>>>
>>>>>
>>>>> Then think of it as being named Big_Freds_Pizza(), the point is 
>>>>> that my code seems to defeat Rice.
>>>>>
>>>>> Didn't you make a claim that you could fool it?
>>>>>
>>>>>>>> Which raises all sorts of questions regarding your previous 
>>>>>>>> usage of the term 'simulate'. Does your 'simulating decider' 
>>>>>>>> actually involve simulation at all?
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> The x86utm operating system is based on an x86 emulator that has 
>>>>>>> decades of development.
>>>>>>
>>>>>> That doesn't answer my question at all (and I don't know why you 
>>>>>> think anyone cares how many decades something has been under 
>>>>>> development).
>>>>>>
>>>>>> You consistently referred to your H as a 'simulating halt 
>>>>>> decider', but every time you present code snippets of H it shows H 
>>>>>> making a direct call to its input rather than invoking any kind of 
>>>>>> simulator.
>>>>>>
>>>>>> So is H actually the thing doing the simulation, or is H simply 
>>>>>> *being* simulated in much the same way as your so-called 
>>>>>> 'Simulate' function above is?
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Why can't you seem to stay focused on the key point at hand?
>>>>> Why do you diverge off on inconsequential trivialities?
>>>>
>>>> Because it *isn't* an inconsequential triviality. I'm trying to 
>>>> figure out the actual architecture of your system, and you are being 
>>>> deliberately unhelpful.
>>>>
>>>> Just because you don't understand why a particular question is being 
>>>> asked isn't a good reason to refuse to answer it. 
>>>
>>> int Simulate(u32 P, u32 I)
>>> {
>>>    ((int(*)(int))P)(I);
>>>    return 1;
>>> }
>>>
>>> // H and H2 are partial halt deciders
>>> u32 PSR_Decider(u32 P, u32 I)
>>> {
>>>    u32 Input_Halts1 = H((u32)P, (u32)I);
>>>    u32 Input_Halts2 = H2((u32)Simulate, (u32)P, (u32)I);
>>>    Output("Input_Halts1 = ", Input_Halts1);
>>>    Output("Input_Halts2 = ", Input_Halts2);
>>>    if (Input_Halts1 != Input_Halts2)
>>>      return 1;
>>>    return 0;
>>> }
>>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("PSR_Decider = ", PSR_Decider((u32)P, (u32)P));
>>> }
>>>
>>> The point of this post is whether or not my PSR_Decider() is correct.
>>> The name that I choose for my functions is not related to that.
>>
>> I'm not asking about the name. I'm asking whether your "simulating 
>> halt decider" H actually performs any simulation or whether it is 
>> simply being simulated as you claim that 'Simulate' above is.
>>
>> And once again you've failed to answer. It's a simple straightforward 
>> question. It can be answered in a single short sentence. So why not 
>> simply answer it rather than coming up with excuses for not answering it?
>>
> 
> I have aready answered this many hundreds of times, asking the same 
> quesition again seems quite disingenuous. Here is an additional detail 
> that I have only provided about a dozen times:
> 
> This is *how* H simulates its slave process one x86 instruction at-a-time.
> 
> u32  DebugStep(Registers* master_state,
>                 Registers* slave_state,
>                 Decoded_Line_Of_Code* decoded) {}
> 
> master_state has the machine register values of H and slave_state has 
> the machine register values of P. decoded has the simplified machine 
> code that was executed.

That doesn't answer my question, though. I am interested in *where* the 
simulation actually takes place. Does H actually initialize the 
simulation and set up these state records, or is this something done by 
your "operating system".

When you call H(P, P) does the copy of H inside P set up a second set of 
register state records and initialize a new simulation or not?

Also, why would a simulation of P require *two* sets of register states? 
It should only require the state of the machine being simulated.

>>>> I can guarantee you that if you ever present your work in a *real* 
>>>> academic environment, you will be asked all sorts of questions of 
>>>> which you might not immediately see the relevance, and you *will* be 
>>>> expected to answer them.
>>>>
>>>>> If you think that you can fool my Pathological 
>>>>> self-reference(Olcott 2004) decider go ahead any try this. If it is 
>>>>> impossible to fool it then that proves that it is correct.
>>>>
>>>> How can anyone possible answer this?
>>>>
>>>> You've apparently now got two different halt decider, H1 and H2. You 
>>>> haven't provided even the vaguest description of what these things 
>>>> do or how they differ from one another.
>>>>
>>>
>>> So before you ever read what I say you first make sure to forget 
>>> everything else that we have discussed.
>>>
>>> The P of int main(){ P(P); } reaches its final state.
>>> The input to H(P,P) cannot possibly reach its final state.
>>> PSR_Decider() sees this difference.
>>
>> So why are you using a different halt decider for each case? What's 
>> the different between H1 and H2? And why do you need Simulate at all? 
>> Why not just call H2(P, P) given that your 'simulate' is no more than 
>> a wrapper for a function call.
>>
> 
> H2 take three params so that it can execute the equivalent of
> int main(){ P(P); }

P(P) is already the equivalent of int main() { P(P); }.

So H2(Simulate, P, P)

should return the exact same answer as

H1(P, P)

given that 'Simulate' is just a wrapper for P(P).

>> How is it that H2 *correctly* determines that P(P) does halt
> 
> P reaches its final state.

But how exactly is it that H2 gets this answer right when H1 gets the 
answer wrong?

>> (or that Simulate(P, P) doesn't halt) 
> 
> Simulate does halt.

Yes. That was a typo. I already corrected it.

>> whereas H1 incorrectly claims that P(P) doesn't halt? 
> 
> H1 correctly determines that its input cannot possibly ever halt unless 
> H1 aborts its simulation of P, thus perfectly matching the never halts 
> criteria.
 >
> int main(){ P(P); } does halt.

Yes. I get that. What I don't get is how your H2 manages to correctly 
determine this if it is using the same broken halting criteria as H1.

In both cases you have P(P) appearing as an input to your halt decider 
rather than as an independent computation.

André

-- 
To email remove 'invalid' & replace 'gm' with well known Google mail 
service.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.theory

csiph-web