On Tue, 5 Jul 2022 16:05:28 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/5/2022 4:01 PM, Mr Flibble wrote:
> > On Tue, 5 Jul 2022 15:16:56 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/5/2022 2:54 PM, wij wrote:
> >>> On Wednesday, 6 July 2022 at 03:33:51 UTC+8, olcott wrote:
> >>>> On 7/5/2022 1:49 PM, wij wrote:
> >>>>> On Monday, 4 July 2022 at 02:00:00 UTC+8, Mr Flibble wrote:
> >>>>>> On Sun, 3 Jul 2022 10:57:40 -0700 (PDT)
> >>>>>> wij <wyni...@gmail.com> wrote:
> >>>>>>
> >>>>>>> On Monday, 4 July 2022 at 01:31:46 UTC+8, Mr Flibble wrote:
> >>>>>>>> Hi!
> >>>>>>>>
> >>>>>>>> I have an idea for a simulating halt decider that forks the
> >>>>>>>> simulation into two branches if the input calls the halt
> >>>>>>>> decider as per [Strachey 1965]'s "Impossible Program":
> >>>>>>>>
> >>>>>>>> void P(void (*x)())
> >>>>>>>> {
> >>>>>>>> if (H(x, x))
> >>>>>>>> infinite_loop: goto infinite_loop;
> >>>>>>>> return;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> int main()
> >>>>>>>> {
> >>>>>>>> std::cout << "Input halts: " << H(P, P) << std::endl;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> When the simulator detects the call to H in P it forks the
> >>>>>>>> simulation into a non-halting branch (returning 0 to P) and a
> >>>>>>>> halting branch (returning 1 to P) and continues the
> >>>>>>>> simulation of these two branches in parallel.
> >>>>>>>>
> >>>>>>>> If the non-halting branch is determined to halt AND the
> >>>>>>>> halting branch is determined to not halt then pathology is
> >>>>>>>> detected and reported.
> >>>>>>>>
> >>>>>>>> If EITHER branch is determined to be correctly decided then
> >>>>>>>> that will be the decision of the halting decider.
> >>>>>>>>
> >>>>>>>> Crucially this scheme will handle (and correctly decide) the
> >>>>>>>> following case whereby the result of H is discarded by the
> >>>>>>>> input:
> >>>>>>>>
> >>>>>>>> void Px(void (*x)())
> >>>>>>>> {
> >>>>>>>> (void) H(x, x);
> >>>>>>>> return;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> Thoughts? I am probably missing something obvious.
> >>>>>>>>
> >>>>>>>> /Flibble
> >>>>>>>
> >>>>>>> You should declare copyright first, then public the source
> >>>>>>> before olcott does. Although I don't think olcott has
> >>>>>>> technical competent enough data to sue you, less trouble is
> >>>>>>> always better.
> >>>>>> No need, the timestamps of the Usenet posts should be
> >>>>>> sufficient to prove prior art. :)
> >>>>>>
> >>>>>> /Flibble
> >>>>>
> >>>>> The idea of fork-simulation halting decider indeed looked much
> >>>>> advanced and promising than the oral-based halting decider
> >>>>> (POOH). Chance might be good refuting the HP. comp.theory user
> >>>>> might help you enrich the original idea if you would share more
> >>>>> brilliant thought.
> >>>> So basically you do not understand that it is flat out incorrect
> >>>> for a function called in infinite recursion to ever return to its
> >>>> caller.
> >>>>> My idea of the copyright is that if no one announce it,
> >>>>> copyright does not exist. Probable like the car speeding if not
> >>>>> get caught, no breaking of the law exists (IMO).
> >>>> --
> >>>> 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 think Mr Flibble's fork-simulation halting decider is brilliant,
> >>> original, and could be a better candidate to refute the HP. But it
> >>> is just so far unfinished.
> >>
> >> Yet Flibble does not even understand that code following an
> >> infinitely recursive function call is dead code that is never
> >> reached.
> >
> > My fork-simulation halting decider is NOT infinitely recursive as it
> > returns a value to its caller on each branch. It is your erroneous
> > decider that has an issue with infinite recursion. [Strachey 1965]
> > is NOT recursive so neither is my solution.
> >
> >>
> >> His forking idea merely makes infinite forks of infinitely nested
> >> emulation. The emulations are already executed in a separate
> >> process so they are already forked.
> >
> > No it doesn't as it isn't recursive; the simulator will create two
> > branches each time the decider is called from the input and the
> > decider will return halting and non-halting for each branch -- no
> > recursion.
> >
> > /Flibble
> >
> So it contradicts itself.
It doesn't contradict itself but if there is a "contradiction" then the
"Impossible Program" is being asserted which will result in my decider
signaling an exception due to the input being pathological. Try
CAREFULLY reading my original post again in its entirety.

Your idea of equating infinite recursion due to "Impossible
Program" pathology (which you don't even check for, you just assume
it) with the state of non-halting is bogus.

/Flibble

On 7/5/2022 4:14 PM, Mr Flibble wrote:
> On Tue, 5 Jul 2022 16:05:28 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/5/2022 4:01 PM, Mr Flibble wrote:
>>> On Tue, 5 Jul 2022 15:16:56 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/5/2022 2:54 PM, wij wrote:
>>>>> On Wednesday, 6 July 2022 at 03:33:51 UTC+8, olcott wrote:
>>>>>> On 7/5/2022 1:49 PM, wij wrote:
>>>>>>> On Monday, 4 July 2022 at 02:00:00 UTC+8, Mr Flibble wrote:
>>>>>>>> On Sun, 3 Jul 2022 10:57:40 -0700 (PDT)
>>>>>>>> wij <wyni...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On Monday, 4 July 2022 at 01:31:46 UTC+8, Mr Flibble wrote:
>>>>>>>>>> Hi!
>>>>>>>>>>
>>>>>>>>>> I have an idea for a simulating halt decider that forks the
>>>>>>>>>> simulation into two branches if the input calls the halt
>>>>>>>>>> decider as per [Strachey 1965]'s "Impossible Program":
>>>>>>>>>>
>>>>>>>>>> void P(void (*x)())
>>>>>>>>>> {
>>>>>>>>>> if (H(x, x))
>>>>>>>>>> infinite_loop: goto infinite_loop;
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> std::cout << "Input halts: " << H(P, P) << std::endl;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> When the simulator detects the call to H in P it forks the
>>>>>>>>>> simulation into a non-halting branch (returning 0 to P) and a
>>>>>>>>>> halting branch (returning 1 to P) and continues the
>>>>>>>>>> simulation of these two branches in parallel.
>>>>>>>>>>
>>>>>>>>>> If the non-halting branch is determined to halt AND the
>>>>>>>>>> halting branch is determined to not halt then pathology is
>>>>>>>>>> detected and reported.
>>>>>>>>>>
>>>>>>>>>> If EITHER branch is determined to be correctly decided then
>>>>>>>>>> that will be the decision of the halting decider.
>>>>>>>>>>
>>>>>>>>>> Crucially this scheme will handle (and correctly decide) the
>>>>>>>>>> following case whereby the result of H is discarded by the
>>>>>>>>>> input:
>>>>>>>>>>
>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>> {
>>>>>>>>>> (void) H(x, x);
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Thoughts? I am probably missing something obvious.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> You should declare copyright first, then public the source
>>>>>>>>> before olcott does. Although I don't think olcott has
>>>>>>>>> technical competent enough data to sue you, less trouble is
>>>>>>>>> always better.
>>>>>>>> No need, the timestamps of the Usenet posts should be
>>>>>>>> sufficient to prove prior art. :)
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> The idea of fork-simulation halting decider indeed looked much
>>>>>>> advanced and promising than the oral-based halting decider
>>>>>>> (POOH). Chance might be good refuting the HP. comp.theory user
>>>>>>> might help you enrich the original idea if you would share more
>>>>>>> brilliant thought.
>>>>>> So basically you do not understand that it is flat out incorrect
>>>>>> for a function called in infinite recursion to ever return to its
>>>>>> caller.
>>>>>>> My idea of the copyright is that if no one announce it,
>>>>>>> copyright does not exist. Probable like the car speeding if not
>>>>>>> get caught, no breaking of the law exists (IMO).
>>>>>> --
>>>>>> 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 think Mr Flibble's fork-simulation halting decider is brilliant,
>>>>> original, and could be a better candidate to refute the HP. But it
>>>>> is just so far unfinished.
>>>>
>>>> Yet Flibble does not even understand that code following an
>>>> infinitely recursive function call is dead code that is never
>>>> reached.
>>>
>>> My fork-simulation halting decider is NOT infinitely recursive as it
>>> returns a value to its caller on each branch. It is your erroneous
>>> decider that has an issue with infinite recursion. [Strachey 1965]
>>> is NOT recursive so neither is my solution.
>>>
>>>>
>>>> His forking idea merely makes infinite forks of infinitely nested
>>>> emulation. The emulations are already executed in a separate
>>>> process so they are already forked.
>>>
>>> No it doesn't as it isn't recursive; the simulator will create two
>>> branches each time the decider is called from the input and the
>>> decider will return halting and non-halting for each branch -- no
>>> recursion.
>>>
>>> /Flibble
>>>
>> So it contradicts itself.
>
> It doesn't contradict itself but if there is a "contradiction" then the
> "Impossible Program" is being asserted which will result in my decider
> signaling an exception due to the input being pathological. Try
> CAREFULLY reading my original post again in its entirety.
>
> Your idea of equating infinite recursion due to "Impossible
> Program" pathology (which you don't even check for, you just assume
> it) with the state of non-halting is bogus.
>
> /Flibble
>

Then the correct way to do this is not that the input both halts and
does not halt, (a contradiction) the correct way to do this would be:
Does the input halt ? is not a truth bearer thus is neither true nor false.

Because the input to H(P,P) is proven:

From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input would
never reach the "ret" instruction (final state) of this input.

This is the wrong answer for H(P,P).

*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

*Only to those having the required software engineering prerequisites*

The start state, state transitions inbetween and the final state of a
computation can be construed as a formal proof from premises to conclusion.

--
Copyright 2022 Pete Olcott

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

On Tue, 5 Jul 2022 16:23:48 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/5/2022 4:14 PM, Mr Flibble wrote:
> > On Tue, 5 Jul 2022 16:05:28 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/5/2022 4:01 PM, Mr Flibble wrote:
> >>> On Tue, 5 Jul 2022 15:16:56 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/5/2022 2:54 PM, wij wrote:
> >>>>> On Wednesday, 6 July 2022 at 03:33:51 UTC+8, olcott wrote:
> >>>>>> On 7/5/2022 1:49 PM, wij wrote:
> >>>>>>> On Monday, 4 July 2022 at 02:00:00 UTC+8, Mr Flibble wrote:
> >>>>>>>> On Sun, 3 Jul 2022 10:57:40 -0700 (PDT)
> >>>>>>>> wij <wyni...@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>> On Monday, 4 July 2022 at 01:31:46 UTC+8, Mr Flibble wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi!
> >>>>>>>>>>
> >>>>>>>>>> I have an idea for a simulating halt decider that forks the
> >>>>>>>>>> simulation into two branches if the input calls the halt
> >>>>>>>>>> decider as per [Strachey 1965]'s "Impossible Program":
> >>>>>>>>>>
> >>>>>>>>>> void P(void (*x)())
> >>>>>>>>>> {
> >>>>>>>>>> if (H(x, x))
> >>>>>>>>>> infinite_loop: goto infinite_loop;
> >>>>>>>>>> return;
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> int main()
> >>>>>>>>>> {
> >>>>>>>>>> std::cout << "Input halts: " << H(P, P) << std::endl;
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> When the simulator detects the call to H in P it forks the
> >>>>>>>>>> simulation into a non-halting branch (returning 0 to P)
> >>>>>>>>>> and a halting branch (returning 1 to P) and continues the
> >>>>>>>>>> simulation of these two branches in parallel.
> >>>>>>>>>>
> >>>>>>>>>> If the non-halting branch is determined to halt AND the
> >>>>>>>>>> halting branch is determined to not halt then pathology is
> >>>>>>>>>> detected and reported.
> >>>>>>>>>>
> >>>>>>>>>> If EITHER branch is determined to be correctly decided then
> >>>>>>>>>> that will be the decision of the halting decider.
> >>>>>>>>>>
> >>>>>>>>>> Crucially this scheme will handle (and correctly decide)
> >>>>>>>>>> the following case whereby the result of H is discarded by
> >>>>>>>>>> the input:
> >>>>>>>>>>
> >>>>>>>>>> void Px(void (*x)())
> >>>>>>>>>> {
> >>>>>>>>>> (void) H(x, x);
> >>>>>>>>>> return;
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> Thoughts? I am probably missing something obvious.
> >>>>>>>>>>
> >>>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>> You should declare copyright first, then public the source
> >>>>>>>>> before olcott does. Although I don't think olcott has
> >>>>>>>>> technical competent enough data to sue you, less trouble is
> >>>>>>>>> always better.
> >>>>>>>> No need, the timestamps of the Usenet posts should be
> >>>>>>>> sufficient to prove prior art. :)
> >>>>>>>>
> >>>>>>>> /Flibble
> >>>>>>>
> >>>>>>> The idea of fork-simulation halting decider indeed looked much
> >>>>>>> advanced and promising than the oral-based halting decider
> >>>>>>> (POOH). Chance might be good refuting the HP. comp.theory user
> >>>>>>> might help you enrich the original idea if you would share
> >>>>>>> more brilliant thought.
> >>>>>> So basically you do not understand that it is flat out
> >>>>>> incorrect for a function called in infinite recursion to ever
> >>>>>> return to its caller.
> >>>>>>> My idea of the copyright is that if no one announce it,
> >>>>>>> copyright does not exist. Probable like the car speeding if
> >>>>>>> not get caught, no breaking of the law exists (IMO).
> >>>>>> --
> >>>>>> 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 think Mr Flibble's fork-simulation halting decider is
> >>>>> brilliant, original, and could be a better candidate to refute
> >>>>> the HP. But it is just so far unfinished.
> >>>>
> >>>> Yet Flibble does not even understand that code following an
> >>>> infinitely recursive function call is dead code that is never
> >>>> reached.
> >>>
> >>> My fork-simulation halting decider is NOT infinitely recursive as
> >>> it returns a value to its caller on each branch. It is your
> >>> erroneous decider that has an issue with infinite recursion.
> >>> [Strachey 1965] is NOT recursive so neither is my solution.
> >>>
> >>>>
> >>>> His forking idea merely makes infinite forks of infinitely nested
> >>>> emulation. The emulations are already executed in a separate
> >>>> process so they are already forked.
> >>>
> >>> No it doesn't as it isn't recursive; the simulator will create two
> >>> branches each time the decider is called from the input and the
> >>> decider will return halting and non-halting for each branch -- no
> >>> recursion.
> >>>
> >>> /Flibble
> >>>
> >> So it contradicts itself.
> >
> > It doesn't contradict itself but if there is a "contradiction" then
> > the "Impossible Program" is being asserted which will result in my
> > decider signaling an exception due to the input being pathological.
> > Try CAREFULLY reading my original post again in its entirety.
> >
> > Your idea of equating infinite recursion due to "Impossible
> > Program" pathology (which you don't even check for, you just assume
> > it) with the state of non-halting is bogus.
> >
> > /Flibble
> >
>
> Then the correct way to do this is not that the input both halts and
> does not halt, (a contradiction) the correct way to do this would be:
> Does the input halt ? is not a truth bearer thus is neither true nor
> false.

The correct way to do it is to raise an exception if there is a
contradiction rather than artificially claiming non-halting based on
some supposed infinite recursion which is only a property of your
erroneous solution.

/Flibble

On 7/5/2022 5:53 PM, Mr Flibble wrote:
> On Tue, 5 Jul 2022 16:23:48 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/5/2022 4:14 PM, Mr Flibble wrote:
>>> On Tue, 5 Jul 2022 16:05:28 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/5/2022 4:01 PM, Mr Flibble wrote:
>>>>> On Tue, 5 Jul 2022 15:16:56 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 7/5/2022 2:54 PM, wij wrote:
>>>>>>> On Wednesday, 6 July 2022 at 03:33:51 UTC+8, olcott wrote:
>>>>>>>> On 7/5/2022 1:49 PM, wij wrote:
>>>>>>>>> On Monday, 4 July 2022 at 02:00:00 UTC+8, Mr Flibble wrote:
>>>>>>>>>> On Sun, 3 Jul 2022 10:57:40 -0700 (PDT)
>>>>>>>>>> wij <wyni...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Monday, 4 July 2022 at 01:31:46 UTC+8, Mr Flibble wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi!
>>>>>>>>>>>>
>>>>>>>>>>>> I have an idea for a simulating halt decider that forks the
>>>>>>>>>>>> simulation into two branches if the input calls the halt
>>>>>>>>>>>> decider as per [Strachey 1965]'s "Impossible Program":
>>>>>>>>>>>>
>>>>>>>>>>>> void P(void (*x)())
>>>>>>>>>>>> {
>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>> infinite_loop: goto infinite_loop;
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> std::cout << "Input halts: " << H(P, P) << std::endl;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> When the simulator detects the call to H in P it forks the
>>>>>>>>>>>> simulation into a non-halting branch (returning 0 to P)
>>>>>>>>>>>> and a halting branch (returning 1 to P) and continues the
>>>>>>>>>>>> simulation of these two branches in parallel.
>>>>>>>>>>>>
>>>>>>>>>>>> If the non-halting branch is determined to halt AND the
>>>>>>>>>>>> halting branch is determined to not halt then pathology is
>>>>>>>>>>>> detected and reported.
>>>>>>>>>>>>
>>>>>>>>>>>> If EITHER branch is determined to be correctly decided then
>>>>>>>>>>>> that will be the decision of the halting decider.
>>>>>>>>>>>>
>>>>>>>>>>>> Crucially this scheme will handle (and correctly decide)
>>>>>>>>>>>> the following case whereby the result of H is discarded by
>>>>>>>>>>>> the input:
>>>>>>>>>>>>
>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>> {
>>>>>>>>>>>> (void) H(x, x);
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Thoughts? I am probably missing something obvious.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> You should declare copyright first, then public the source
>>>>>>>>>>> before olcott does. Although I don't think olcott has
>>>>>>>>>>> technical competent enough data to sue you, less trouble is
>>>>>>>>>>> always better.
>>>>>>>>>> No need, the timestamps of the Usenet posts should be
>>>>>>>>>> sufficient to prove prior art. :)
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> The idea of fork-simulation halting decider indeed looked much
>>>>>>>>> advanced and promising than the oral-based halting decider
>>>>>>>>> (POOH). Chance might be good refuting the HP. comp.theory user
>>>>>>>>> might help you enrich the original idea if you would share
>>>>>>>>> more brilliant thought.
>>>>>>>> So basically you do not understand that it is flat out
>>>>>>>> incorrect for a function called in infinite recursion to ever
>>>>>>>> return to its caller.
>>>>>>>>> My idea of the copyright is that if no one announce it,
>>>>>>>>> copyright does not exist. Probable like the car speeding if
>>>>>>>>> not get caught, no breaking of the law exists (IMO).
>>>>>>>> --
>>>>>>>> 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 think Mr Flibble's fork-simulation halting decider is
>>>>>>> brilliant, original, and could be a better candidate to refute
>>>>>>> the HP. But it is just so far unfinished.
>>>>>>
>>>>>> Yet Flibble does not even understand that code following an
>>>>>> infinitely recursive function call is dead code that is never
>>>>>> reached.
>>>>>
>>>>> My fork-simulation halting decider is NOT infinitely recursive as
>>>>> it returns a value to its caller on each branch. It is your
>>>>> erroneous decider that has an issue with infinite recursion.
>>>>> [Strachey 1965] is NOT recursive so neither is my solution.
>>>>>
>>>>>>
>>>>>> His forking idea merely makes infinite forks of infinitely nested
>>>>>> emulation. The emulations are already executed in a separate
>>>>>> process so they are already forked.
>>>>>
>>>>> No it doesn't as it isn't recursive; the simulator will create two
>>>>> branches each time the decider is called from the input and the
>>>>> decider will return halting and non-halting for each branch -- no
>>>>> recursion.
>>>>>
>>>>> /Flibble
>>>>>
>>>> So it contradicts itself.
>>>
>>> It doesn't contradict itself but if there is a "contradiction" then
>>> the "Impossible Program" is being asserted which will result in my
>>> decider signaling an exception due to the input being pathological.
>>> Try CAREFULLY reading my original post again in its entirety.
>>>
>>> Your idea of equating infinite recursion due to "Impossible
>>> Program" pathology (which you don't even check for, you just assume
>>> it) with the state of non-halting is bogus.
>>>
>>> /Flibble
>>>
>>
>> Then the correct way to do this is not that the input both halts and
>> does not halt, (a contradiction) the correct way to do this would be:
>> Does the input halt ? is not a truth bearer thus is neither true nor
>> false.
>
> The correct way to do it is to raise an exception if there is a
> contradiction rather than artificially claiming non-halting based on
> some supposed infinite recursion which is only a property of your
> erroneous solution.
>
> /Flibble
>

The halting problem exclicitly allows for any damn thing that correctly
reports the halt status of its input: H(P,P)==0 DOES DO THAT !!!

On 7/5/22 3:33 PM, olcott wrote:
> On 7/5/2022 1:49 PM, wij wrote:
>> On Monday, 4 July 2022 at 02:00:00 UTC+8, Mr Flibble wrote:
>>> On Sun, 3 Jul 2022 10:57:40 -0700 (PDT)
>>> wij <wyni...@gmail.com> wrote:
>>>
>>>> On Monday, 4 July 2022 at 01:31:46 UTC+8, Mr Flibble wrote:
>>>>> Hi!
>>>>>
>>>>> I have an idea for a simulating halt decider that forks the
>>>>> simulation into two branches if the input calls the halt decider as
>>>>> per [Strachey 1965]'s "Impossible Program":
>>>>>
>>>>> void P(void (*x)())
>>>>> {
>>>>> if (H(x, x))
>>>>> infinite_loop: goto infinite_loop;
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> std::cout << "Input halts: " << H(P, P) << std::endl;
>>>>> }
>>>>>
>>>>> When the simulator detects the call to H in P it forks the
>>>>> simulation into a non-halting branch (returning 0 to P) and a
>>>>> halting branch (returning 1 to P) and continues the simulation of
>>>>> these two branches in parallel.
>>>>>
>>>>> If the non-halting branch is determined to halt AND the halting
>>>>> branch is determined to not halt then pathology is detected and
>>>>> reported.
>>>>>
>>>>> If EITHER branch is determined to be correctly decided then that
>>>>> will be the decision of the halting decider.
>>>>>
>>>>> Crucially this scheme will handle (and correctly decide) the
>>>>> following case whereby the result of H is discarded by the input:
>>>>>
>>>>> void Px(void (*x)())
>>>>> {
>>>>> (void) H(x, x);
>>>>> return;
>>>>> }
>>>>>
>>>>> Thoughts? I am probably missing something obvious.
>>>>>
>>>>> /Flibble
>>>>
>>>> You should declare copyright first, then public the source before
>>>> olcott does. Although I don't think olcott has technical competent
>>>> enough data to sue you, less trouble is always better.
>>> No need, the timestamps of the Usenet posts should be sufficient to
>>> prove prior art. :)
>>>
>>> /Flibble
>>
>> The idea of fork-simulation halting decider indeed looked much
>> advanced and
>> promising than the oral-based halting decider (POOH). Chance might be
>> good
>> refuting the HP. comp.theory user might help you enrich the original
>> idea if you
>> would share more brilliant thought.
>
> So basically you do not understand that it is flat out incorrect for a
> function called in infinite recursion to ever return to its caller.

Which is why your H if it actually works the way you claim, also never
returns to its caller when called as H(P,P).

Since it never reaches the point where it can CORRECTLY determine that
its input is non-halting (since if it ever does, the input becomes
halting), it creates that infinite recursion you talk about, and thus
never returns, and thus fails to be a decider.

>
>> My idea of the copyright is that if no one announce it, copyright does
>> not exist.
>> Probable like the car speeding if not get caught, no breaking of the
>> law exists (IMO).
>
>

On 05/07/2022 19:49, wij wrote:
> The idea of fork-simulation halting decider indeed looked much advanced and
> promising than the oral-based halting decider (POOH). Chance might be good
> refuting the HP.

If by "refuting the HP" you mean "constructing a halt decider", then
you have as much chance as refuting that 2+2 == 4 [in all cases, with the
usual meanings of those words]. All the obfuscation of the last couple of
decades does absolutely nothing to indicate any actual error in any of the
several known proofs that no general halt decider can exist. If you, or PO,
ever did manage to produce an actual purported "H", then we already know how
to construct an actual counterexample that refutes your, or his, claim.
That's all anyone really needs to know. We can sit back and wait however
long it takes for an actual claimed "H" [whether in C or x86 code or as a
TM] to appear, and then it is a matter of moments to produce a program and
input that "H" fails with.

If by "refuting the HP" you mean something else, then you need to
explain further, as "refuting" in English applies to claims rather than
to problems.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Praetorius

On 7/6/2022 7:50 AM, Andy Walker wrote:
> On 05/07/2022 19:49, wij wrote:
>> The idea of fork-simulation halting decider indeed looked much
>> advanced and
>> promising than the oral-based halting decider (POOH). Chance might be
>> good
>> refuting the HP.
>
>     If by "refuting the HP" you mean "constructing a halt decider", then
> you have as much chance as refuting that 2+2 == 4 [in all cases, with the
> usual meanings of those words].  All the obfuscation of the last couple of
> decades does absolutely nothing to indicate any actual error in any of the
> several known proofs that no general halt decider can exist.  If you, or
> PO,
> ever did manage to produce an actual purported "H", then we already know
> how
> to construct an actual counterexample that refutes your, or his, claim.
> That's all anyone really needs to know.  We can sit back and wait however
> long it takes for an actual claimed "H" [whether in C or x86 code or as a
> TM] to appear, and then it is a matter of moments to produce a program and
> input that "H" fails with.
>
>     If by "refuting the HP" you mean something else, then you need to
> explain further, as "refuting" in English applies to claims rather than
> to problems.
>

I dare you to try to refute this.

From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input would
never reach the "ret" instruction (final state) of this input.

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

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

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

H and P implement the above specified pathological relationship to each
other:

*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

--
Copyright 2022 Pete Olcott

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

On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:
> On 7/6/2022 7:50 AM, Andy Walker wrote:
> > On 05/07/2022 19:49, wij wrote:
> >> The idea of fork-simulation halting decider indeed looked much
> >> advanced and
> >> promising than the oral-based halting decider (POOH). Chance might be
> >> good
> >> refuting the HP.
> >
> > If by "refuting the HP" you mean "constructing a halt decider", then
> > you have as much chance as refuting that 2+2 == 4 [in all cases, with the
> > usual meanings of those words]. All the obfuscation of the last couple of
> > decades does absolutely nothing to indicate any actual error in any of the
> > several known proofs that no general halt decider can exist. If you, or
> > PO,
> > ever did manage to produce an actual purported "H", then we already know
> > how
> > to construct an actual counterexample that refutes your, or his, claim.
> > That's all anyone really needs to know. We can sit back and wait however
> > long it takes for an actual claimed "H" [whether in C or x86 code or as a
> > TM] to appear, and then it is a matter of moments to produce a program and
> > input that "H" fails with.
> >
> > If by "refuting the HP" you mean something else, then you need to
> > explain further, as "refuting" in English applies to claims rather than
> > to problems.
> >
> I dare you to try to refute this.
> From a purely software engineering perspective (anchored in the
> semantics of the x86 language) it is proven that H(P,P) correctly
> predicts that its correct and complete x86 emulation of its input would
> never reach the "ret" instruction (final state) of this input.

H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.

Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.

This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.

On 7/6/2022 8:37 AM, Dennis Bush wrote:
> On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:
>> On 7/6/2022 7:50 AM, Andy Walker wrote:
>>> On 05/07/2022 19:49, wij wrote:
>>>> The idea of fork-simulation halting decider indeed looked much
>>>> advanced and
>>>> promising than the oral-based halting decider (POOH). Chance might be
>>>> good
>>>> refuting the HP.
>>>
>>> If by "refuting the HP" you mean "constructing a halt decider", then
>>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the
>>> usual meanings of those words]. All the obfuscation of the last couple of
>>> decades does absolutely nothing to indicate any actual error in any of the
>>> several known proofs that no general halt decider can exist. If you, or
>>> PO,
>>> ever did manage to produce an actual purported "H", then we already know
>>> how
>>> to construct an actual counterexample that refutes your, or his, claim.
>>> That's all anyone really needs to know. We can sit back and wait however
>>> long it takes for an actual claimed "H" [whether in C or x86 code or as a
>>> TM] to appear, and then it is a matter of moments to produce a program and
>>> input that "H" fails with.
>>>
>>> If by "refuting the HP" you mean something else, then you need to
>>> explain further, as "refuting" in English applies to claims rather than
>>> to problems.
>>>
>> I dare you to try to refute this.
>> From a purely software engineering perspective (anchored in the
>> semantics of the x86 language) it is proven that H(P,P) correctly
>> predicts that its correct and complete x86 emulation of its input would
>> never reach the "ret" instruction (final state) of this input.
>
> H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
>
> Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
>
> This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.

