On 5/7/2022 6:10 PM, wij wrote:
> On Sunday, 8 May 2022 at 05:50:43 UTC+8, olcott wrote:
>> On 4/23/2022 12:29 PM, wij wrote:
>>> On Sunday, 24 April 2022 at 01:20:23 UTC+8, olcott wrote:
>>>> On 4/23/2022 12:15 PM, wij wrote:
>>>>> On Sunday, 24 April 2022 at 00:52:00 UTC+8, olcott wrote:
>>>>>> On 4/23/2022 11:43 AM, wij wrote:
>>>>>>> On Sunday, 24 April 2022 at 00:34:55 UTC+8, olcott wrote:
>>>>>>>> On 4/23/2022 11:29 AM, wij wrote:
>>>>>>>>> On Sunday, 24 April 2022 at 00:05:19 UTC+8, olcott wrote:
>>>>>>>>>> On 4/23/2022 10:58 AM, wij wrote:
>>>>>>>>>>> On Saturday, 23 April 2022 at 22:49:59 UTC+8, olcott wrote:
>>>>>>>>>>>> All of my reviewers expect H(P,P) to compute the halt status of P(P),
>>>>>>>>>>>> yet the behavior specified by the input to H(P,P) is not the same as the
>>>>>>>>>>>> behavior specified by P(P).
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> If using this common concept, the halting decider H, when given an argument P
>>>>>>>>>>> (or P P), is supposed to answer whether P(P) will halt or not. This is a very
>>>>>>>>>>> simple, easy idea to understand even for teenager students.
>>>>>>>>>>>
>>>>>>>>>> When this very simple idea is very rigorously examined (as it is in my
>>>>>>>>>> paper) one sees that this requires the halt decider to be a mind reader
>>>>>>>>>> and compute the halt status other than the actual halt status specified
>>>>>>>>>> by its actual input.
>>>>>>>>>
>>>>>>>>> Your wording/interpretations/paper change all the time. No idea what this new
>>>>>>>>> excuse 'mind reader' might mean. As said, the Halting Problem is very simple
>>>>>>>>> and intuitive.
>>>>>>>>> H should be a decider that computes the actual halt status of P(P). P is the
>>>>>>>>> H's actual argument input.
>>>>>>>>> I expect you might try to find some bugs of those descriptions to rephrasing it
>>>>>>>>> in your favor. But, what would be the point? What is the usefulness of POOP?
>>>>>>>> Yet when you carefully examine my paper:
>>>>>>>> Anyone that is an expert in the C programming language, the x86
>>>>>>>> programming language, exactly how C translates into x86 and what an x86
>>>>>>>> processor emulator is can easily verify that the correctly simulated
>>>>>>>> input to H(P,P) by H specifies a non-halting sequence of configurations.
>>>>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>>>>
>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>> Simply ignoring the verified facts is a ridiculously foolish was to form
>>>>>>>> any actual rebuttal.
>>>>>>>> --
>>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>>
>>>>>>>> "Talent hits a target no one else can hit;
>>>>>>>> Genius hits a target no one else can see."
>>>>>>>> Arthur Schopenhauer
>>>>>>>
>>>>>>> You already verified the fact that H(P,P) will be in an infinite recursive call
>>>>>>> (thus, undecidable). Why you say H(P,P)==false (or true)?
>>>>>> You might make a wild guess like this if you make sure to hardly pay
>>>>>> attention. When you actually pay close attention and carefully study my
>>>>>> paper it is very easy to see that H sees the same infinitely repeating
>>>>>> pattern that we see, thus can abort its simulation and reject its input.
>>>>>> Begin Local Halt Decider Simulation
>>>>>>
>>>>>> machine stack stack machine assembly
>>>>>> address address data code language
>>>>>> ======== ======== ======== ========= =============
>>>>>> ...[000009d6][00211368][0021136c] 55 push ebp // enter P
>>>>>> ...[000009d7][00211368][0021136c] 8bec mov ebp,esp
>>>>>> ...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
>>>>>> ...[000009dc][00211364][000009d6] 50 push eax // Push P
>>>>>> ...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
>>>>>> ...[000009e0][00211360][000009d6] 51 push ecx // Push P
>>>>>> ...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
>>>>>> ...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
>>>>>> ...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
>>>>>> ...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
>>>>>> ...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
>>>>>> ...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
>>>>>> ...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
>>>>>> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>>
>>>>>> 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
>>>>>
>>>>> "Local Halt Decider: Infinite Recursion Detected Simulation Stopped" means
>>>>> your x86utm emulator has encountered an infinite recursive call.
>>>>> This is referred to as "undecidable". This is the fact.
>>>> So you are saying that after H makes the correct halt status decision
>>>> that this correct halt status decision is impossible to make.
>>>>
>>>> That is just like my example a smashing a Boston cream pie in your face
>>>> and while this pie drips from your face you deny that the pie exists.
>>>
>>> Your H did not show 'correct decision' but 'unreachable' (exactly what the HP says).
>>>
>>> This is like "0.999..." (or repeating decimal) problems: Infinite repeating
>>> simply means INFINITE repeating. Please, respect what it is.
>> My H proves that H(P,P)== false
>> on the basis that H does correctly compute the mapping from its input
>> parameters to its own final reject state on the basis of the actual
>> behavior actually specified by its input parameters.
>>
>> The details of this are shown here:
>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>
>> A bunch of goofy people here do not understand that this meets the
>> definition of a correct halt decider.
>>
>> They believe that H must compute a mapping from non-inputs. This is
>> quite nuts because they already know that no decider can ever do 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
>
> There is no "return false" in the execution trace of your H.
> Your H run in infinite recursive calls, it demonstrates H(P,P)==Undecidable.
>
> You only need to show a 'H' that GUR can fail (or the conventional HP proof).

