On 5/9/22 7:00 PM, olcott wrote:
> On 5/9/2022 5:49 PM, Dennis Bush wrote:
>> On Monday, May 9, 2022 at 6:02:56 PM UTC-4, olcott wrote:
>>> On 5/9/2022 4:26 PM, Dennis Bush wrote:
>>>> On Monday, May 9, 2022 at 5:01:47 PM UTC-4, olcott wrote:
>>>>> On 5/9/2022 3:37 PM, Dennis Bush wrote:
>>>>>> On Monday, May 9, 2022 at 4:21:21 PM UTC-4, olcott wrote:
>>>>>>> On 5/9/2022 1:36 PM, wij wrote:
>>>>>>>> On Tuesday, 10 May 2022 at 02:13:22 UTC+8, olcott wrote:
>>>>>>>>> On 5/9/2022 1:10 PM, wij wrote:
>>>>>>>>>> On Tuesday, 10 May 2022 at 01:44:28 UTC+8, olcott wrote:
>>>>>>>>>>> On 5/9/2022 12:35 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Mon, 9 May 2022 10:57:39 -0500
>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5/8/2022 5:46 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> Based on the assumption that [Strachey, 1965] is not actually
>>>>>>>>>>>>>> advocating running a program (either through direct
>>>>>>>>>>>>>> execution or by
>>>>>>>>>>>>>> simulation) to determine if that program halts Strachey's
>>>>>>>>>>>>>> "Impossible Program" is indeed impossible for the reason
>>>>>>>>>>>>>> given (the
>>>>>>>>>>>>>> contradiction).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The only open question in my mind is what it actually
>>>>>>>>>>>>>> means for a
>>>>>>>>>>>>>> decider to evaluate the source code of itself in addition
>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>> source code of the program which would invoke the decider
>>>>>>>>>>>>>> if it
>>>>>>>>>>>>>> actually was run.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I was wrong. Apologies for the noise.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You were correct that the input never reaches its
>>>>>>>>>>>>> impossible part
>>>>>>>>>>>>> because it is stuck in infinite recursion.
>>>>>>>>>>>>
>>>>>>>>>>>> Have you not read my retraction? I was in error: there is no
>>>>>>>>>>>> infinite
>>>>>>>>>>>> recursion.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This only occurs if the halt decider H is a simulating halt
>>>>>>>>>>>>> decider.
>>>>>>>>>>>>> When the input to H(P,P) does get stuck in infinite
>>>>>>>>>>>>> recursion H can
>>>>>>>>>>>>> see this.
>>>>>>>>>>>>
>>>>>>>>>>>> Simulation is an erroneous approach.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>> I have proven otherwise:
>>>>>>>>>>>
>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>>>>>
>>>>>>>>>>> "Talent hits a target no one else can hit;
>>>>>>>>>>> Genius hits a target no one else can see."
>>>>>>>>>>> Arthur Schopenhauer
>>>>>>>>>>
>>>>>>>>>> According to GUR, your proof is wrong:
>>>>>>>>>> GUR says "No TM U can decide the property of a TM P if that
>>>>>>>>>> property can be defied by TM P."
>>>>>>>>> According to my proof GUR is wrong. You have to actually read
>>>>>>>>> it to see
>>>>>>>>> this.
>>>>>>>>> --
>>>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>>>
>>>>>>>>> "Talent hits a target no one else can hit;
>>>>>>>>> Genius hits a target no one else can see."
>>>>>>>>> Arthur Schopenhauer
>>>>>>>>
>>>>>>>> Any halting decider is shown/proved not able to return a correct
>>>>>>>> answer.
>>>>>>> All deciders must compute the mapping from their inputs to an
>>>>>>> accept/reject state on the basis of a property of these inputs thus
>>>>>>
>>>>>> And for the halting function, the property of the inputs is the
>>>>>> representation of a turning machine and the input to that machine
>>>>> No not at all. There is no (indirect reference) of "representation" to
>>>>> it.
>>>>>
>>>>
>>>> There is by the definition of the problem.
>>>>
>>>>> The input is a literal string that precisely specifies a sequence of
>>>>> configurations. In this case it is x86 machine code.
>>>>>>>
>>>>>>> All halt deciders must compute the mapping from their inputs to an
>>>>>>> accept/reject state on the basis of a the actual behavior
>>>>>>> specified by
>>>>>>> these actual inputs.
>>>>>>
>>>>>> And by definition, the actual behavior specified by the actual
>>>>>> inputs is the behavior of the turing machine represented by the
>>>>>> first input whose input is the second input.
>>>>> No not at all. There is no (indirect reference) of "representation" to
>>>>> it. The input is a literal string that precisely specifies a
>>>>> sequence of
>>>>> configurations. In this case it is x86 machine code.
>>>>>> i.e. the the actual behavior specified by the actual inputs to
>>>>>> H(P,P) is the behavior of P(P) *by the definition of the problem*.
>>>>> No not at all. There is no (indirect reference) of "representation" to
>>>>> it. The input is a literal string that precisely specifies a
>>>>> sequence of
>>>>> configurations. In this case it is x86 machine code.
>>>>>
>>>>> Either you are interpreting "representation" incorrectly or the
>>>>> statement of the problem never noticed that it directly contradicts
>>>>> the
>>>>> definition of a decider in some rare cases.
>>>>
>>>> You mean this definition of a decider?
>>>>
>>>> https://cs.stackexchange.com/a/84440
>>>>
>>>> The one you "always accepted ... as the best one"?
>>>>
>>>> All this says is that a decider maps input to accept/reject.
>>>> It doesn't say anything about *how* that mapping occurs.
>>> Now we are getting into nuances of meaning that are not commonly known.
>>>
>>> It must do so in the basis of a property specified by its input finite
>>> string.
>>
>> And for a halt decider H(P,P), the specified property *by definition*
>> is the behavior of P(P)
>>
>>>
>>> For example a decider that decides whether or not its input has a string
>>> length > 20 will simply base its decision on the actual length of the
>>> actual input string.
>>>
>>> Another decider may determine if the string contains: "the". Deciders
>>> always decide on the basis of what the finite string actually specifies,
>>> not what someone imagines that these strings "should" specify.
>>>
>>> For the halt deciders this property is the actual behavior actually
>>> specified by these finite strings.
>>
>> Which by *the definition of the problem*, for a halt decider H(P,P),
>> that property is the behavior of P(P)
>>
>>> We already know that the correct
>>> simulation of an input is the ultimate measure of the behavior of this
>>> input.
>>
>> And the correct simulation of the input to H(P,P) is by definition
>> UTM(P,P) because it is equivalent to the behavior of the direct
>> execution of P(P)
>
>
> void P(u32 x)
> {
>   if (x86_emulate(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> Yet the UTM must be embedded at the same place where H would be
> embedded. The above P would never stop running.
>
>

Nope, the UTM is a totally seperate computation.

Where do you see put a UTM in the place of copies of the decider while
simulating the input? (or words to that effect)

You just run a UTM on the input as an independent computation to verify
that the answer was correct.