In other words Dennis and Richard are saying that no halt decider can
ever correctly determine (in a finite number of steps) that
Infinite_Loop() never halts.

*H0 correctly determines that Infinite_Loop() never halts*

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H0((u32)Infinite_Loop));
}

_Infinite_Loop()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](02) ebfe jmp 00001105
[00001107](01) 5d pop ebp
[00001108](01) c3 ret
Size in bytes:(0007) [00001108]

_main()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](05) 6802110000 push 00001102
[0000119a](05) e8d3fbffff call 00000d72
[0000119f](03) 83c404 add esp,+04
[000011a2](01) 50 push eax
[000011a3](05) 68a3040000 push 000004a3
[000011a8](05) e845f3ffff call 000004f2
[000011ad](03) 83c408 add esp,+08
[000011b0](02) 33c0 xor eax,eax
[000011b2](01) 5d pop ebp
[000011b3](01) c3 ret
Size in bytes:(0034) [000011b3]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001192][00101ef8][00000000] 55 push ebp
[00001193][00101ef8][00000000] 8bec mov ebp,esp
[00001195][00101ef4][00001102] 6802110000 push 00001102
[0000119a][00101ef0][0000119f] e8d3fbffff call 00000d72

H0: Begin Simulation Execution Trace Stored at:211fac
[00001102][00211f9c][00211fa0] 55 push ebp
[00001103][00211f9c][00211fa0] 8bec mov ebp,esp
[00001105][00211f9c][00211fa0] ebfe jmp 00001105
[00001105][00211f9c][00211fa0] ebfe jmp 00001105
H0: Infinite Loop Detected Simulation Stopped

