On 7/6/2022 11:33 AM, Mr Flibble wrote:
> 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
>

Provide the full source-code for a fully operational working example of
this. Now that I converted H into a pure function of its inputs I will
be able to publish its full source code and the source code of the
x86utm operating system.

--
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 12:28:48 PM UTC-4, olcott wrote:
> 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.

On Wed, 6 Jul 2022 11:39:31 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/6/2022 11:33 AM, Mr Flibble wrote:
> > 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
> >
>
> Provide the full source-code for a fully operational working example
> of this. Now that I converted H into a pure function of its inputs I
> will be able to publish its full source code and the source code of
> the x86utm operating system.
No, I have better things to do with my time.

/Flibble

On 7/6/2022 11:52 AM, Mr Flibble wrote:
> On Wed, 6 Jul 2022 11:39:31 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/6/2022 11:33 AM, Mr Flibble wrote:
>>> 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
>>>
>>
>> Provide the full source-code for a fully operational working example
>> of this. Now that I converted H into a pure function of its inputs I
>> will be able to publish its full source code and the source code of
>> the x86utm operating system.
>
> No, I have better things to do with my time.
>
> /Flibble
>

So you expressly acknowledge that your ideas may simply be too vague to
properly review. For example you never even mentioned the criterion
measure of your pathological input decider.

I published one of these a long time ago.
It applies to Gödel's 1931 incompleteness theorem

Truth_Bearer(G) ≡ ((PA ⊢ G) ∨ (PA ⊢ ¬G))

*Proof that Wittgenstein is correct about Gödel*
https://www.researchgate.net/publication/333907915_Proof_that_Wittgenstein_is_correct_about_Godel

--
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 12:10:37 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/6/2022 11:52 AM, Mr Flibble wrote:
> > On Wed, 6 Jul 2022 11:39:31 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/6/2022 11:33 AM, Mr Flibble wrote:
> >>> 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
> >>>
> >>
> >> Provide the full source-code for a fully operational working
> >> example of this. Now that I converted H into a pure function of
> >> its inputs I will be able to publish its full source code and the
> >> source code of the x86utm operating system.
> >
> > No, I have better things to do with my time.
> >
> > /Flibble
> >
>
> So you expressly acknowledge that your ideas may simply be too vague
> to properly review. For example you never even mentioned the
> criterion measure of your pathological input decider.

I clearly stated how pathological input is detected in my original post.

/Flibble

On Wednesday, 6 July 2022 at 17:24:10 UTC+1, Ben Bacarisse wrote:
> Mr Flibble <fli...@reddwarf.jmc> writes:
>
> > On Wed, 6 Jul 2022 13:50:16 +0100
> > Andy Walker <a...@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.
>
Three way deciders are useful. They are built into optimisers. Working out
that code always passes through a given point is the same problem as the
halting problem if all the data is constant, and a similar problem if it is
variable. In practice most code written by humans can either simply be shown
to halt or simply be shown to loop forever (or be data-dependent). Few
people write functions with complex while conditions that equate to famous
problems in mathematics.

So a fairly simple three way built-in halt decider is useful as part of an optimiser.
However you can't publish it as a piece of work "on the halting problem".

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Wednesday, 6 July 2022 at 17:24:10 UTC+1, Ben Bacarisse wrote:
>> Mr Flibble <fli...@reddwarf.jmc> writes:
>>
>> > On Wed, 6 Jul 2022 13:50:16 +0100
>> > Andy Walker <a...@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.
>>
> Three way deciders are useful.

As I said.

> They are built into optimisers. Working out
> that code always passes through a given point is the same problem as the
> halting problem if all the data is constant, and a similar problem if it is
> variable. In practice most code written by humans can either simply be shown
> to halt or simply be shown to loop forever (or be data-dependent). Few
> people write functions with complex while conditions that equate to famous
> problems in mathematics.
>
> So a fairly simple three way built-in halt decider is useful as part
> of an optimiser.

You may well be more up-to-date than I am, but the last time I knew,
optimisers had little more than a basic flow analysis. What is the
state of the art nowadays?

> However you can't publish it as a piece of work "on the halting problem".

--
Ben.

