On Tuesday, 10 May 2022 at 07:00:22 UTC+8, 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.
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

I have replied with the major problem of your rebuttal in another post:
https://groups.google.com/g/comp.theory/c/GajNoV6CAz4
I.e. no H, no rebuttal. All in your paper has no effect to the HP proof.

The second one:
The real P is a test program. P cannot exist before the existence of H and
the 'H' inside P is a functional equivalent thing (it may be in Lisp, C,TM,x86,...
even nothing apparent to do H), CPU sees only machine codes (or TM, symbols),
and all machine codes (byte string) are valid to the CPU (no such issues like loop,
recursive,...). This replies your 'recursive' or 'pathological' myth.