if (current->Simplified_Opcode == JMP) // JMP
if (current->Decode_Target <= current->Address) // upward
if (traced->Address == current->Decode_Target) // to this address
if (Conditional_Branch_Count == 0) // no escape
return 1;

[0000119f][00101ef8][00000000] 83c404 add esp,+04
[000011a2][00101ef4][00000000] 50 push eax
[000011a3][00101ef0][000004a3] 68a3040000 push 000004a3
[000011a8][00101ef0][000004a3] e845f3ffff call 000004f2
Input_Halts = 0
[000011ad][00101ef8][00000000] 83c408 add esp,+08
[000011b0][00101ef8][00000000] 33c0 xor eax,eax
[000011b2][00101efc][00100000] 5d pop ebp
[000011b3][00101f00][00000004] c3 ret
Number of Instructions Executed(554) == 8 Pages

*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

--
Copyright 2022 Pete Olcott

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

On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote:
> On 7/6/2022 8:37 AM, Dennis Bush wrote:
> > On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:
> >> On 7/6/2022 7:50 AM, Andy Walker wrote:
> >>> On 05/07/2022 19:49, wij wrote:
> >>>> The idea of fork-simulation halting decider indeed looked much
> >>>> advanced and
> >>>> promising than the oral-based halting decider (POOH). Chance might be
> >>>> good
> >>>> refuting the HP.
> >>>
> >>> If by "refuting the HP" you mean "constructing a halt decider", then
> >>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the
> >>> usual meanings of those words]. All the obfuscation of the last couple of
> >>> decades does absolutely nothing to indicate any actual error in any of the
> >>> several known proofs that no general halt decider can exist. If you, or
> >>> PO,
> >>> ever did manage to produce an actual purported "H", then we already know
> >>> how
> >>> to construct an actual counterexample that refutes your, or his, claim.
> >>> That's all anyone really needs to know. We can sit back and wait however
> >>> long it takes for an actual claimed "H" [whether in C or x86 code or as a
> >>> TM] to appear, and then it is a matter of moments to produce a program and
> >>> input that "H" fails with.
> >>>
> >>> If by "refuting the HP" you mean something else, then you need to
> >>> explain further, as "refuting" in English applies to claims rather than
> >>> to problems.
> >>>
> >> I dare you to try to refute this.
> >> From a purely software engineering perspective (anchored in the
> >> semantics of the x86 language) it is proven that H(P,P) correctly
> >> predicts that its correct and complete x86 emulation of its input would
> >> never reach the "ret" instruction (final state) of this input.
> >
> > H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
> >
> > Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
> >
> > This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
> In other words Dennis and Richard are saying that no halt decider can
> ever correctly determine (in a finite number of steps) that
> Infinite_Loop() never halts.

Infinite_Loop has previously shown to be irrelevant.

Try again.

On 7/6/2022 9:06 AM, Dennis Bush wrote:
> On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote:
>> On 7/6/2022 8:37 AM, Dennis Bush wrote:
>>> On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:
>>>> On 7/6/2022 7:50 AM, Andy Walker wrote:
>>>>> On 05/07/2022 19:49, wij wrote:
>>>>>> The idea of fork-simulation halting decider indeed looked much
>>>>>> advanced and
>>>>>> promising than the oral-based halting decider (POOH). Chance might be
>>>>>> good
>>>>>> refuting the HP.
>>>>>
>>>>> If by "refuting the HP" you mean "constructing a halt decider", then
>>>>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the
>>>>> usual meanings of those words]. All the obfuscation of the last couple of
>>>>> decades does absolutely nothing to indicate any actual error in any of the
>>>>> several known proofs that no general halt decider can exist. If you, or
>>>>> PO,
>>>>> ever did manage to produce an actual purported "H", then we already know
>>>>> how
>>>>> to construct an actual counterexample that refutes your, or his, claim.
>>>>> That's all anyone really needs to know. We can sit back and wait however
>>>>> long it takes for an actual claimed "H" [whether in C or x86 code or as a
>>>>> TM] to appear, and then it is a matter of moments to produce a program and
>>>>> input that "H" fails with.
>>>>>
>>>>> If by "refuting the HP" you mean something else, then you need to
>>>>> explain further, as "refuting" in English applies to claims rather than
>>>>> to problems.
>>>>>
>>>> I dare you to try to refute this.
>>>> From a purely software engineering perspective (anchored in the
>>>> semantics of the x86 language) it is proven that H(P,P) correctly
>>>> predicts that its correct and complete x86 emulation of its input would
>>>> never reach the "ret" instruction (final state) of this input.
>>>
>>> H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
>>>
>>> Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
>>>
>>> This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
>> In other words Dennis and Richard are saying that no halt decider can
>> ever correctly determine (in a finite number of steps) that
>> Infinite_Loop() never halts.
>
> Infinite_Loop has previously shown to be irrelevant.
>
> Try again.
>