On Thursday, 7 July 2022 at 01:10:46 UTC+8, olcott wrote:
> On 7/6/2022 11:52 AM, Mr Flibble wrote:
> > On Wed, 6 Jul 2022 11:39:31 -0500
> > olcott <No...@NoWhere.com> wrote:
> >
> >> On 7/6/2022 11:33 AM, Mr Flibble wrote:
> >>> On Wed, 06 Jul 2022 17:24:07 +0100
> >>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> >>>
> >>>> Mr Flibble <fli...@reddwarf.jmc> writes:
> >>>>
> >>>>> On Wed, 6 Jul 2022 13:50:16 +0100
> >>>>> Andy Walker <a...@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
> >>>
> >>
> >> Provide the full source-code for a fully operational working example
> >> of this. Now that I converted H into a pure function of its inputs I
> >> will be able to publish its full source code and the source code of
> >> the x86utm operating system.
> >
> > No, I have better things to do with my time.
> >
> > /Flibble
> >
> So you expressly acknowledge that your ideas may simply be too vague to
> properly review. For example you never even mentioned the criterion
> measure of your pathological input decider.
>
> I published one of these a long time ago.
> It applies to Gödel's 1931 incompleteness theorem
>
> Truth_Bearer(G) ≡ ((PA ⊢ G) ∨ (PA ⊢ ¬G))
>
> *Proof that Wittgenstein is correct about Gödel*
> https://www.researchgate.net/publication/333907915_Proof_that_Wittgenstein_is_correct_about_Godel
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

Any competent engineer knows immediately. Because TM probably cannot simulate Unix signal,
a "signaling halting decider" sounds plausible. The brilliant idea may be a way to
correct refutation of the HP. SHD beats POOH.

Mr Flibble <flibble@reddwarf.jmc> writes:

> 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.

It's vague by my standards, but then there is no reason for you to care
about that. If it's as clear as you want it to be, that's fine.

> 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.

Right. That's not even a useful three-way decider since no one really
cares about that one case in practical situations.

--
Ben.

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

> Mr Flibble <flibble@reddwarf.jmc> writes:
>
> > 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.
>
> It's vague by my standards, but then there is no reason for you to
> care about that. If it's as clear as you want it to be, that's fine.
>
> > 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.
>
> Right. That's not even a useful three-way decider since no one really
> cares about that one case in practical situations.
Practical situations? It is a thought experiment: a potential
refutation of the HP proofs.

/Flibble

On Wednesday, 6 July 2022 at 19:01:40 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Wednesday, 6 July 2022 at 17:24:10 UTC+1, Ben Bacarisse wrote:
> >> Mr Flibble <fli...@reddwarf.jmc> writes:
> >>
> >> > On Wed, 6 Jul 2022 13:50:16 +0100
> >> > Andy Walker <a...@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.
> >>
> > Three way deciders are useful.
> As I said.
> > They are built into optimisers. Working out
> > that code always passes through a given point is the same problem as the
> > halting problem if all the data is constant, and a similar problem if it is
> > variable. In practice most code written by humans can either simply be shown
> > to halt or simply be shown to loop forever (or be data-dependent). Few
> > people write functions with complex while conditions that equate to famous
> > problems in mathematics.
> >
> > So a fairly simple three way built-in halt decider is useful as part
> > of an optimiser.
> You may well be more up-to-date than I am, but the last time I knew,
> optimisers had little more than a basic flow analysis. What is the
> state of the art nowadays?
>
Constant propagation. In C++, you can help the compiler along with constexpr.
constexpr means "this is a pure function of its arguments, and when called
with constants, yields a constant".
However of course it is possible to build a constexpr which is too hard for the
compiler to resolve. This happened to us in real code. A keen "latest and greatest"
C++ programmer pushed the compiler beyond its limits, and the build broke on
the CI server.

On 06/07/2022 17:03, Mr Flibble wrote:
> So rather than just hand-waving why don't you point out any actual
> errors in my proposed solution, Mr Andy Walker.

I did, when you proposed it: you have not defined "pathological".
When you do, you will find that either you have defined it as a trivial
property that advances the theory of the HP not one jot, or else that the
detection of pathological programs is as insoluble as the HP and you have
not solved anything of interest to the theorists. Note also Ben's reply.

Absent some formal definition of "pathological", hand waving is
all that anyone [inc you] can do with your proposal.