This earlier paper has more details:
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

olcott <NoOne@NoWhere.com> writes:

> A bunch of goofy people here do not understand that this meets the
> definition of a correct halt decider.

You have had some limited support from a poster who thinks the CIA edits
their Usenet posts, and from another using the name Mr Flibble. And
/we're/ the goofy ones?

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

On Sun, 08 May 2022 01:12:42 +0100
Ben <ben.usenet@bsb.me.uk> wrote:

> olcott <NoOne@NoWhere.com> writes:
>
> > A bunch of goofy people here do not understand that this meets the
> > definition of a correct halt decider.
>
> You have had some limited support from a poster who thinks the CIA
> edits their Usenet posts, and from another using the name Mr Flibble.
> And /we're/ the goofy ones?
Ben who?

/Flibble

On 5/7/2022 7:12 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> A bunch of goofy people here do not understand that this meets the
>> definition of a correct halt decider.
>
> You have had some limited support from a poster who thinks the CIA edits
> their Usenet posts, and from another using the name Mr Flibble. And
> /we're/ the goofy ones?
>

On 5/7/2022 7:19 PM, olcott wrote:
> On 5/7/2022 6:35 PM, Dennis Bush wrote:
>> The *definition* of the problem states that the actual behavior of the
>> actual input to H(P,P) is P(P).
>
> Whomever wrote that definition also knows that
>
> THIS IS SET IN STONE:
> All deciders only compute the mapping from their input parameters to an
> accept/reject state on the basis of the actual properties actually
> specified by this input
>
> THIS LOGICALLY FOLLOWS FROM THAT:
> Since a halt decider is a type of decider this means that all halt
> deciders only compute the mapping from their input parameters to an
> accept/reject state on the basis of the actual behavior actually
> specified by this input.
>
> This means that they simply made the false assumption that the correctly
> simulated input to every simulating halt decider must always have
> exactly the same behavior as the direct execution of this input.
>
> It is a weird exception that they never noticed because they never
> bothered to pursue simulating halt deciders applied to the HP to its
> logical conclusion.

The requirements contradict the definition of a decider.
The author of these requirements was not aware of that.

--
Copyright 2022 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 5/7/2022 7:12 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> A bunch of goofy people here do not understand that this meets the
>>> definition of a correct halt decider.
>>
>> You have had some limited support from a poster who thinks the CIA edits
>> their Usenet posts, and from another using the name Mr Flibble. And
>> /we're/ the goofy ones?

> The requirements contradict the definition of a decider.

No. It us unlikely you will ever concede this point, so all you have to
offer now is a back and forth endless loop. I offered to help you see
why you are wrong, but you failed to write even the simplest Turing
machine and have so far refused to define another.

Maybe it's just time to try to publish your great paper: "How everyone
made a mistake and a halt decider is correct to reject at least one
input that encodes a finite computation". No, that's too clear, but if
you waffle and are vague about "the behaviour specified by the input"
then it goes straight into the editor's bin.

I think you are stuck here for the time being.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

On 5/7/22 8:24 PM, olcott wrote:
> On 5/7/2022 7:12 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> A bunch of goofy people here do not understand that this meets the
>>> definition of a correct halt decider.
>>
>> You have had some limited support from a poster who thinks the CIA edits
>> their Usenet posts, and from another using the name Mr Flibble.  And
>> /we're/ the goofy ones?
>>
>
> On 5/7/2022 7:19 PM, olcott wrote:
> > On 5/7/2022 6:35 PM, Dennis Bush wrote:
> >> The *definition* of the problem states that the actual behavior of the
> >> actual input to H(P,P) is P(P).
> >
> > Whomever wrote that definition also knows that
> >
> > THIS IS SET IN STONE:
> > All deciders only compute the mapping from their input parameters to an
> > accept/reject state on the basis of the actual properties actually
> > specified by this input
> >
> > THIS LOGICALLY FOLLOWS FROM THAT:
> > Since a halt decider is a type of decider this means that all halt
> > deciders only compute the mapping from their input parameters to an
> > accept/reject state on the basis of the actual behavior actually
> > specified by this input.
> >
> > This means that they simply made the false assumption that the correctly
> > simulated input to every simulating halt decider must always have
> > exactly the same behavior as the direct execution of this input.
> >
> > It is a weird exception that they never noticed because they never
> > bothered to pursue simulating halt deciders applied to the HP to its
> > logical conclusion.
>
> The requirements contradict the definition of a decider.
> The author of these requirements was not aware of that.
>

Nope, YOUR "requirements" contradict the definition of a xyz decider.

The only requirement of just a "decider" is that it halts on all inputs,
which means it incidentally computes SOME mapping of input to output,
but that mapping isn't specified by the term "decider"

To be a xyz decider, that mapping it computes must match the xyz mapping.

For Halting, the mapping of M,w is the mapping of M,w to whether M
applied to w will Halt (or M(w) halts in function notation).

You are REJECTING this definitin, so you aren't using the right
definition, and you logic is just flawed.