Your claim is that it is impossible for a halt decider to correctly
predict that its input would never halt unless this input is simulated
forever and it never halts. I proved that you are wrong about this.

H0(Infinite_Loop);
H(Infinite_Recursion, 0x777);
H(P,P);

All correctly predict (in a finite number of steps) that their complete
and correct x86 emulation of their input would never reach the "ret"
instruction of this input.

The above three examples are provided as Example_01, Example_02, and
Example_03 in my linked paper below.

*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

--

--
Copyright 2022 Pete Olcott

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

On Wednesday, July 6, 2022 at 10:28:10 AM UTC-4, olcott wrote:
> On 7/6/2022 9:06 AM, Dennis Bush wrote:
> > On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote:
> >> On 7/6/2022 8:37 AM, Dennis Bush wrote:
> >>> On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:
> >>>> On 7/6/2022 7:50 AM, Andy Walker wrote:
> >>>>> On 05/07/2022 19:49, wij wrote:
> >>>>>> The idea of fork-simulation halting decider indeed looked much
> >>>>>> advanced and
> >>>>>> promising than the oral-based halting decider (POOH). Chance might be
> >>>>>> good
> >>>>>> refuting the HP.
> >>>>>
> >>>>> If by "refuting the HP" you mean "constructing a halt decider", then
> >>>>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the
> >>>>> usual meanings of those words]. All the obfuscation of the last couple of
> >>>>> decades does absolutely nothing to indicate any actual error in any of the
> >>>>> several known proofs that no general halt decider can exist. If you, or
> >>>>> PO,
> >>>>> ever did manage to produce an actual purported "H", then we already know
> >>>>> how
> >>>>> to construct an actual counterexample that refutes your, or his, claim.
> >>>>> That's all anyone really needs to know. We can sit back and wait however
> >>>>> long it takes for an actual claimed "H" [whether in C or x86 code or as a
> >>>>> TM] to appear, and then it is a matter of moments to produce a program and
> >>>>> input that "H" fails with.
> >>>>>
> >>>>> If by "refuting the HP" you mean something else, then you need to
> >>>>> explain further, as "refuting" in English applies to claims rather than
> >>>>> to problems.
> >>>>>
> >>>> I dare you to try to refute this.
> >>>> From a purely software engineering perspective (anchored in the
> >>>> semantics of the x86 language) it is proven that H(P,P) correctly
> >>>> predicts that its correct and complete x86 emulation of its input would
> >>>> never reach the "ret" instruction (final state) of this input.
> >>>
> >>> H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
> >>>
> >>> Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
> >>>
> >>> This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
> >> In other words Dennis and Richard are saying that no halt decider can
> >> ever correctly determine (in a finite number of steps) that
> >> Infinite_Loop() never halts.
> >
> > Infinite_Loop has previously shown to be irrelevant.
> >
> > Try again.
> >
> Your claim is that it is impossible for a halt decider to correctly
> predict that its input would never halt unless this input is simulated
> forever and it never halts. I proved that you are wrong about this.

That's not what I said. I said that it's impossible for Ha(Pa,Pa) to do a correct and complete emulation of its input because it aborts, therefore its nonsense to predict what Ha(Pa,Pa)'s correct and complete emulation of its input will do.

On 7/6/2022 9:44 AM, Dennis Bush wrote:
> On Wednesday, July 6, 2022 at 10:28:10 AM UTC-4, olcott wrote:
>> On 7/6/2022 9:06 AM, Dennis Bush wrote:
>>> On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote:
>>>> On 7/6/2022 8:37 AM, Dennis Bush wrote:
>>>>> On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:
>>>>>> On 7/6/2022 7:50 AM, Andy Walker wrote:
>>>>>>> On 05/07/2022 19:49, wij wrote:
>>>>>>>> The idea of fork-simulation halting decider indeed looked much
>>>>>>>> advanced and
>>>>>>>> promising than the oral-based halting decider (POOH). Chance might be
>>>>>>>> good
>>>>>>>> refuting the HP.
>>>>>>>
>>>>>>> If by "refuting the HP" you mean "constructing a halt decider", then
>>>>>>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the
>>>>>>> usual meanings of those words]. All the obfuscation of the last couple of
>>>>>>> decades does absolutely nothing to indicate any actual error in any of the
>>>>>>> several known proofs that no general halt decider can exist. If you, or
>>>>>>> PO,
>>>>>>> ever did manage to produce an actual purported "H", then we already know
>>>>>>> how
>>>>>>> to construct an actual counterexample that refutes your, or his, claim.
>>>>>>> That's all anyone really needs to know. We can sit back and wait however
>>>>>>> long it takes for an actual claimed "H" [whether in C or x86 code or as a
>>>>>>> TM] to appear, and then it is a matter of moments to produce a program and
>>>>>>> input that "H" fails with.
>>>>>>>
>>>>>>> If by "refuting the HP" you mean something else, then you need to
>>>>>>> explain further, as "refuting" in English applies to claims rather than
>>>>>>> to problems.
>>>>>>>
>>>>>> I dare you to try to refute this.
>>>>>> From a purely software engineering perspective (anchored in the
>>>>>> semantics of the x86 language) it is proven that H(P,P) correctly
>>>>>> predicts that its correct and complete x86 emulation of its input would
>>>>>> never reach the "ret" instruction (final state) of this input.
>>>>>
>>>>> H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
>>>>>
>>>>> Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
>>>>>
>>>>> This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
>>>> In other words Dennis and Richard are saying that no halt decider can
>>>> ever correctly determine (in a finite number of steps) that
>>>> Infinite_Loop() never halts.
>>>
>>> Infinite_Loop has previously shown to be irrelevant.
>>>
>>> Try again.
>>>
>> Your claim is that it is impossible for a halt decider to correctly
>> predict that its input would never halt unless this input is simulated
>> forever and it never halts. I proved that you are wrong about this.
>
> That's not what I said. I said that it's impossible for Ha(Pa,Pa) to do a correct and complete emulation of its input because it aborts, therefore its nonsense to predict what Ha(Pa,Pa)'s correct and complete emulation of its input will do.

The halt deciders all correctly predict (in a finite number of steps)
what their correct and complete emulation of their input would do on the
basis that these inputs demonstrate non-halting behavior patterns that
the halt deciders recognize.

If your nonsense reasoning applies to H(P,P) then when this same
nonsense reasoning is applied to H0(Infinite_Loop) and
H(Infinite_Recursion, 0x777) it is shown to be nonsense.

All three of these examples are provided in my paper:
Example_01 H0(Infinite_Loop);
Example_02 H(Infinite_Recursion, 0x777);
Example_03 H(P,P);

*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

--
Copyright 2022 Pete Olcott

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

On Wednesday, July 6, 2022 at 11:05:12 AM UTC-4, olcott wrote:
> On 7/6/2022 9:44 AM, Dennis Bush wrote:
> > On Wednesday, July 6, 2022 at 10:28:10 AM UTC-4, olcott wrote:
> >> On 7/6/2022 9:06 AM, Dennis Bush wrote:
> >>> On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote:
> >>>> On 7/6/2022 8:37 AM, Dennis Bush wrote:
> >>>>> On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:
> >>>>>> On 7/6/2022 7:50 AM, Andy Walker wrote:
> >>>>>>> On 05/07/2022 19:49, wij wrote:
> >>>>>>>> The idea of fork-simulation halting decider indeed looked much
> >>>>>>>> advanced and
> >>>>>>>> promising than the oral-based halting decider (POOH). Chance might be
> >>>>>>>> good
> >>>>>>>> refuting the HP.
> >>>>>>>
> >>>>>>> If by "refuting the HP" you mean "constructing a halt decider", then
> >>>>>>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the
> >>>>>>> usual meanings of those words]. All the obfuscation of the last couple of
> >>>>>>> decades does absolutely nothing to indicate any actual error in any of the
> >>>>>>> several known proofs that no general halt decider can exist. If you, or
> >>>>>>> PO,
> >>>>>>> ever did manage to produce an actual purported "H", then we already know
> >>>>>>> how
> >>>>>>> to construct an actual counterexample that refutes your, or his, claim.
> >>>>>>> That's all anyone really needs to know. We can sit back and wait however
> >>>>>>> long it takes for an actual claimed "H" [whether in C or x86 code or as a
> >>>>>>> TM] to appear, and then it is a matter of moments to produce a program and
> >>>>>>> input that "H" fails with.
> >>>>>>>
> >>>>>>> If by "refuting the HP" you mean something else, then you need to
> >>>>>>> explain further, as "refuting" in English applies to claims rather than
> >>>>>>> to problems.
> >>>>>>>
> >>>>>> I dare you to try to refute this.
> >>>>>> From a purely software engineering perspective (anchored in the
> >>>>>> semantics of the x86 language) it is proven that H(P,P) correctly
> >>>>>> predicts that its correct and complete x86 emulation of its input would
> >>>>>> never reach the "ret" instruction (final state) of this input.
> >>>>>
> >>>>> H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
> >>>>>
> >>>>> Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
> >>>>>
> >>>>> This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
> >>>> In other words Dennis and Richard are saying that no halt decider can
> >>>> ever correctly determine (in a finite number of steps) that
> >>>> Infinite_Loop() never halts.
> >>>
> >>> Infinite_Loop has previously shown to be irrelevant.
> >>>
> >>> Try again.
> >>>
> >> Your claim is that it is impossible for a halt decider to correctly
> >> predict that its input would never halt unless this input is simulated
> >> forever and it never halts. I proved that you are wrong about this.
> >
> > That's not what I said. I said that it's impossible for Ha(Pa,Pa) to do a correct and complete emulation of its input because it aborts, therefore its nonsense to predict what Ha(Pa,Pa)'s correct and complete emulation of its input will do.
> The halt deciders all correctly predict (in a finite number of steps)
> what their correct and complete emulation of their input would do on the
> basis that these inputs demonstrate non-halting behavior patterns that
> the halt deciders recognize.

But in the case of Ha(Pa,Pa) it *doesn't* do a correct and complete emulation of its input, so it makes no sense to say what Ha's correct and complete emulation would be.

>
> If your nonsense reasoning applies to H(P,P) then when this same
> nonsense reasoning is applied to H0(Infinite_Loop) and
> H(Infinite_Recursion, 0x777) it is shown to be nonsense.

Yes, it applies to those as well as none of them do a complete and correct simulation of their inputs. They happen to get the right answer because an *actual* correct and complete simulation of their inputs, i.e. UTM(Infinite_Loop) and UTM(Infinite_Recursion, 0x777) do not halt.

The correct and complete simulation of the input to Ha(Pa,Pa), i.e. UTM(Pa,Pa), *does* halt, so Ha(Pa,Pa)==0 is wrong

>
> All three of these examples are provided in my paper:
> Example_01 H0(Infinite_Loop);
> Example_02 H(Infinite_Recursion, 0x777);
> Example_03 H(P,P);
> *Halting problem proofs refuted on the basis of software engineering*
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