--
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 6:22 PM, Andy Walker wrote:
> On 06/07/2022 17:03, Mr Flibble wrote:
>> So rather than just hand-waving why don't you point out any actual
>> errors in my proposed solution, Mr Andy Walker.
>
>     I did, when you proposed it:  you have not defined "pathological".
> When you do, you will find that either you have defined it as a trivial
> property that advances the theory of the HP not one jot, or else that the
> detection of pathological programs is as insoluble as the HP and you have
> not solved anything of interest to the theorists.  Note also Ben's reply.
>
>     Absent some formal definition of "pathological", hand waving is
> all that anyone [inc you] can do with your proposal.
>

I agree.

--
Copyright 2022 Pete Olcott

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

Mr Flibble <flibble@reddwarf.jmc> writes:

> On Wed, 06 Jul 2022 19:15:06 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>> > 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.
>>
>> It's vague by my standards, but then there is no reason for you to
>> care about that. If it's as clear as you want it to be, that's fine.
>>
>> > 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.
>>
>> Right. That's not even a useful three-way decider since no one really
>> cares about that one case in practical situations.
>
> Practical situations? It is a thought experiment: a potential
> refutation of the HP proofs.

No it isn't. The proofs are about halt deciders, and you are not
proposing or describing a halt decider. Programs (TMs, whatever) that
do not get every instance of the halting problem right are ten-a-penny
and say nothing about the proofs.

Their only value is in practical situations, but you seem to agree with
me that your suggestion was never intended to, and does not have, that
kind of utility.

--
Ben.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Wednesday, 6 July 2022 at 19:01:40 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Wednesday, 6 July 2022 at 17:24:10 UTC+1, Ben Bacarisse wrote:
>> >> Mr Flibble <fli...@reddwarf.jmc> writes:
>> >>
>> >> > On Wed, 6 Jul 2022 13:50:16 +0100
>> >> > Andy Walker <a...@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.
>> >>
>> > Three way deciders are useful.
>> As I said.
>> > They are built into optimisers. Working out
>> > that code always passes through a given point is the same problem as the
>> > halting problem if all the data is constant, and a similar problem if it is
>> > variable. In practice most code written by humans can either simply be shown
>> > to halt or simply be shown to loop forever (or be data-dependent). Few
>> > people write functions with complex while conditions that equate to famous
>> > problems in mathematics.
>> >
>> > So a fairly simple three way built-in halt decider is useful as part
>> > of an optimiser.
>> You may well be more up-to-date than I am, but the last time I knew,
>> optimisers had little more than a basic flow analysis. What is the
>> state of the art nowadays?
>>
> Constant propagation. In C++, you can help the compiler along with
> constexpr. constexpr means "this is a pure function of its arguments,
> and when called with constants, yields a constant". However of course
> it is possible to build a constexpr which is too hard for the compiler
> to resolve. This happened to us in real code. A keen "latest and
> greatest" C++ programmer pushed the compiler beyond its limits, and
> the build broke on the CI server.

I think we are talking at cross-purposes. You said compilers nowadays
analyse code behaviour in a way similar to a halt decider (imperfectly
of course). I said nothing I'd seem came close to that sort of
analysis, but that I am probably behind the times. Your reply does not
help me to learn what you know that I don't.

--
Ben.

On Thu, 07 Jul 2022 01:21:36 +0100
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Mr Flibble <flibble@reddwarf.jmc> writes:
>
> > On Wed, 06 Jul 2022 19:15:06 +0100
> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> >
> >> Mr Flibble <flibble@reddwarf.jmc> writes:
> >>
> >> > 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.
> >>
> >> It's vague by my standards, but then there is no reason for you to
> >> care about that. If it's as clear as you want it to be, that's
> >> fine.
> >> > 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.
> >>
> >> Right. That's not even a useful three-way decider since no one
> >> really cares about that one case in practical situations.
> >
> > Practical situations? It is a thought experiment: a potential
> > refutation of the HP proofs.
>
> No it isn't. The proofs are about halt deciders, and you are not
> proposing or describing a halt decider. Programs (TMs, whatever) that
> do not get every instance of the halting problem right are ten-a-penny
> and say nothing about the proofs.
>
> Their only value is in practical situations, but you seem to agree
> with me that your suggestion was never intended to, and does not
> have, that kind of utility.
I believe my signaling halt decider should always get the answer right
ergo is a potential refutation of the proofs.

/Flibble

On Thu, 7 Jul 2022 00:22:54 +0100
Andy Walker <anw@cuboid.co.uk> wrote:

> On 06/07/2022 17:03, Mr Flibble wrote:
> > So rather than just hand-waving why don't you point out any actual
> > errors in my proposed solution, Mr Andy Walker.
>
> I did, when you proposed it: you have not defined
> "pathological". When you do, you will find that either you have
> defined it as a trivial property that advances the theory of the HP
> not one jot, or else that the detection of pathological programs is
> as insoluble as the HP and you have not solved anything of interest
> to the theorists. Note also Ben's reply.

The halting problem itself defines what it means for an input to
pathological and my halting decider can detect such an input and signal
an exception. Based on this I believe I do have something of interest
to the "theorists".

>
> Absent some formal definition of "pathological", hand waving
> is all that anyone [inc you] can do with your proposal.

Hand waving is all you've got as you don't appear to have any actual
rebuttal.

/Flibble

On 7/6/2022 7:52 PM, Mr Flibble wrote:
> On Thu, 07 Jul 2022 01:21:36 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>>> On Wed, 06 Jul 2022 19:15:06 +0100
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>
>>>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>>>
>>>>> 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.
>>>>
>>>> It's vague by my standards, but then there is no reason for you to
>>>> care about that. If it's as clear as you want it to be, that's
>>>> fine.
>>>>> 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.
>>>>
>>>> Right. That's not even a useful three-way decider since no one
>>>> really cares about that one case in practical situations.
>>>
>>> Practical situations? It is a thought experiment: a potential
>>> refutation of the HP proofs.
>>
>> No it isn't. The proofs are about halt deciders, and you are not
>> proposing or describing a halt decider. Programs (TMs, whatever) that
>> do not get every instance of the halting problem right are ten-a-penny
>> and say nothing about the proofs.
>>
>> Their only value is in practical situations, but you seem to agree
>> with me that your suggestion was never intended to, and does not
>> have, that kind of utility.
>
> I believe my signaling halt decider should always get the answer right
> ergo is a potential refutation of the proofs.
>
> /Flibble
>

Yet since you do not even define its criterion measure everything else
that you says about it is utterly useless babble.

--
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 7:57 PM, Mr Flibble wrote:
> On Thu, 7 Jul 2022 00:22:54 +0100
> Andy Walker <anw@cuboid.co.uk> wrote:
>
>> On 06/07/2022 17:03, Mr Flibble wrote:
>>> So rather than just hand-waving why don't you point out any actual
>>> errors in my proposed solution, Mr Andy Walker.
>>
>> I did, when you proposed it: you have not defined
>> "pathological". When you do, you will find that either you have
>> defined it as a trivial property that advances the theory of the HP
>> not one jot, or else that the detection of pathological programs is
>> as insoluble as the HP and you have not solved anything of interest
>> to the theorists. Note also Ben's reply.
>
> The halting problem itself defines what it means for an input to
> pathological and my halting decider can detect such an input and signal
> an exception. Based on this I believe I do have something of interest
> to the "theorists".

What is the freaking "if" statement that your decider uses?

I already designed a pathological self-reference decider years ago.

Halting Problem Proof from Finite Strings to Final States
https://www.researchgate.net/publication/323384939_Halting_Problem_Proof_from_Finite_Strings_to_Final_States

>>
>> Absent some formal definition of "pathological", hand waving
>> is all that anyone [inc you] can do with your proposal.
>
> Hand waving is all you've got as you don't appear to have any actual
> rebuttal.
>
> /Flibble
>
>

--
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/22 9:32 AM, 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.
>

Since P(P) Halts when H(P,P) returns 0, this is obviously incorrect.

Your dishonest dodge of saying the input to H(P,P) doesn't actually
represent the program P(P) just says that H isn't actually meeting the
definition of a Halt Decider.

This is redoubled by the fact that the definition of P says P is asking
H what P(P) does, so if H(P,P) doesn't mean that you also haven't
constructed the correct P to match the proof you claim to refute.

Thus, all you have proved is that your arguement is bogus and just based
on misdefining things, in other words, you lie.

> 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
>
>
>

Your argument: ALL LIES.