On 7/6/2022 10:16 AM, Dennis Bush wrote:
> On Wednesday, July 6, 2022 at 11:05:12 AM UTC-4, olcott wrote:
>> On 7/6/2022 9:44 AM, Dennis Bush wrote:
>>> On Wednesday, July 6, 2022 at 10:28:10 AM UTC-4, olcott wrote:
>>>> On 7/6/2022 9:06 AM, Dennis Bush wrote:
>>>>> On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote:
>>>>>> On 7/6/2022 8:37 AM, Dennis Bush wrote:
>>>>>>> On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:
>>>>>>>> On 7/6/2022 7:50 AM, Andy Walker wrote:
>>>>>>>>> On 05/07/2022 19:49, wij wrote:
>>>>>>>>>> The idea of fork-simulation halting decider indeed looked much
>>>>>>>>>> advanced and
>>>>>>>>>> promising than the oral-based halting decider (POOH). Chance might be
>>>>>>>>>> good
>>>>>>>>>> refuting the HP.
>>>>>>>>>
>>>>>>>>> If by "refuting the HP" you mean "constructing a halt decider", then
>>>>>>>>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the
>>>>>>>>> usual meanings of those words]. All the obfuscation of the last couple of
>>>>>>>>> decades does absolutely nothing to indicate any actual error in any of the
>>>>>>>>> several known proofs that no general halt decider can exist. If you, or
>>>>>>>>> PO,
>>>>>>>>> ever did manage to produce an actual purported "H", then we already know
>>>>>>>>> how
>>>>>>>>> to construct an actual counterexample that refutes your, or his, claim.
>>>>>>>>> That's all anyone really needs to know. We can sit back and wait however
>>>>>>>>> long it takes for an actual claimed "H" [whether in C or x86 code or as a
>>>>>>>>> TM] to appear, and then it is a matter of moments to produce a program and
>>>>>>>>> input that "H" fails with.
>>>>>>>>>
>>>>>>>>> If by "refuting the HP" you mean something else, then you need to
>>>>>>>>> explain further, as "refuting" in English applies to claims rather than
>>>>>>>>> to problems.
>>>>>>>>>
>>>>>>>> I dare you to try to refute this.
>>>>>>>> From a purely software engineering perspective (anchored in the
>>>>>>>> semantics of the x86 language) it is proven that H(P,P) correctly
>>>>>>>> predicts that its correct and complete x86 emulation of its input would
>>>>>>>> never reach the "ret" instruction (final state) of this input.
>>>>>>>
>>>>>>> H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
>>>>>>>
>>>>>>> Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
>>>>>>>
>>>>>>> This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
>>>>>> In other words Dennis and Richard are saying that no halt decider can
>>>>>> ever correctly determine (in a finite number of steps) that
>>>>>> Infinite_Loop() never halts.
>>>>>
>>>>> Infinite_Loop has previously shown to be irrelevant.
>>>>>
>>>>> Try again.
>>>>>
>>>> Your claim is that it is impossible for a halt decider to correctly
>>>> predict that its input would never halt unless this input is simulated
>>>> forever and it never halts. I proved that you are wrong about this.
>>>
>>> That's not what I said. I said that it's impossible for Ha(Pa,Pa) to do a correct and complete emulation of its input because it aborts, therefore its nonsense to predict what Ha(Pa,Pa)'s correct and complete emulation of its input will do.
>> The halt deciders all correctly predict (in a finite number of steps)
>> what their correct and complete emulation of their input would do on the
>> basis that these inputs demonstrate non-halting behavior patterns that
>> the halt deciders recognize.
>
> But in the case of Ha(Pa,Pa) it *doesn't* do a correct and complete emulation of its input, so it makes no sense to say what Ha's correct and complete emulation would be.
>
>>
>> If your nonsense reasoning applies to H(P,P) then when this same
>> nonsense reasoning is applied to H0(Infinite_Loop) and
>> H(Infinite_Recursion, 0x777) it is shown to be nonsense.
>
> Yes, it applies to those as well as none of them do a complete and correct simulation of their inputs. They happen to get the right answer because an *actual* correct and complete simulation of their inputs, i.e. UTM(Infinite_Loop) and UTM(Infinite_Recursion, 0x777) do not halt.
>
> The correct and complete simulation of the input to Ha(Pa,Pa),

A simulating halt decider correctly predicts whether or not its correct
and complete simulation of its input would ever reach the final state of
this input.

Many times its correct and complete simulation of its input would match
the behavior of another different simulator simulating this same input.

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

This is not the case when H and P have the above halting theorem
pathological relationship to each other. In that case it is the actual
behavior of the actual input that must be assessed.

A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

P(P) reaches its "ret" instruction.

From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input would
never reach the "ret" instruction (final state) of this input.

That you insist that infinite behavior can only be recognized by
infinite simulation is a bald faced lie and you know it. I have proven
otherwise by H0(Infinite_Loop) and H(Infinite_Recursion, 0x777).

> i.e. UTM(Pa,Pa), *does* halt, so Ha(Pa,Pa)==0 is wrong
>
>>
>> All three of these examples are provided in my paper:
>> Example_01 H0(Infinite_Loop);
>> Example_02 H(Infinite_Recursion, 0x777);
>> Example_03 H(P,P);
>> *Halting problem proofs refuted on the basis of software engineering*
>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer

--
Copyright 2022 Pete Olcott

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

On Wed, 6 Jul 2022 13:50:16 +0100
Andy Walker <anw@cuboid.co.uk> wrote:

> On 05/07/2022 19:49, wij wrote:
> > The idea of fork-simulation halting decider indeed looked much
> > advanced and promising than the oral-based halting decider (POOH).
> > Chance might be good refuting the HP.
>
> If by "refuting the HP" you mean "constructing a halt
> decider", then you have as much chance as refuting that 2+2 == 4 [in
> all cases, with the usual meanings of those words]. All the
> obfuscation of the last couple of decades does absolutely nothing to
> indicate any actual error in any of the several known proofs that no
> general halt decider can exist. If you, or PO, ever did manage to
> produce an actual purported "H", then we already know how to
> construct an actual counterexample that refutes your, or his, claim.
> That's all anyone really needs to know. We can sit back and wait
> however long it takes for an actual claimed "H" [whether in C or x86
> code or as a TM] to appear, and then it is a matter of moments to
> produce a program and input that "H" fails with.
>
> If by "refuting the HP" you mean something else, then you
> need to explain further, as "refuting" in English applies to claims
> rather than to problems.
My solution bears no relation to Olcott's which has obvious flaws and
unlike Olcott I certainly have not been engaged in any form of
obfuscation "for years": I only thought of my idea a few days ago and
my original post is simple, clear and to the point.

So rather than just hand-waving why don't you point out any actual
errors in my proposed solution, Mr Andy Walker.

/Flibble

On 7/6/2022 11:03 AM, Mr Flibble wrote:
> On Wed, 6 Jul 2022 13:50:16 +0100
> Andy Walker <anw@cuboid.co.uk> wrote:
>
>> On 05/07/2022 19:49, wij wrote:
>>> The idea of fork-simulation halting decider indeed looked much
>>> advanced and promising than the oral-based halting decider (POOH).
>>> Chance might be good refuting the HP.
>>
>> If by "refuting the HP" you mean "constructing a halt
>> decider", then you have as much chance as refuting that 2+2 == 4 [in
>> all cases, with the usual meanings of those words]. All the
>> obfuscation of the last couple of decades does absolutely nothing to
>> indicate any actual error in any of the several known proofs that no
>> general halt decider can exist. If you, or PO, ever did manage to
>> produce an actual purported "H", then we already know how to
>> construct an actual counterexample that refutes your, or his, claim.
>> That's all anyone really needs to know. We can sit back and wait
>> however long it takes for an actual claimed "H" [whether in C or x86
>> code or as a TM] to appear, and then it is a matter of moments to
>> produce a program and input that "H" fails with.
>>
>> If by "refuting the HP" you mean something else, then you
>> need to explain further, as "refuting" in English applies to claims
>> rather than to problems.
>
> My solution bears no relation to Olcott's which has obvious flaws and
> unlike Olcott I certainly have not been engaged in any form of
> obfuscation "for years": I only thought of my idea a few days ago and
> my original post is simple, clear and to the point.
>
> So rather than just hand-waving why don't you point out any actual
> errors in my proposed solution, Mr Andy Walker.
>
> /Flibble
>

Hand waving is his best shot.

--
Copyright 2022 Pete Olcott

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

On Wednesday, July 6, 2022 at 11:54:12 AM UTC-4, olcott wrote:
> On 7/6/2022 10:16 AM, Dennis Bush wrote:
> > On Wednesday, July 6, 2022 at 11:05:12 AM UTC-4, olcott wrote:
> >> On 7/6/2022 9:44 AM, Dennis Bush wrote:
> >>> On Wednesday, July 6, 2022 at 10:28:10 AM UTC-4, olcott wrote:
> >>>> On 7/6/2022 9:06 AM, Dennis Bush wrote:
> >>>>> On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote:
> >>>>>> On 7/6/2022 8:37 AM, Dennis Bush wrote:
> >>>>>>> On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:
> >>>>>>>> On 7/6/2022 7:50 AM, Andy Walker wrote:
> >>>>>>>>> On 05/07/2022 19:49, wij wrote:
> >>>>>>>>>> The idea of fork-simulation halting decider indeed looked much
> >>>>>>>>>> advanced and
> >>>>>>>>>> promising than the oral-based halting decider (POOH). Chance might be
> >>>>>>>>>> good
> >>>>>>>>>> refuting the HP.
> >>>>>>>>>
> >>>>>>>>> If by "refuting the HP" you mean "constructing a halt decider", then
> >>>>>>>>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the
> >>>>>>>>> usual meanings of those words]. All the obfuscation of the last couple of
> >>>>>>>>> decades does absolutely nothing to indicate any actual error in any of the
> >>>>>>>>> several known proofs that no general halt decider can exist. If you, or
> >>>>>>>>> PO,
> >>>>>>>>> ever did manage to produce an actual purported "H", then we already know
> >>>>>>>>> how
> >>>>>>>>> to construct an actual counterexample that refutes your, or his, claim.
> >>>>>>>>> That's all anyone really needs to know. We can sit back and wait however
> >>>>>>>>> long it takes for an actual claimed "H" [whether in C or x86 code or as a
> >>>>>>>>> TM] to appear, and then it is a matter of moments to produce a program and
> >>>>>>>>> input that "H" fails with.
> >>>>>>>>>
> >>>>>>>>> If by "refuting the HP" you mean something else, then you need to
> >>>>>>>>> explain further, as "refuting" in English applies to claims rather than
> >>>>>>>>> to problems.
> >>>>>>>>>
> >>>>>>>> I dare you to try to refute this.
> >>>>>>>> From a purely software engineering perspective (anchored in the
> >>>>>>>> semantics of the x86 language) it is proven that H(P,P) correctly
> >>>>>>>> predicts that its correct and complete x86 emulation of its input would
> >>>>>>>> never reach the "ret" instruction (final state) of this input.
> >>>>>>>
> >>>>>>> H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
> >>>>>>>
> >>>>>>> Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
> >>>>>>>
> >>>>>>> This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
> >>>>>> In other words Dennis and Richard are saying that no halt decider can
> >>>>>> ever correctly determine (in a finite number of steps) that
> >>>>>> Infinite_Loop() never halts.
> >>>>>
> >>>>> Infinite_Loop has previously shown to be irrelevant.
> >>>>>
> >>>>> Try again.
> >>>>>
> >>>> Your claim is that it is impossible for a halt decider to correctly
> >>>> predict that its input would never halt unless this input is simulated
> >>>> forever and it never halts. I proved that you are wrong about this.
> >>>
> >>> That's not what I said. I said that it's impossible for Ha(Pa,Pa) to do a correct and complete emulation of its input because it aborts, therefore its nonsense to predict what Ha(Pa,Pa)'s correct and complete emulation of its input will do.
> >> The halt deciders all correctly predict (in a finite number of steps)
> >> what their correct and complete emulation of their input would do on the
> >> basis that these inputs demonstrate non-halting behavior patterns that
> >> the halt deciders recognize.
> >
> > But in the case of Ha(Pa,Pa) it *doesn't* do a correct and complete emulation of its input, so it makes no sense to say what Ha's correct and complete emulation would be.
> >
> >>
> >> If your nonsense reasoning applies to H(P,P) then when this same
> >> nonsense reasoning is applied to H0(Infinite_Loop) and
> >> H(Infinite_Recursion, 0x777) it is shown to be nonsense.
> >
> > Yes, it applies to those as well as none of them do a complete and correct simulation of their inputs. They happen to get the right answer because an *actual* correct and complete simulation of their inputs, i.e. UTM(Infinite_Loop) and UTM(Infinite_Recursion, 0x777) do not halt.
> >
> > The correct and complete simulation of the input to Ha(Pa,Pa),
> A simulating halt decider correctly predicts whether or not its correct
> and complete simulation of its input would ever reach the final state of
> this input.

So you again just repeat your claim without explaining why I am wrong.

Which means you agree that your claim is nonsense.

>
> Many times its correct and complete simulation of its input

Simply doesn't exist if the decider aborts

> would match
> the behavior of another different simulator simulating this same input.
> For any program H that might determine if programs halt, a
> "pathological"
> program P, called with some input, can pass its own source and its
> input to
> H and then specifically do the opposite of what H predicts P will
> do. No H
> can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
> This is not the case when H and P have the above halting theorem
> pathological relationship to each other. In that case it is the actual
> behavior of the actual input that must be assessed.
>
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.

Which by the specification put forth by the halting problem:

H(x,y)==1 if and only if x(y) halts, and
H(x,y)==0 if and only if x(y) does not halt

Is the behavior of x(y)

Remember, the halting problem is asking the question "Does an *algorithm* exist that can determine if *any* arbitrary algorithm will halt given a particular input", and *if* such an algorithm exits, it MUST implement the above specification.

>
> P(P) reaches its "ret" instruction.
> From a purely software engineering perspective (anchored in the
> semantics of the x86 language)

Ha must implement the specification it is stipulated to, which is

H(x,y)==1 if and only if x(y) halts, and
H(x,y)==0 if and only if x(y) does not halt

> it is proven that H(P,P) correctly
> predicts that its correct and complete x86 emulation of its input

Does not exist if Ha aborts

On 7/6/2022 11:09 AM, Dennis Bush wrote:
> On Wednesday, July 6, 2022 at 11:54:12 AM UTC-4, olcott wrote:
>> On 7/6/2022 10:16 AM, Dennis Bush wrote:
>>> On Wednesday, July 6, 2022 at 11:05:12 AM UTC-4, olcott wrote:
>>>> On 7/6/2022 9:44 AM, Dennis Bush wrote:
>>>>> On Wednesday, July 6, 2022 at 10:28:10 AM UTC-4, olcott wrote:
>>>>>> On 7/6/2022 9:06 AM, Dennis Bush wrote:
>>>>>>> On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote:
>>>>>>>> On 7/6/2022 8:37 AM, Dennis Bush wrote:
>>>>>>>>> On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:
>>>>>>>>>> On 7/6/2022 7:50 AM, Andy Walker wrote:
>>>>>>>>>>> On 05/07/2022 19:49, wij wrote:
>>>>>>>>>>>> The idea of fork-simulation halting decider indeed looked much
>>>>>>>>>>>> advanced and
>>>>>>>>>>>> promising than the oral-based halting decider (POOH). Chance might be
>>>>>>>>>>>> good
>>>>>>>>>>>> refuting the HP.
>>>>>>>>>>>
>>>>>>>>>>> If by "refuting the HP" you mean "constructing a halt decider", then
>>>>>>>>>>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the
>>>>>>>>>>> usual meanings of those words]. All the obfuscation of the last couple of
>>>>>>>>>>> decades does absolutely nothing to indicate any actual error in any of the
>>>>>>>>>>> several known proofs that no general halt decider can exist. If you, or
>>>>>>>>>>> PO,
>>>>>>>>>>> ever did manage to produce an actual purported "H", then we already know
>>>>>>>>>>> how
>>>>>>>>>>> to construct an actual counterexample that refutes your, or his, claim.
>>>>>>>>>>> That's all anyone really needs to know. We can sit back and wait however
>>>>>>>>>>> long it takes for an actual claimed "H" [whether in C or x86 code or as a
>>>>>>>>>>> TM] to appear, and then it is a matter of moments to produce a program and
>>>>>>>>>>> input that "H" fails with.
>>>>>>>>>>>
>>>>>>>>>>> If by "refuting the HP" you mean something else, then you need to
>>>>>>>>>>> explain further, as "refuting" in English applies to claims rather than
>>>>>>>>>>> to problems.
>>>>>>>>>>>
>>>>>>>>>> I dare you to try to refute this.
>>>>>>>>>> From a purely software engineering perspective (anchored in the
>>>>>>>>>> semantics of the x86 language) it is proven that H(P,P) correctly
>>>>>>>>>> predicts that its correct and complete x86 emulation of its input would
>>>>>>>>>> never reach the "ret" instruction (final state) of this input.
>>>>>>>>>
>>>>>>>>> H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
>>>>>>>>>
>>>>>>>>> Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
>>>>>>>>>
>>>>>>>>> This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
>>>>>>>> In other words Dennis and Richard are saying that no halt decider can
>>>>>>>> ever correctly determine (in a finite number of steps) that
>>>>>>>> Infinite_Loop() never halts.
>>>>>>>
>>>>>>> Infinite_Loop has previously shown to be irrelevant.
>>>>>>>
>>>>>>> Try again.
>>>>>>>
>>>>>> Your claim is that it is impossible for a halt decider to correctly
>>>>>> predict that its input would never halt unless this input is simulated
>>>>>> forever and it never halts. I proved that you are wrong about this.
>>>>>
>>>>> That's not what I said. I said that it's impossible for Ha(Pa,Pa) to do a correct and complete emulation of its input because it aborts, therefore its nonsense to predict what Ha(Pa,Pa)'s correct and complete emulation of its input will do.
>>>> The halt deciders all correctly predict (in a finite number of steps)
>>>> what their correct and complete emulation of their input would do on the
>>>> basis that these inputs demonstrate non-halting behavior patterns that
>>>> the halt deciders recognize.
>>>
>>> But in the case of Ha(Pa,Pa) it *doesn't* do a correct and complete emulation of its input, so it makes no sense to say what Ha's correct and complete emulation would be.
>>>
>>>>
>>>> If your nonsense reasoning applies to H(P,P) then when this same
>>>> nonsense reasoning is applied to H0(Infinite_Loop) and
>>>> H(Infinite_Recursion, 0x777) it is shown to be nonsense.
>>>
>>> Yes, it applies to those as well as none of them do a complete and correct simulation of their inputs. They happen to get the right answer because an *actual* correct and complete simulation of their inputs, i.e. UTM(Infinite_Loop) and UTM(Infinite_Recursion, 0x777) do not halt.
>>>
>>> The correct and complete simulation of the input to Ha(Pa,Pa),
>> A simulating halt decider correctly predicts whether or not its correct
>> and complete simulation of its input would ever reach the final state of
>> this input.
>
> So you again just repeat your claim without explaining why I am wrong.
>
> Which means you agree that your claim is nonsense.

From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input would
never reach the "ret" instruction (final state) of this input.

A halt decider computes the mapping from its inputs to an accept or
reject state based on the actual behavior of these actual inputs.

H(P,P) does do that therefore H(P,P)==0 is necessarily correct. Every
rebuttal of a necessarily correct statement is necessarily incorrect.

>>
>> Many times its correct and complete simulation of its input
>
> Simply doesn't exist if the decider aborts
>
>> would match
>> the behavior of another different simulator simulating this same input.
>> For any program H that might determine if programs halt, a
>> "pathological"
>> program P, called with some input, can pass its own source and its
>> input to
>> H and then specifically do the opposite of what H predicts P will
>> do. No H
>> can exist that handles this case.
>> https://en.wikipedia.org/wiki/Halting_problem
>> This is not the case when H and P have the above halting theorem
>> pathological relationship to each other. In that case it is the actual
>> behavior of the actual input that must be assessed.
>>
>> A halt decider must compute the mapping from its inputs to an accept or
>> reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>
> Which by the specification put forth by the halting problem:
>
> H(x,y)==1 if and only if x(y) halts, and
> H(x,y)==0 if and only if x(y) does not halt
>
> Is the behavior of x(y)
>
> Remember, the halting problem is asking the question "Does an *algorithm* exist that can determine if *any* arbitrary algorithm will halt given a particular input", and *if* such an algorithm exits, it MUST implement the above specification.
>
>>
>> P(P) reaches its "ret" instruction.
>> From a purely software engineering perspective (anchored in the
>> semantics of the x86 language)
>
> Ha must implement the specification it is stipulated to, which is
>
> H(x,y)==1 if and only if x(y) halts, and
> H(x,y)==0 if and only if x(y) does not halt
>
>> it is proven that H(P,P) correctly
>> predicts that its correct and complete x86 emulation of its input
>
> Does not exist if Ha aborts