On Wed, 6 Jul 2022 20:10:29 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/6/2022 7:57 PM, Mr Flibble wrote:
> > On Thu, 7 Jul 2022 00:22:54 +0100
> > Andy Walker <anw@cuboid.co.uk> wrote:
> >
> >> On 06/07/2022 17:03, Mr Flibble wrote:
> >>> So rather than just hand-waving why don't you point out any actual
> >>> errors in my proposed solution, Mr Andy Walker.
> >>
> >> I did, when you proposed it: you have not defined
> >> "pathological". When you do, you will find that either you have
> >> defined it as a trivial property that advances the theory of the HP
> >> not one jot, or else that the detection of pathological programs is
> >> as insoluble as the HP and you have not solved anything of interest
> >> to the theorists. Note also Ben's reply.
> >
> > The halting problem itself defines what it means for an input to
> > pathological and my halting decider can detect such an input and
> > signal an exception. Based on this I believe I do have something
> > of interest to the "theorists".
>
> What is the freaking "if" statement that your decider uses?
>
> I already designed a pathological self-reference decider years ago.
>
> Halting Problem Proof from Finite Strings to Final States
> https://www.researchgate.net/publication/323384939_Halting_Problem_Proof_from_Finite_Strings_to_Final_States

Merely detecting "self-reference" is not sufficient for detecting
pathological inputs as it will give a false positive for the following:

void Px(void (*x)())
{ (void) H(x, x);
return;
}

This has been explained to you many times now. My signaling halting
decider does not suffer from this problem.

/Flibble

Mr Flibble <flibble@reddwarf.jmc> writes:

> On Thu, 07 Jul 2022 01:21:36 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>> > On Wed, 06 Jul 2022 19:15:06 +0100
>> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

>> >> That's not even a useful three-way decider since no one
>> >> really cares about that one case in practical situations.
>> >
>> > Practical situations? It is a thought experiment: a potential
>> > refutation of the HP proofs.
>>
>> No it isn't. The proofs are about halt deciders, and you are not
>> proposing or describing a halt decider. Programs (TMs, whatever) that
>> do not get every instance of the halting problem right are ten-a-penny
>> and say nothing about the proofs.
>>
>> Their only value is in practical situations, but you seem to agree
>> with me that your suggestion was never intended to, and does not
>> have, that kind of utility.
>
> I believe my signaling halt decider should always get the answer right
> ergo is a potential refutation of the proofs.

I can't see why you believe that since you explicitly state otherwise.
Your original post a vague about a lot of things, but it seemed pretty
clear about this.

--
Ben.

On Thu, 07 Jul 2022 20:37:53 +0100
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Mr Flibble <flibble@reddwarf.jmc> writes:
>
> > On Thu, 07 Jul 2022 01:21:36 +0100
> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> >
> >> Mr Flibble <flibble@reddwarf.jmc> writes:
> >>
> >> > On Wed, 06 Jul 2022 19:15:06 +0100
> >> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
> >> >> That's not even a useful three-way decider since no one
> >> >> really cares about that one case in practical situations.
> >> >
> >> > Practical situations? It is a thought experiment: a potential
> >> > refutation of the HP proofs.
> >>
> >> No it isn't. The proofs are about halt deciders, and you are not
> >> proposing or describing a halt decider. Programs (TMs, whatever)
> >> that do not get every instance of the halting problem right are
> >> ten-a-penny and say nothing about the proofs.
> >>
> >> Their only value is in practical situations, but you seem to agree
> >> with me that your suggestion was never intended to, and does not
> >> have, that kind of utility.
> >
> > I believe my signaling halt decider should always get the answer
> > right ergo is a potential refutation of the proofs.
>
> I can't see why you believe that since you explicitly state otherwise.
> Your original post a vague about a lot of things, but it seemed pretty
> clear about this.
Getting the answer right means one of three things for my signaling
halting decider:

1) Decision halting
2) Decision non-halting
3) Exception (pathological input)

If you want to assert that having a third outcome of a exception signal
means this has nothing to do with the HP then you are free to assert
that but I disagree.

/Flibble

Mr Flibble <flibble@reddwarf.jmc> writes:

> On Thu, 07 Jul 2022 20:37:53 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>> > On Thu, 07 Jul 2022 01:21:36 +0100
>> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> >
>> >> Mr Flibble <flibble@reddwarf.jmc> writes:
>> >>
>> >> > On Wed, 06 Jul 2022 19:15:06 +0100
>> >> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>> >> >> That's not even a useful three-way decider since no one
>> >> >> really cares about that one case in practical situations.
>> >> >
>> >> > Practical situations? It is a thought experiment: a potential
>> >> > refutation of the HP proofs.
>> >>
>> >> No it isn't. The proofs are about halt deciders, and you are not
>> >> proposing or describing a halt decider. Programs (TMs, whatever)
>> >> that do not get every instance of the halting problem right are
>> >> ten-a-penny and say nothing about the proofs.
>> >>
>> >> Their only value is in practical situations, but you seem to agree
>> >> with me that your suggestion was never intended to, and does not
>> >> have, that kind of utility.
>> >
>> > I believe my signaling halt decider should always get the answer
>> > right ergo is a potential refutation of the proofs.
>>
>> I can't see why you believe that since you explicitly state otherwise.
>> Your original post a vague about a lot of things, but it seemed pretty
>> clear about this.
>
> Getting the answer right means one of three things for my signaling
> halting decider:
>
> 1) Decision halting
> 2) Decision non-halting
> 3) Exception (pathological input)

Yes, as I said, that much was clear. Such "deciders" and not very
interesting unless 3 is a semantic property of the computation being
decided, in which case I refer you to Rice's theorem.

> If you want to assert that having a third outcome of a exception signal
> means this has nothing to do with the HP then you are free to assert
> that but I disagree.

The fact that such TMs (or C programs, or algorithms, or whatever) exist
is a trivial fact not in dispute.

Of course, there are /some/ meanings for 3 (and the consequent 1 and 2)
for which you would /not/ be able to write the code, (since it would, in
fact, imply a real halt decider) but you don't say enough about these
conditions to be able to say more.

--
Ben.

On Thu, 07 Jul 2022 21:50:21 +0100
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Mr Flibble <flibble@reddwarf.jmc> writes:
>
> > On Thu, 07 Jul 2022 20:37:53 +0100
> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> >
> >> Mr Flibble <flibble@reddwarf.jmc> writes:
> >>
> >> > On Thu, 07 Jul 2022 01:21:36 +0100
> >> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> >> >
> >> >> Mr Flibble <flibble@reddwarf.jmc> writes:
> >> >>
> >> >> > On Wed, 06 Jul 2022 19:15:06 +0100
> >> >> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> >>
> >> >> >> That's not even a useful three-way decider since no one
> >> >> >> really cares about that one case in practical situations.
> >> >> >>
> >> >> >
> >> >> > Practical situations? It is a thought experiment: a potential
> >> >> > refutation of the HP proofs.
> >> >>
> >> >> No it isn't. The proofs are about halt deciders, and you are
> >> >> not proposing or describing a halt decider. Programs (TMs,
> >> >> whatever) that do not get every instance of the halting problem
> >> >> right are ten-a-penny and say nothing about the proofs.
> >> >>
> >> >> Their only value is in practical situations, but you seem to
> >> >> agree with me that your suggestion was never intended to, and
> >> >> does not have, that kind of utility.
> >> >
> >> > I believe my signaling halt decider should always get the answer
> >> > right ergo is a potential refutation of the proofs.
> >>
> >> I can't see why you believe that since you explicitly state
> >> otherwise. Your original post a vague about a lot of things, but
> >> it seemed pretty clear about this.
> >
> > Getting the answer right means one of three things for my signaling
> > halting decider:
> >
> > 1) Decision halting
> > 2) Decision non-halting
> > 3) Exception (pathological input)
>
> Yes, as I said, that much was clear. Such "deciders" and not very
> interesting unless 3 is a semantic property of the computation being
> decided, in which case I refer you to Rice's theorem.
>
> > If you want to assert that having a third outcome of a exception
> > signal means this has nothing to do with the HP then you are free
> > to assert that but I disagree.
>
> The fact that such TMs (or C programs, or algorithms, or whatever)
> exist is a trivial fact not in dispute.
>
> Of course, there are /some/ meanings for 3 (and the consequent 1 and
> 2) for which you would /not/ be able to write the code, (since it
> would, in fact, imply a real halt decider) but you don't say enough
> about these conditions to be able to say more.
I am aware of the problems with a simulation-based halting decider: for
returning a decision of non-halting the SHD would rely on detecting
repeated machine state given a machine of finite size has a finite
number of configurations; for returning any decision I also appreciate
that the SHD might not answer within the lifetime of the observable
universe but that would still, I suggest, be a finite not infinite time.

/Flibble