On Wednesday, July 6, 2022 at 12:15:52 PM UTC-4, olcott wrote:
> On 7/6/2022 11:09 AM, Dennis Bush wrote:
> > On Wednesday, July 6, 2022 at 11:54:12 AM UTC-4, olcott wrote:
> >> On 7/6/2022 10:16 AM, Dennis Bush wrote:
> >>> On Wednesday, July 6, 2022 at 11:05:12 AM UTC-4, olcott wrote:
> >>>> On 7/6/2022 9:44 AM, Dennis Bush wrote:
> >>>>> On Wednesday, July 6, 2022 at 10:28:10 AM UTC-4, olcott wrote:
> >>>>>> On 7/6/2022 9:06 AM, Dennis Bush wrote:
> >>>>>>> On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote:
> >>>>>>>> On 7/6/2022 8:37 AM, Dennis Bush wrote:
> >>>>>>>>> On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:
> >>>>>>>>>> On 7/6/2022 7:50 AM, Andy Walker wrote:
> >>>>>>>>>>> On 05/07/2022 19:49, wij wrote:
> >>>>>>>>>>>> The idea of fork-simulation halting decider indeed looked much
> >>>>>>>>>>>> advanced and
> >>>>>>>>>>>> promising than the oral-based halting decider (POOH). Chance might be
> >>>>>>>>>>>> good
> >>>>>>>>>>>> refuting the HP.
> >>>>>>>>>>>
> >>>>>>>>>>> If by "refuting the HP" you mean "constructing a halt decider", then
> >>>>>>>>>>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the
> >>>>>>>>>>> usual meanings of those words]. All the obfuscation of the last couple of
> >>>>>>>>>>> decades does absolutely nothing to indicate any actual error in any of the
> >>>>>>>>>>> several known proofs that no general halt decider can exist. If you, or
> >>>>>>>>>>> PO,
> >>>>>>>>>>> ever did manage to produce an actual purported "H", then we already know
> >>>>>>>>>>> how
> >>>>>>>>>>> to construct an actual counterexample that refutes your, or his, claim.
> >>>>>>>>>>> That's all anyone really needs to know. We can sit back and wait however
> >>>>>>>>>>> long it takes for an actual claimed "H" [whether in C or x86 code or as a
> >>>>>>>>>>> TM] to appear, and then it is a matter of moments to produce a program and
> >>>>>>>>>>> input that "H" fails with.
> >>>>>>>>>>>
> >>>>>>>>>>> If by "refuting the HP" you mean something else, then you need to
> >>>>>>>>>>> explain further, as "refuting" in English applies to claims rather than
> >>>>>>>>>>> to problems.
> >>>>>>>>>>>
> >>>>>>>>>> I dare you to try to refute this.
> >>>>>>>>>> From a purely software engineering perspective (anchored in the
> >>>>>>>>>> semantics of the x86 language) it is proven that H(P,P) correctly
> >>>>>>>>>> predicts that its correct and complete x86 emulation of its input would
> >>>>>>>>>> never reach the "ret" instruction (final state) of this input.
> >>>>>>>>>
> >>>>>>>>> H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
> >>>>>>>>>
> >>>>>>>>> Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
> >>>>>>>>>
> >>>>>>>>> This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
> >>>>>>>> In other words Dennis and Richard are saying that no halt decider can
> >>>>>>>> ever correctly determine (in a finite number of steps) that
> >>>>>>>> Infinite_Loop() never halts.
> >>>>>>>
> >>>>>>> Infinite_Loop has previously shown to be irrelevant.
> >>>>>>>
> >>>>>>> Try again.
> >>>>>>>
> >>>>>> Your claim is that it is impossible for a halt decider to correctly
> >>>>>> predict that its input would never halt unless this input is simulated
> >>>>>> forever and it never halts. I proved that you are wrong about this..
> >>>>>
> >>>>> That's not what I said. I said that it's impossible for Ha(Pa,Pa) to do a correct and complete emulation of its input because it aborts, therefore its nonsense to predict what Ha(Pa,Pa)'s correct and complete emulation of its input will do.
> >>>> The halt deciders all correctly predict (in a finite number of steps)
> >>>> what their correct and complete emulation of their input would do on the
> >>>> basis that these inputs demonstrate non-halting behavior patterns that
> >>>> the halt deciders recognize.
> >>>
> >>> But in the case of Ha(Pa,Pa) it *doesn't* do a correct and complete emulation of its input, so it makes no sense to say what Ha's correct and complete emulation would be.
> >>>
> >>>>
> >>>> If your nonsense reasoning applies to H(P,P) then when this same
> >>>> nonsense reasoning is applied to H0(Infinite_Loop) and
> >>>> H(Infinite_Recursion, 0x777) it is shown to be nonsense.
> >>>
> >>> Yes, it applies to those as well as none of them do a complete and correct simulation of their inputs. They happen to get the right answer because an *actual* correct and complete simulation of their inputs, i.e. UTM(Infinite_Loop) and UTM(Infinite_Recursion, 0x777) do not halt.
> >>>
> >>> The correct and complete simulation of the input to Ha(Pa,Pa),
> >> A simulating halt decider correctly predicts whether or not its correct
> >> and complete simulation of its input would ever reach the final state of
> >> this input.
> >
> > So you again just repeat your claim without explaining why I am wrong.
> >
> > Which means you agree that your claim is nonsense.
>
> From a purely software engineering perspective (anchored in the
> semantics of the x86 language) it is proven that H(P,P) correctly
> predicts that its correct and complete x86 emulation of its input

Why do you continue to make this claim after you've agreed that it's nonsense?

Ha(Pa,Pa) does not perform a correct and complete simulation, therefore Ha(Pa,Pa)'s correct and complete simulation does not exist.

> would
> never reach the "ret" instruction (final state) of this input.
> A halt decider computes the mapping from its inputs to an accept or
> reject state based on the actual behavior of these actual inputs.
>
> H(P,P) does do that therefore H(P,P)==0 is necessarily correct. Every
> rebuttal of a necessarily correct statement is necessarily incorrect.
> >>
> >> Many times its correct and complete simulation of its input
> >
> > Simply doesn't exist if the decider aborts
> >
> >> would match
> >> the behavior of another different simulator simulating this same input..
> >> For any program H that might determine if programs halt, a
> >> "pathological"
> >> program P, called with some input, can pass its own source and its
> >> input to
> >> H and then specifically do the opposite of what H predicts P will
> >> do. No H
> >> can exist that handles this case.
> >> https://en.wikipedia.org/wiki/Halting_problem
> >> This is not the case when H and P have the above halting theorem
> >> pathological relationship to each other. In that case it is the actual
> >> behavior of the actual input that must be assessed.
> >>
> >> A halt decider must compute the mapping from its inputs to an accept or
> >> reject state on the basis of the actual behavior that is actually
> >> specified by these inputs.
> >
> > Which by the specification put forth by the halting problem:
> >
> > H(x,y)==1 if and only if x(y) halts, and
> > H(x,y)==0 if and only if x(y) does not halt
> >
> > Is the behavior of x(y)
> >
> > Remember, the halting problem is asking the question "Does an *algorithm* exist that can determine if *any* arbitrary algorithm will halt given a particular input", and *if* such an algorithm exits, it MUST implement the above specification.
> >
> >>
> >> P(P) reaches its "ret" instruction.
> >> From a purely software engineering perspective (anchored in the
> >> semantics of the x86 language)
> >
> > Ha must implement the specification it is stipulated to, which is
> >
> > H(x,y)==1 if and only if x(y) halts, and
> > H(x,y)==0 if and only if x(y) does not halt
> >
> >> it is proven that H(P,P) correctly
> >> predicts that its correct and complete x86 emulation of its input
> >
> > Does not exist if Ha aborts

Mr Flibble <flibble@reddwarf.jmc> writes:

> On Wed, 6 Jul 2022 13:50:16 +0100
> Andy Walker <anw@cuboid.co.uk> wrote:
>
>> On 05/07/2022 19:49, wij wrote:
>> > The idea of fork-simulation halting decider indeed looked much
>> > advanced and promising than the oral-based halting decider (POOH).
>> > Chance might be good refuting the HP.
>>
>> If by "refuting the HP" you mean "constructing a halt
>> decider", then you have as much chance as refuting that 2+2 == 4 [in
>> all cases, with the usual meanings of those words]. All the
>> obfuscation of the last couple of decades does absolutely nothing to
>> indicate any actual error in any of the several known proofs that no
>> general halt decider can exist. If you, or PO, ever did manage to
>> produce an actual purported "H", then we already know how to
>> construct an actual counterexample that refutes your, or his, claim.
>> That's all anyone really needs to know. We can sit back and wait
>> however long it takes for an actual claimed "H" [whether in C or x86
>> code or as a TM] to appear, and then it is a matter of moments to
>> produce a program and input that "H" fails with.
>>
>> If by "refuting the HP" you mean something else, then you
>> need to explain further, as "refuting" in English applies to claims
>> rather than to problems.
>
> My solution bears no relation to Olcott's which has obvious flaws and
> unlike Olcott I certainly have not been engaged in any form of
> obfuscation "for years": I only thought of my idea a few days ago and
> my original post is simple, clear and to the point.
>
> So rather than just hand-waving why don't you point out any actual
> errors in my proposed solution, Mr Andy Walker.

I thought you claimed a three-way decider? That's fine. There's
nothing to say about such things other than to ask how good it is. A
really good three-way halt decider would be very useful in practice, but
the usual offerings just refuses to decide a huge category of problem
instances and would be no use in practice.

Try not to be a crank. It's a crank tactic to put the onus on everyone
else to show that some vague idea is wrong because it suggests you just
want people to talk to you. Publish (and in this case I am including
here), and if there's a flaw it will be pointed out quickly enough.

--
Ben.

On 7/6/2022 11:19 AM, Dennis Bush wrote:
> On Wednesday, July 6, 2022 at 12:15:52 PM UTC-4, olcott wrote:
>> On 7/6/2022 11:09 AM, Dennis Bush wrote:
>>> On Wednesday, July 6, 2022 at 11:54:12 AM UTC-4, olcott wrote:
>>>> On 7/6/2022 10:16 AM, Dennis Bush wrote:
>>>>> On Wednesday, July 6, 2022 at 11:05:12 AM UTC-4, olcott wrote:
>>>>>> On 7/6/2022 9:44 AM, Dennis Bush wrote:
>>>>>>> On Wednesday, July 6, 2022 at 10:28:10 AM UTC-4, olcott wrote:
>>>>>>>> On 7/6/2022 9:06 AM, Dennis Bush wrote:
>>>>>>>>> On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote:
>>>>>>>>>> On 7/6/2022 8:37 AM, Dennis Bush wrote:
>>>>>>>>>>> On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:
>>>>>>>>>>>> On 7/6/2022 7:50 AM, Andy Walker wrote:
>>>>>>>>>>>>> On 05/07/2022 19:49, wij wrote:
>>>>>>>>>>>>>> The idea of fork-simulation halting decider indeed looked much
>>>>>>>>>>>>>> advanced and
>>>>>>>>>>>>>> promising than the oral-based halting decider (POOH). Chance might be
>>>>>>>>>>>>>> good
>>>>>>>>>>>>>> refuting the HP.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If by "refuting the HP" you mean "constructing a halt decider", then
>>>>>>>>>>>>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the
>>>>>>>>>>>>> usual meanings of those words]. All the obfuscation of the last couple of
>>>>>>>>>>>>> decades does absolutely nothing to indicate any actual error in any of the
>>>>>>>>>>>>> several known proofs that no general halt decider can exist. If you, or
>>>>>>>>>>>>> PO,
>>>>>>>>>>>>> ever did manage to produce an actual purported "H", then we already know
>>>>>>>>>>>>> how
>>>>>>>>>>>>> to construct an actual counterexample that refutes your, or his, claim.
>>>>>>>>>>>>> That's all anyone really needs to know. We can sit back and wait however
>>>>>>>>>>>>> long it takes for an actual claimed "H" [whether in C or x86 code or as a
>>>>>>>>>>>>> TM] to appear, and then it is a matter of moments to produce a program and
>>>>>>>>>>>>> input that "H" fails with.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If by "refuting the HP" you mean something else, then you need to
>>>>>>>>>>>>> explain further, as "refuting" in English applies to claims rather than
>>>>>>>>>>>>> to problems.
>>>>>>>>>>>>>
>>>>>>>>>>>> I dare you to try to refute this.
>>>>>>>>>>>> From a purely software engineering perspective (anchored in the
>>>>>>>>>>>> semantics of the x86 language) it is proven that H(P,P) correctly
>>>>>>>>>>>> predicts that its correct and complete x86 emulation of its input would
>>>>>>>>>>>> never reach the "ret" instruction (final state) of this input.
>>>>>>>>>>>
>>>>>>>>>>> H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
>>>>>>>>>>>
>>>>>>>>>>> Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
>>>>>>>>>>>
>>>>>>>>>>> This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
>>>>>>>>>> In other words Dennis and Richard are saying that no halt decider can
>>>>>>>>>> ever correctly determine (in a finite number of steps) that
>>>>>>>>>> Infinite_Loop() never halts.
>>>>>>>>>
>>>>>>>>> Infinite_Loop has previously shown to be irrelevant.
>>>>>>>>>
>>>>>>>>> Try again.
>>>>>>>>>
>>>>>>>> Your claim is that it is impossible for a halt decider to correctly
>>>>>>>> predict that its input would never halt unless this input is simulated
>>>>>>>> forever and it never halts. I proved that you are wrong about this.
>>>>>>>
>>>>>>> That's not what I said. I said that it's impossible for Ha(Pa,Pa) to do a correct and complete emulation of its input because it aborts, therefore its nonsense to predict what Ha(Pa,Pa)'s correct and complete emulation of its input will do.
>>>>>> The halt deciders all correctly predict (in a finite number of steps)
>>>>>> what their correct and complete emulation of their input would do on the
>>>>>> basis that these inputs demonstrate non-halting behavior patterns that
>>>>>> the halt deciders recognize.
>>>>>
>>>>> But in the case of Ha(Pa,Pa) it *doesn't* do a correct and complete emulation of its input, so it makes no sense to say what Ha's correct and complete emulation would be.
>>>>>
>>>>>>
>>>>>> If your nonsense reasoning applies to H(P,P) then when this same
>>>>>> nonsense reasoning is applied to H0(Infinite_Loop) and
>>>>>> H(Infinite_Recursion, 0x777) it is shown to be nonsense.
>>>>>
>>>>> Yes, it applies to those as well as none of them do a complete and correct simulation of their inputs. They happen to get the right answer because an *actual* correct and complete simulation of their inputs, i.e. UTM(Infinite_Loop) and UTM(Infinite_Recursion, 0x777) do not halt.
>>>>>
>>>>> The correct and complete simulation of the input to Ha(Pa,Pa),
>>>> A simulating halt decider correctly predicts whether or not its correct
>>>> and complete simulation of its input would ever reach the final state of
>>>> this input.
>>>
>>> So you again just repeat your claim without explaining why I am wrong.
>>>
>>> Which means you agree that your claim is nonsense.
>>
>> From a purely software engineering perspective (anchored in the
>> semantics of the x86 language) it is proven that H(P,P) correctly
>> predicts that its correct and complete x86 emulation of its input
>
> Why do you continue to make this claim after you've agreed that it's nonsense?
>

From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P)

correctly predicts (without doing a complete emulation)
correctly predicts (without doing a complete emulation)
correctly predicts (without doing a complete emulation)
correctly predicts (without doing a complete emulation)

that its correct and complete x86 emulation of its input would never
reach the "ret" instruction (final state) of this input.

It does this by correctly recognizing an infinite behavior pattern in
its partial x86 emulation of its input.

It does this by correctly recognizing an infinite behavior pattern in
its partial x86 emulation of its input.

It does this by correctly recognizing an infinite behavior pattern in
its partial x86 emulation of its input.

It does this by correctly recognizing an infinite behavior pattern in
its partial x86 emulation of its input.

> Ha(Pa,Pa) does not perform a correct and complete simulation, therefore Ha(Pa,Pa)'s correct and complete simulation does not exist.
>
>
>> would
>> never reach the "ret" instruction (final state) of this input.
>> A halt decider computes the mapping from its inputs to an accept or
>> reject state based on the actual behavior of these actual inputs.
>>
>> H(P,P) does do that therefore H(P,P)==0 is necessarily correct. Every
>> rebuttal of a necessarily correct statement is necessarily incorrect.
>>>>
>>>> Many times its correct and complete simulation of its input
>>>
>>> Simply doesn't exist if the decider aborts
>>>
>>>> would match
>>>> the behavior of another different simulator simulating this same input.
>>>> For any program H that might determine if programs halt, a
>>>> "pathological"
>>>> program P, called with some input, can pass its own source and its
>>>> input to
>>>> H and then specifically do the opposite of what H predicts P will
>>>> do. No H
>>>> can exist that handles this case.
>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>> This is not the case when H and P have the above halting theorem
>>>> pathological relationship to each other. In that case it is the actual
>>>> behavior of the actual input that must be assessed.
>>>>
>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>> reject state on the basis of the actual behavior that is actually
>>>> specified by these inputs.
>>>
>>> Which by the specification put forth by the halting problem:
>>>
>>> H(x,y)==1 if and only if x(y) halts, and
>>> H(x,y)==0 if and only if x(y) does not halt
>>>
>>> Is the behavior of x(y)
>>>
>>> Remember, the halting problem is asking the question "Does an *algorithm* exist that can determine if *any* arbitrary algorithm will halt given a particular input", and *if* such an algorithm exits, it MUST implement the above specification.
>>>
>>>>
>>>> P(P) reaches its "ret" instruction.
>>>> From a purely software engineering perspective (anchored in the
>>>> semantics of the x86 language)
>>>
>>> Ha must implement the specification it is stipulated to, which is
>>>
>>> H(x,y)==1 if and only if x(y) halts, and
>>> H(x,y)==0 if and only if x(y) does not halt
>>>
>>>> it is proven that H(P,P) correctly
>>>> predicts that its correct and complete x86 emulation of its input
>>>
>>> Does not exist if Ha aborts
>

On Wed, 06 Jul 2022 17:24:07 +0100
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Mr Flibble <flibble@reddwarf.jmc> writes:
>
> > On Wed, 6 Jul 2022 13:50:16 +0100
> > Andy Walker <anw@cuboid.co.uk> wrote:
> >
> >> On 05/07/2022 19:49, wij wrote:
> >> > The idea of fork-simulation halting decider indeed looked much
> >> > advanced and promising than the oral-based halting decider
> >> > (POOH). Chance might be good refuting the HP.
> >>
> >> If by "refuting the HP" you mean "constructing a halt
> >> decider", then you have as much chance as refuting that 2+2 == 4
> >> [in all cases, with the usual meanings of those words]. All the
> >> obfuscation of the last couple of decades does absolutely nothing
> >> to indicate any actual error in any of the several known proofs
> >> that no general halt decider can exist. If you, or PO, ever did
> >> manage to produce an actual purported "H", then we already know
> >> how to construct an actual counterexample that refutes your, or
> >> his, claim. That's all anyone really needs to know. We can sit
> >> back and wait however long it takes for an actual claimed "H"
> >> [whether in C or x86 code or as a TM] to appear, and then it is a
> >> matter of moments to produce a program and input that "H" fails
> >> with.
> >>
> >> If by "refuting the HP" you mean something else, then you
> >> need to explain further, as "refuting" in English applies to claims
> >> rather than to problems.
> >
> > My solution bears no relation to Olcott's which has obvious flaws
> > and unlike Olcott I certainly have not been engaged in any form of
> > obfuscation "for years": I only thought of my idea a few days ago
> > and my original post is simple, clear and to the point.
> >
> > So rather than just hand-waving why don't you point out any actual
> > errors in my proposed solution, Mr Andy Walker.
>
> I thought you claimed a three-way decider? That's fine. There's
> nothing to say about such things other than to ask how good it is. A
> really good three-way halt decider would be very useful in practice,
> but the usual offerings just refuses to decide a huge category of
> problem instances and would be no use in practice.
>
> Try not to be a crank. It's a crank tactic to put the onus on
> everyone else to show that some vague idea is wrong because it
> suggests you just want people to talk to you. Publish (and in this
> case I am including here), and if there's a flaw it will be pointed
> out quickly enough.
I have published: my original post in this thread is simple, clear and
to the point: certainly not vague. As far as being a "three-way"
decider: the third outcome is not a decision of "unknown" it is an
exception thrown when an "Impossible Program" contradiction is detected.

/Flibble

On 7/6/2022 11:24 AM, Ben Bacarisse wrote:
> Mr Flibble <flibble@reddwarf.jmc> writes:
>
>> On Wed, 6 Jul 2022 13:50:16 +0100
>> Andy Walker <anw@cuboid.co.uk> wrote:
>>
>>> On 05/07/2022 19:49, wij wrote:
>>>> The idea of fork-simulation halting decider indeed looked much
>>>> advanced and promising than the oral-based halting decider (POOH).
>>>> Chance might be good refuting the HP.
>>>
>>> If by "refuting the HP" you mean "constructing a halt
>>> decider", then you have as much chance as refuting that 2+2 == 4 [in
>>> all cases, with the usual meanings of those words]. All the
>>> obfuscation of the last couple of decades does absolutely nothing to
>>> indicate any actual error in any of the several known proofs that no
>>> general halt decider can exist. If you, or PO, ever did manage to
>>> produce an actual purported "H", then we already know how to
>>> construct an actual counterexample that refutes your, or his, claim.
>>> That's all anyone really needs to know. We can sit back and wait
>>> however long it takes for an actual claimed "H" [whether in C or x86
>>> code or as a TM] to appear, and then it is a matter of moments to
>>> produce a program and input that "H" fails with.
>>>
>>> If by "refuting the HP" you mean something else, then you
>>> need to explain further, as "refuting" in English applies to claims
>>> rather than to problems.
>>
>> My solution bears no relation to Olcott's which has obvious flaws and
>> unlike Olcott I certainly have not been engaged in any form of
>> obfuscation "for years": I only thought of my idea a few days ago and
>> my original post is simple, clear and to the point.
>>
>> So rather than just hand-waving why don't you point out any actual
>> errors in my proposed solution, Mr Andy Walker.
>
> I thought you claimed a three-way decider? That's fine. There's
> nothing to say about such things other than to ask how good it is. A
> really good three-way halt decider would be very useful in practice, but
> the usual offerings just refuses to decide a huge category of problem
> instances and would be no use in practice.
>
> Try not to be a crank. It's a crank tactic to put the onus on everyone
> else to show that some vague idea is wrong because it suggests you just
> want people to talk to you. Publish (and in this case I am including
> here), and if there's a flaw it will be pointed out quickly enough.
>

The problem with that is that publisher will tell you that they will not
publish it because they don't consider it publication quality and that
is all the feedback that they will provide.

--
Copyright 2022 Pete Olcott

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

On 7/6/2022 11:34 AM, olcott wrote:
> On 7/6/2022 11:24 AM, Ben Bacarisse wrote:
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>>> On Wed, 6 Jul 2022 13:50:16 +0100
>>> Andy Walker <anw@cuboid.co.uk> wrote:
>>>
>>>> On 05/07/2022 19:49, wij wrote:
>>>>> The idea of fork-simulation halting decider indeed looked much
>>>>> advanced and promising than the oral-based halting decider (POOH).
>>>>> Chance might be good refuting the HP.
>>>>
>>>>     If by "refuting the HP" you mean "constructing a halt
>>>> decider", then you have as much chance as refuting that 2+2 == 4 [in
>>>> all cases, with the usual meanings of those words].  All the
>>>> obfuscation of the last couple of decades does absolutely nothing to
>>>> indicate any actual error in any of the several known proofs that no
>>>> general halt decider can exist.  If you, or PO, ever did manage to
>>>> produce an actual purported "H", then we already know how to
>>>> construct an actual counterexample that refutes your, or his, claim.
>>>> That's all anyone really needs to know.  We can sit back and wait
>>>> however long it takes for an actual claimed "H" [whether in C or x86
>>>> code or as a TM] to appear, and then it is a matter of moments to
>>>> produce a program and input that "H" fails with.
>>>>
>>>>     If by "refuting the HP" you mean something else, then you
>>>> need to explain further, as "refuting" in English applies to claims
>>>> rather than to problems.
>>> My solution bears no relation to Olcott's which has obvious flaws and
>>> unlike Olcott I certainly have not been engaged in any form of
>>> obfuscation "for years": I only thought of my idea a few days ago and
>>> my original post is simple, clear and to the point.
>>>
>>> So rather than just hand-waving why don't you point out any actual
>>> errors in my proposed solution, Mr Andy Walker.
>>
>> I thought you claimed a three-way decider?  That's fine.  There's
>> nothing to say about such things other than to ask how good it is.  A
>> really good three-way halt decider would be very useful in practice, but
>> the usual offerings just refuses to decide a huge category of problem
>> instances and would be no use in practice.
>>
>> Try not to be a crank.  It's a crank tactic to put the onus on everyone
>> else to show that some vague idea is wrong because it suggests you just
>> want people to talk to you.  Publish (and in this case I am including
>> here), and if there's a flaw it will be pointed out quickly enough.
>>
>
> The problem with that is that publisher will tell you that they will not
> publish it because they don't consider it publication quality and that
> is all the feedback that they will provide.
>

It is a purely style over substance thing. They will not point out any
errors in your reasoning because they never read what you said.

--
Copyright 2022 Pete Olcott

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