info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Halting Problem Solved (Black Box Decider Theory)
5 views
Skip to first unread message
olcott
Jul 16, 2021, 2:31:43 PM7/16/21
to
On 7/16/2021 1:00 PM, Mr Flibble wrote:
> A pathological program that executes a black box decider and returns the
> opposite result can be detected by the black box decider.
>
> So there are THREE possible results the black box decider can return:
>
> 1) Program halts
> 2) Program does not halt
> 3) Program is pathological and can be discarded as invalid.
>
> Halting problem solved.
>
> Next.
>
> /Flibble
>
Rice's theorem says that pathological self-reference is (in at least
some cases) an undecidable property. Unless halting is decidable then
neither is pathological self-reference.
Halting <is> decidable.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
H aborts its input on the basis that the above call from P to H(P,P) is
essentially infinitely recursive.
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
> A pathological program that executes a black box decider and returns the
> opposite result can be detected by the black box decider.
>
> So there are THREE possible results the black box decider can return:
>
> 1) Program halts
> 2) Program does not halt
> 3) Program is pathological and can be discarded as invalid.
>
> Halting problem solved.
>
> Next.
>
> /Flibble
>
Rice's theorem says that pathological self-reference is (in at least
some cases) an undecidable property. Unless halting is decidable then
neither is pathological self-reference.
Halting <is> decidable.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
H aborts its input on the basis that the above call from P to H(P,P) is
essentially infinitely recursive.
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
olcott
Jul 16, 2021, 3:56:10 PM7/16/21
to
On 7/16/2021 2:46 PM, Alan Mackenzie wrote:
> Mr Flibble <fli...@reddwarf.jmc> wrote:
>> On Fri, 16 Jul 2021 19:28:12 +0100
>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>>> Single. Year. In the end, I decided to bring it up myself and set
>>> explaining what's wrong the argument as an exercise. I wonder if any
>>> of the students here would like to have a go at that?
>
>>> (By student, I mean anyone reading this who has not read a textbook on
>>> this topic.)
>
>> I simply don't believe you. You appear to be a pathological liar; feel
>> free to provide evidence of what you are claiming.
>
> That's quite uncalled for. Reading (or browsing) these interminable
> threads over the last months, it's quite clear that Ben is an expert.
> You, by contrast, are merely exercising your freedom of expression.
>
> That you, in all apparent seriousness, put forward your 1), 2), 3) above
> indicates you are far from an expert. These things aren't a matter of
> opinion, they're a matter of settled fact.
>
> When it comes to the halting problem, there is no dispute, except amongst
> cranks. It has a rock solid proof, much as do the trisection of the
> angle or the squaring of the circle.
>
>> /Flibble
>
None-the-less when an input does the opposite of whatever its
corresponding halt decider decides those that are not mere sheep
following the herd of others realize that this exactly matches the
self-contradictory pattern of the Liar Paradox and is thereby erroneous.
If a halt decider merely watches the behavior of its simulated input
this eliminates the self-contradictory nature of the conventional
counter-examples. The halt decider cannot possibly have any effect on
its own halting decision because it has no behavior that can possibly
have any effect on this decision.
In this case the input cannot possibly do the opposite of whatever the
halt decider decides.
> Mr Flibble <fli...@reddwarf.jmc> wrote:
>> On Fri, 16 Jul 2021 19:28:12 +0100
>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>
>>> Mr Flibble <fli...@reddwarf.jmc> writes:
>
>>>> A pathological program that executes a black box decider and
>>>> returns the opposite result can be detected by the black box
>>>> decider.
>
>>>> So there are THREE possible results the black box decider can
>>>> return:
>
>>>> 1) Program halts
>>>> 2) Program does not halt
>>>> 3) Program is pathological and can be discarded as invalid.
>
>>>> Halting problem solved.
>
>>> This one came up every year when one teaches this material. Every.
>>> Mr Flibble <fli...@reddwarf.jmc> writes:
>
>>>> A pathological program that executes a black box decider and
>>>> returns the opposite result can be detected by the black box
>>>> decider.
>
>>>> So there are THREE possible results the black box decider can
>>>> return:
>
>>>> 1) Program halts
>>>> 2) Program does not halt
>>>> 3) Program is pathological and can be discarded as invalid.
>
>>>> Halting problem solved.
>
>>> Single. Year. In the end, I decided to bring it up myself and set
>>> explaining what's wrong the argument as an exercise. I wonder if any
>>> of the students here would like to have a go at that?
>
>>> (By student, I mean anyone reading this who has not read a textbook on
>>> this topic.)
>
>> I simply don't believe you. You appear to be a pathological liar; feel
>> free to provide evidence of what you are claiming.
>
> That's quite uncalled for. Reading (or browsing) these interminable
> threads over the last months, it's quite clear that Ben is an expert.
> You, by contrast, are merely exercising your freedom of expression.
>
> That you, in all apparent seriousness, put forward your 1), 2), 3) above
> indicates you are far from an expert. These things aren't a matter of
> opinion, they're a matter of settled fact.
>
> When it comes to the halting problem, there is no dispute, except amongst
> cranks. It has a rock solid proof, much as do the trisection of the
> angle or the squaring of the circle.
>
>> /Flibble
>
None-the-less when an input does the opposite of whatever its
corresponding halt decider decides those that are not mere sheep
following the herd of others realize that this exactly matches the
self-contradictory pattern of the Liar Paradox and is thereby erroneous.
If a halt decider merely watches the behavior of its simulated input
this eliminates the self-contradictory nature of the conventional
counter-examples. The halt decider cannot possibly have any effect on
its own halting decision because it has no behavior that can possibly
have any effect on this decision.
In this case the input cannot possibly do the opposite of whatever the
halt decider decides.
olcott
Jul 16, 2021, 4:01:05 PM7/16/21
to
On 7/16/2021 2:56 PM, Mr Flibble wrote:
> Expert? I have a CompSci BSc (Hons) degree, dear. Also, "far from an
> expert" is an attack on the person and not the argument, a logical
> fallacy, dear.
>
> Rock solid proof? Prove it, dear.
>
> /Flibble
>
People that are stuck in rebuttal mode switch to rhetoric when they run
out of reasoning.
If they weren't damn liars they would acknowledge that they have run out
of reasoning rather than switch to rhetoric.
> expert" is an attack on the person and not the argument, a logical
> fallacy, dear.
>
>>
>> When it comes to the halting problem, there is no dispute, except
>> amongst cranks. It has a rock solid proof, much as do the trisection
>> of the angle or the squaring of the circle.
>
> Cranks? Ad hom logical fallacy (again), dear.
>>
>> When it comes to the halting problem, there is no dispute, except
>> amongst cranks. It has a rock solid proof, much as do the trisection
>> of the angle or the squaring of the circle.
>
>
> Rock solid proof? Prove it, dear.
>
> /Flibble
>
People that are stuck in rebuttal mode switch to rhetoric when they run
out of reasoning.
If they weren't damn liars they would acknowledge that they have run out
of reasoning rather than switch to rhetoric.
olcott
Jul 16, 2021, 6:32:11 PM7/16/21
to
> you study things like the halting problem?
>
>> Also, "far from an expert" is an attack on the person and not the
>> argument, a logical fallacy, dear.
>
> No, it's an attack on your 1), 2), 3). No expert could have seriously
>> Also, "far from an expert" is an attack on the person and not the
>> argument, a logical fallacy, dear.
>
> put 3) forward. Like Peter Olcott, you want people to fall into the trap
> of taking established falsehoods seriously and debating them point by
> point. When somebody such as yourself posts falsehoods, particularly
> ludicrous falsehoods, it is folly to go into an equal status argument
> with those falsehoods. Rubbish must be decried as rubbish, and the
> people advancing falsehoods must also be so decried. The truth matters,
> and in this matter, the truth has been settled for many decades.
>
> Every program is either halting or not halting. Assuming the black box
> returns the correct result, it can only return 1) or 2). There is no
> such thing as a "pathological program" in this sense.
That an input was intentionally defined to do the opposite of whatever a
corresponding TM decides <is> the exact same pathology as the liar paradox.
That an input was intentionally defined to do the opposite of whatever a
corresponding TM decides <is> the exact same pathology as the liar paradox.
That an input was intentionally defined to do the opposite of whatever a
corresponding TM decides <is> the exact same pathology as the liar paradox.
Flibble sees this. You as one of many mere sheep refuse to even look at
the counter-argument. That is despicable.
1,2,3 is the same as my work from 2004.
> How would it
> behave? Somehow neither halt, nor not halt? Get stuck in some sort of
> limbo where it's no longer running yet hasn't yet ceased to run? The
> notion is incoherent.
>
> Come on Mr Flibble, please assure us all that your 1), 2), 3) above was
> intended as some sort of joke, or parody, or something.
>
>>> When it comes to the halting problem, there is no dispute, except
>>> amongst cranks. It has a rock solid proof, much as do the trisection
>>> of the angle or the squaring of the circle.
>
>> Cranks? Ad hom logical fallacy (again), dear.
>
> Not at all. A statement of plain fact. The truth of the halting problem
>>> When it comes to the halting problem, there is no dispute, except
>>> amongst cranks. It has a rock solid proof, much as do the trisection
>>> of the angle or the squaring of the circle.
>
>> Cranks? Ad hom logical fallacy (again), dear.
>
> is settled, and only cranks dispute it.
>
>> Rock solid proof? Prove it, dear.
>
> No. I don't have the energy. You can find proofs far more eloquent than
>> Rock solid proof? Prove it, dear.
>
> I could give in the text books you should still have from your student
> days. Failing that, ask Peter Olcott. I believe he keeps them on his
> website.
>
>> /Flibble
olcott
Jul 17, 2021, 12:15:55 AM7/17/21
to
On 7/16/2021 5:54 PM, Alan Mackenzie wrote:
> [ Malicious cross-posting removed ]
> would like to label as "pathalogical" either halts or it doesn't. There
> is no such thing as a "pathalogical" program in this sense. I note you
> decline to address my questions (below) as to its behaviour.
>
rec routine P
§L:if T[P] go to L
Return §
// Strachey(1965) "An impossible program" CPL translated to C
// https://doi.org/10.1093/comjnl/7.4.313
void P()
{
if (T((u32)P))
L: goto L;
}
Which Boolean value can the Strachey T return to the Strachey P that is
the correct halt status of P ?
>> Flibble sees this. You as one of many mere sheep refuse to even look at
>> the counter-argument. That is despicable.
>
> I have looked at it, analysed it in detail, and it is rubbish. A program
> either terminates or it does not. There is no magical third behaviour.
> [ Malicious cross-posting removed ]
>
> In comp.theory olcott <No...@nowhere.com> wrote:
>> On 7/16/2021 5:24 PM, Alan Mackenzie wrote:
>>> Mr Flibble <fli...@reddwarf.jmc> wrote:
>>>> On Fri, 16 Jul 2021 19:46:28 -0000 (UTC)
>>>> Alan Mackenzie <a...@muc.de> wrote:
>
>>>>> Mr Flibble <fli...@reddwarf.jmc> wrote:
>>>>>> On Fri, 16 Jul 2021 19:28:12 +0100
>>>>>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>
>>>>>>> Mr Flibble <fli...@reddwarf.jmc> writes:
>
> [ .... ]
> In comp.theory olcott <No...@nowhere.com> wrote:
>> On 7/16/2021 5:24 PM, Alan Mackenzie wrote:
>>> Mr Flibble <fli...@reddwarf.jmc> wrote:
>>>> On Fri, 16 Jul 2021 19:46:28 -0000 (UTC)
>>>> Alan Mackenzie <a...@muc.de> wrote:
>
>>>>> Mr Flibble <fli...@reddwarf.jmc> wrote:
>>>>>> On Fri, 16 Jul 2021 19:28:12 +0100
>>>>>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>
>>>>>>> Mr Flibble <fli...@reddwarf.jmc> writes:
>
>
>>>>>>>> So there are THREE possible results the black box decider can
>>>>>>>> return:
>
>>>>>>>> 1) Program halts
>>>>>>>> 2) Program does not halt
>>>>>>>> 3) Program is pathological and can be discarded as invalid.
>
>>>>>>>> Halting problem solved.
>
> [ .... ]
>>>>>>>> So there are THREE possible results the black box decider can
>>>>>>>> return:
>
>>>>>>>> 1) Program halts
>>>>>>>> 2) Program does not halt
>>>>>>>> 3) Program is pathological and can be discarded as invalid.
>
>>>>>>>> Halting problem solved.
>
>
>>>> Also, "far from an expert" is an attack on the person and not the
>>>> argument, a logical fallacy, dear.
>
>>> No, it's an attack on your 1), 2), 3). No expert could have seriously
>>> put 3) forward. Like Peter Olcott, you want people to fall into the
>>> trap of taking established falsehoods seriously and debating them
>>> point by point. When somebody such as yourself posts falsehoods,
>>> particularly ludicrous falsehoods, it is folly to go into an equal
>>> status argument with those falsehoods. Rubbish must be decried as
>>> rubbish, and the people advancing falsehoods must also be so decried.
>>> The truth matters, and in this matter, the truth has been settled for
>>> many decades.
>
>>> Every program is either halting or not halting. Assuming the black box
>>> returns the correct result, it can only return 1) or 2). There is no
>>> such thing as a "pathological program" in this sense.
>
>> That an input was intentionally defined to do the opposite of whatever a
>> corresponding TM decides <is> the exact same pathology as the liar paradox.
>
> What corresponding TM? I never mentioned one. Just that the program you
>>>> Also, "far from an expert" is an attack on the person and not the
>>>> argument, a logical fallacy, dear.
>
>>> No, it's an attack on your 1), 2), 3). No expert could have seriously
>>> put 3) forward. Like Peter Olcott, you want people to fall into the
>>> trap of taking established falsehoods seriously and debating them
>>> point by point. When somebody such as yourself posts falsehoods,
>>> particularly ludicrous falsehoods, it is folly to go into an equal
>>> status argument with those falsehoods. Rubbish must be decried as
>>> rubbish, and the people advancing falsehoods must also be so decried.
>>> The truth matters, and in this matter, the truth has been settled for
>>> many decades.
>
>>> Every program is either halting or not halting. Assuming the black box
>>> returns the correct result, it can only return 1) or 2). There is no
>>> such thing as a "pathological program" in this sense.
>
>> That an input was intentionally defined to do the opposite of whatever a
>> corresponding TM decides <is> the exact same pathology as the liar paradox.
>
> would like to label as "pathalogical" either halts or it doesn't. There
> is no such thing as a "pathalogical" program in this sense. I note you
> decline to address my questions (below) as to its behaviour.
>
rec routine P
§L:if T[P] go to L
Return §
// Strachey(1965) "An impossible program" CPL translated to C
// https://doi.org/10.1093/comjnl/7.4.313
void P()
{
if (T((u32)P))
L: goto L;
}
Which Boolean value can the Strachey T return to the Strachey P that is
the correct halt status of P ?
>> Flibble sees this. You as one of many mere sheep refuse to even look at
>> the counter-argument. That is despicable.
>
> either terminates or it does not. There is no magical third behaviour.
olcott
Jul 17, 2021, 10:37:52 AM7/17/21
to
On 7/17/2021 4:10 AM, Alan Mackenzie wrote:
> [ Malicious cross-posting removed ]
>
> In comp.theory olcott <No...@nowhere.com> wrote:
>> On 7/16/2021 5:54 PM, Alan Mackenzie wrote:
>
>>> In comp.theory olcott <No...@nowhere.com> wrote:
>>>> On 7/16/2021 5:24 PM, Alan Mackenzie wrote:
>>>>> Mr Flibble <fli...@reddwarf.jmc> wrote:
>>>>>> On Fri, 16 Jul 2021 19:46:28 -0000 (UTC)
>>>>>> Alan Mackenzie <a...@muc.de> wrote:
>
>>>>>>> Mr Flibble <fli...@reddwarf.jmc> wrote:
>>>>>>>> On Fri, 16 Jul 2021 19:28:12 +0100
>>>>>>>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>
>>>>>>>>> Mr Flibble <fli...@reddwarf.jmc> writes:
>
>>> [ .... ]
>
>>>>>>>>>> So there are THREE possible results the black box decider can
>>>>>>>>>> return:
>
>>>>>>>>>> 1) Program halts
>>>>>>>>>> 2) Program does not halt
>>>>>>>>>> 3) Program is pathological and can be discarded as invalid.
>
>>>>>>>>>> Halting problem solved.
>
> [ .... ]
>
> [ Malicious cross-posting removed ]
>
> In comp.theory olcott <No...@nowhere.com> wrote:
>> On 7/16/2021 5:54 PM, Alan Mackenzie wrote:
>
>>> In comp.theory olcott <No...@nowhere.com> wrote:
>>>> On 7/16/2021 5:24 PM, Alan Mackenzie wrote:
>>>>> Mr Flibble <fli...@reddwarf.jmc> wrote:
>>>>>> On Fri, 16 Jul 2021 19:46:28 -0000 (UTC)
>>>>>> Alan Mackenzie <a...@muc.de> wrote:
>
>>>>>>> Mr Flibble <fli...@reddwarf.jmc> wrote:
>>>>>>>> On Fri, 16 Jul 2021 19:28:12 +0100
>>>>>>>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>
>>>>>>>>> Mr Flibble <fli...@reddwarf.jmc> writes:
>
>>> [ .... ]
>
>>>>>>>>>> So there are THREE possible results the black box decider can
>>>>>>>>>> return:
>
>>>>>>>>>> 1) Program halts
>>>>>>>>>> 2) Program does not halt
>>>>>>>>>> 3) Program is pathological and can be discarded as invalid.
>
>>>>>>>>>> Halting problem solved.
>
> [ .... ]
>
>>>>> Every program is either halting or not halting. Assuming the black
>>>>> box returns the correct result, it can only return 1) or 2). There
>>>>> is no such thing as a "pathological program" in this sense.
>
>>>> That an input was intentionally defined to do the opposite of
>>>> whatever a corresponding TM decides <is> the exact same pathology as
>>>> the liar paradox.
>
>>> What corresponding TM? I never mentioned one. Just that the program you
>>> would like to label as "pathalogical" either halts or it doesn't. There
>>> is no such thing as a "pathalogical" program in this sense. I note you
>>> decline to address my questions (below) as to its behaviour.
>
>
>> rec routine P
>> §L:if T[P] go to L
>> Return §
>
>
>> // Strachey(1965) "An impossible program" CPL translated to C
>> // https://doi.org/10.1093/comjnl/7.4.313
>> void P()
>> {
>> if (T((u32)P))
>> L: goto L;
>> }
>
>> Which Boolean value can the Strachey T return to the Strachey P that is
>> the correct halt status of P ?
>
> You're evading the question. This "pathalogical" program that neither
>>>>> box returns the correct result, it can only return 1) or 2). There
>>>>> is no such thing as a "pathological program" in this sense.
>
>>>> That an input was intentionally defined to do the opposite of
>>>> whatever a corresponding TM decides <is> the exact same pathology as
>>>> the liar paradox.
>
>>> What corresponding TM? I never mentioned one. Just that the program you
>>> would like to label as "pathalogical" either halts or it doesn't. There
>>> is no such thing as a "pathalogical" program in this sense. I note you
>>> decline to address my questions (below) as to its behaviour.
>
>
>> rec routine P
>> §L:if T[P] go to L
>> Return §
>
>
>> // Strachey(1965) "An impossible program" CPL translated to C
>> // https://doi.org/10.1093/comjnl/7.4.313
>> void P()
>> {
>> if (T((u32)P))
>> L: goto L;
>> }
>
>> Which Boolean value can the Strachey T return to the Strachey P that is
>> the correct halt status of P ?
>
> halts nor fails to halt - what does its behaviour look like? You have no
> answer. There is no "pathalogical" behaviour, here. The program either
> halts or fails to halt. There is no third possibility.
>
> Regarding your question, which is something completely different, the
> answer is that the T cannot return a correct halt status of P. Why is
> that a problem? We've known for many decades that this is the case.
>
What has not been know for many decades is that undecidable decision
problems are merely errors and nothing more.
Mathematicians really hate to go to the philosophical foundation of the
notion of truth itself and instead continue the religion of what they
learned by rote.
>>>> Flibble sees this. You as one of many mere sheep refuse to even look at
>>>> the counter-argument. That is despicable.
>
>>> I have looked at it, analysed it in detail, and it is rubbish. A program
>>> either terminates or it does not. There is no magical third behaviour.
>
David Brown
Jul 17, 2021, 10:47:17 AM7/17/21
to
On 17/07/2021 00:32, olcott wrote:
> On 7/16/2021 5:24 PM, Alan Mackenzie wrote:
>>
>> Every program is either halting or not halting. Assuming the black box
>> returns the correct result, it can only return 1) or 2). There is no
>> such thing as a "pathological program" in this sense.
>
> That an input was intentionally defined to do the opposite of whatever a
> corresponding TM decides <is> the exact same pathology as the liar paradox.
>
> That an input was intentionally defined to do the opposite of whatever a
> corresponding TM decides <is> the exact same pathology as the liar paradox.
>
> That an input was intentionally defined to do the opposite of whatever a
> corresponding TM decides <is> the exact same pathology as the liar paradox.
>
Sticking your fingers in your ears and shouting "Blah, blah, blah, I'm
> On 7/16/2021 5:24 PM, Alan Mackenzie wrote:
>>
>> Every program is either halting or not halting. Assuming the black box
>> returns the correct result, it can only return 1) or 2). There is no
>> such thing as a "pathological program" in this sense.
>
> That an input was intentionally defined to do the opposite of whatever a
> corresponding TM decides <is> the exact same pathology as the liar paradox.
>
> That an input was intentionally defined to do the opposite of whatever a
> corresponding TM decides <is> the exact same pathology as the liar paradox.
>
> That an input was intentionally defined to do the opposite of whatever a
> corresponding TM decides <is> the exact same pathology as the liar paradox.
>
not listening" does not constitute an argument.
> Flibble sees this. You as one of many mere sheep refuse to even look at
> the counter-argument. That is despicable.
>
does not mean you are the lone genius who sees the truth. It means you
are wrong.
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein
Opposition does not imply that you are a "great spirit". You'd
appreciate that, if you understood anything about logic.
olcott
Jul 17, 2021, 11:35:21 AM7/17/21
to
On 7/16/2021 5:59 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 7/16/2021 3:46 PM, Ben Bacarisse wrote:
>>>
>>>> Halting <is> decidable.
Here is Ben's lie:
>>> No, but more specifically, you've told us that your H gets this case
>>> wrong:
>>
>> No you God damned liar I never said that.
>
> It's true that you never admitted it was wrong,
Above is his admission that it was a lie.
> but you told us that
> H(P,P) == 0 and that P(P) halts. That's the wrong answer, and you knew
> it at the time.
>
I have always known that it is the correct answer, (as shown below) so
you lie again.
I really hope for your sake that this is an exaggeration:
Revelation 21:8 KJV
...all liars, shall have their part in the lake which
burneth with fire and brimstone: which is the second death.
When P(P) stops running because one of the function calls in its
infinite chain of function calls has been aborted this does not make
P(P) a halting computation.
void Infinite_Loop()
{
HERE: goto HERE;
}
_Infinite_Loop()
[00000ab6](01) 55 push ebp
[00000ab7](02) 8bec mov ebp,esp
[00000ab9](02) ebfe jmp 00000ab9
[00000abb](01) 5d pop ebp
[00000abc](01) c3 ret
Size in bytes:(0007) [00000abc]
When the simulating halt decider aborts its simulation of
Infinite_Loop() such that it stops running this does not make
Infinite_Loop() a halting computation.
> olcott <No...@NoWhere.com> writes:
>
>> On 7/16/2021 3:46 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 7/16/2021 1:00 PM, Mr Flibble wrote:
>>>>> A pathological program that executes a black box decider and returns the
>>>>> opposite result can be detected by the black box decider.
>>>>> So there are THREE possible results the black box decider can return:
>>>>> 1) Program halts
>>>>> 2) Program does not halt
>>>>> 3) Program is pathological and can be discarded as invalid.
>>>>> Halting problem solved.
>>>>> Next.
>>>>> /Flibble
>>>>>
>>>>
>>>> Rice's theorem says that pathological self-reference is (in at least
>>>> some cases) an undecidable property. Unless halting is decidable then
>>>> neither is pathological self-reference.
>>> I am cheered to see you've been paying attention.
>>>
>>>> On 7/16/2021 1:00 PM, Mr Flibble wrote:
>>>>> A pathological program that executes a black box decider and returns the
>>>>> opposite result can be detected by the black box decider.
>>>>> So there are THREE possible results the black box decider can return:
>>>>> 1) Program halts
>>>>> 2) Program does not halt
>>>>> 3) Program is pathological and can be discarded as invalid.
>>>>> Halting problem solved.
>>>>> Next.
>>>>> /Flibble
>>>>>
>>>>
>>>> Rice's theorem says that pathological self-reference is (in at least
>>>> some cases) an undecidable property. Unless halting is decidable then
>>>> neither is pathological self-reference.
>>>
>>>> Halting <is> decidable.
Here is Ben's lie:
>>> No, but more specifically, you've told us that your H gets this case
>>> wrong:
>>
>> No you God damned liar I never said that.
>
> It's true that you never admitted it was wrong,
Above is his admission that it was a lie.
> but you told us that
> H(P,P) == 0 and that P(P) halts. That's the wrong answer, and you knew
> it at the time.
>
I have always known that it is the correct answer, (as shown below) so
you lie again.
I really hope for your sake that this is an exaggeration:
Revelation 21:8 KJV
...all liars, shall have their part in the lake which
burneth with fire and brimstone: which is the second death.
When P(P) stops running because one of the function calls in its
infinite chain of function calls has been aborted this does not make
P(P) a halting computation.
void Infinite_Loop()
{
HERE: goto HERE;
}
_Infinite_Loop()
[00000ab6](01) 55 push ebp
[00000ab7](02) 8bec mov ebp,esp
[00000ab9](02) ebfe jmp 00000ab9
[00000abb](01) 5d pop ebp
[00000abc](01) c3 ret
Size in bytes:(0007) [00000abc]
When the simulating halt decider aborts its simulation of
Infinite_Loop() such that it stops running this does not make
Infinite_Loop() a halting computation.
olcott
Jul 17, 2021, 1:06:21 PM7/17/21
to
On 7/17/2021 11:24 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
> olcott <No...@NoWhere.com> writes:
>
>> On 7/17/2021 4:10 AM, Alan Mackenzie wrote:
>
>>> Regarding your question, which is something completely different, the
>>> answer is that the T cannot return a correct halt status of P. Why is
>>> that a problem? We've known for many decades that this is the case.
>>
>> What has not been know for many decades is that undecidable decision
>> problems are merely errors and nothing more.
>
> Don't be silly. Asking if a program halts or not is not an error or a
>
>>> Regarding your question, which is something completely different, the
>>> answer is that the T cannot return a correct halt status of P. Why is
>>> that a problem? We've known for many decades that this is the case.
>>
>> What has not been know for many decades is that undecidable decision
>> problems are merely errors and nothing more.
>
> bad question. Asking if a context-free grammar is ambiguous or is not
> an error or a bad question. Asking if two groups are isomorphic or not
> is not an error of a bad question. You just say these things for the
> sake of having an opinion.
>
As always you diligently make sure to ignore the full context.
(1) When we ask does every element of the set of valid declarative
sentences have as associated Boolean value? The answer is yes.
(2) When we ask does every element of the set of sentences have as
associated Boolean value? The answer is no.
When you ignore the full context you ignore the distinction between (1)
and (2). In this case it is an honest mistake on your part because the
distinction can be difficult to fully appreciate.
> The set of subsets of N is uncountable. The set of Turing machines is
> countable. There must be an uncountable number of undecidable sets of
> numbers. That we've been able to find a few is handy, but it's not
> surprising.
olcott
Jul 19, 2021, 10:41:25 AM7/19/21
to
On 7/17/2021 8:45 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 7/17/2021 11:24 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 7/17/2021 4:10 AM, Alan Mackenzie wrote:
>>>
>>>>> Regarding your question, which is something completely different, the
>>>>> answer is that the T cannot return a correct halt status of P. Why is
>>>>> that a problem? We've known for many decades that this is the case.
>>>>
>>>> What has not been know for many decades is that undecidable decision
>>>> problems are merely errors and nothing more.
>>> Don't be silly. Asking if a program halts or not is not an error or a
>>> bad question. Asking if a context-free grammar is ambiguous or is not
>>> an error or a bad question. Asking if two groups are isomorphic or not
>>> is not an error of a bad question. You just say these things for the
>>> sake of having an opinion.
>>>
>>
>> As always you diligently make sure to ignore the full context.
>
> You call is "extraneous complexity" but when you ignore it, it is
> olcott <No...@NoWhere.com> writes:
>
>> On 7/17/2021 11:24 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 7/17/2021 4:10 AM, Alan Mackenzie wrote:
>>>
>>>>> Regarding your question, which is something completely different, the
>>>>> answer is that the T cannot return a correct halt status of P. Why is
>>>>> that a problem? We've known for many decades that this is the case.
>>>>
>>>> What has not been know for many decades is that undecidable decision
>>>> problems are merely errors and nothing more.
>>> Don't be silly. Asking if a program halts or not is not an error or a
>>> bad question. Asking if a context-free grammar is ambiguous or is not
>>> an error or a bad question. Asking if two groups are isomorphic or not
>>> is not an error of a bad question. You just say these things for the
>>> sake of having an opinion.
>>>
>>
>> As always you diligently make sure to ignore the full context.
>
> usually crucial.
>
>> (1) When we ask does every element of the set of valid declarative
>> sentences have as associated Boolean value? The answer is yes.
>>
>> (2) When we ask does every element of the set of sentences have as
>> associated Boolean value? The answer is no.
>>
>> When you ignore the full context you ignore the distinction between
>> (1) and (2). In this case it is an honest mistake on your part because
>> the distinction can be difficult to fully appreciate.
>
> It's a trivial distinction. And an irrelevant one because every
>> (1) When we ask does every element of the set of valid declarative
>> sentences have as associated Boolean value? The answer is yes.
>>
>> (2) When we ask does every element of the set of sentences have as
>> associated Boolean value? The answer is no.
>>
>> When you ignore the full context you ignore the distinction between
>> (1) and (2). In this case it is an honest mistake on your part because
>> the distinction can be difficult to fully appreciate.
>
> instance of the halting problem has a correct yes/no answer.
>
> For H to be a halt decider, H(P,I) must be true iff P(I) halts. The
> correct answer does not depend on anything but P and I. It does not
> depend on who or what we "ask". In fact, P(I) ether is or is not a
> finite computation even if we never ask anyone or anything about it.
>
> P(P) halts (according to you). H(P,P) == 0 (according to you). That is
> wrong (according to everyone but you).
>
> As far as I can see, there are no facts in dispute, only waffle.
>
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
P((u32)P);
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
}
The fact is that the above computation never ever halts unless some H
aborts some P thus proving beyond all possible doubt that H[0] does
correctly decide that P[2] (zero based addressing) never halts.
olcott
Jul 19, 2021, 10:55:33 AM7/19/21
to
You said :
>>>>> you've told us that your H gets this case wrong:
You know damn well that I never said that H gets this case wrong.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
P((u32)P);
}
The fact is that the above computation never ever halts unless some H
aborts some P thus proving beyond all possible doubt that H[0] does
correctly decide that P[2] (zero based addressing) never halts.
Personally this seems too harsh to me: Revelation 21:8 KJV
}
The fact is that the above computation never ever halts unless some H
aborts some P thus proving beyond all possible doubt that H[0] does
correctly decide that P[2] (zero based addressing) never halts.
...all liars, shall have their part in the lake which burneth with fire
and brimstone: which is the second death.
> you were talking about the halting problem. You kept quoting Linz's
and brimstone: which is the second death.
> definition of what the correct answer was. I thought you understood
> those lines and took them to be the definition of a halt decider.
>
> After all, ever since the Great Delusion of Dec 2018 you've claimed to
> have two "actual Turing machines", H and H^, "exactly and precisely as
> in Linz". You got people's attention by claiming to have something
> impossible, but if you are to believed now, you just had an H that gets
> the wrong answer (according to Linz) about H^, but you never accepted
> Linz's notion of the the right answer should be.
>
> Well, if anyone believes you now, it's clear that I made a mistake in
> taking you are your word. A mistake is not a lie.
>
> For my part, I don't believe you now. I think you meant what you said
> back in 2018. I think you have always known how the halting problem is
> defined, and when you quoted those lines from Linz it was to confirm
> what a halt decider should do.
>
> In other words, I think this is just the latest part of the two and a
> half year walking back of the deluded claims of Dec 2018.
>
> I may, of course, be wrong about this too. The one thing you can know
> for sure is that I have never lied about any of this.
>
>> When P(P) stops running because one of the function calls in its
>> infinite chain of function calls has been aborted this does not make
>> P(P) a halting computation.
>
> I once asked you to confirm that
>> When P(P) stops running because one of the function calls in its
>> infinite chain of function calls has been aborted this does not make
>> P(P) a halting computation.
>
>
> || (B) Every computation that halts, for whatever reason, is a halting
> || computation.
>
> you said
>
> | OK
>
> Was that a lie? Where you mistaken? Are you playing some strange
> language game in which "P(P) stops running" is not "P(P) halts"? Or are
> you simply saying whatever you need to say in order to keep this
> nonsense going?
olcott
Jul 19, 2021, 11:02:09 AM7/19/21
to
On 7/17/2021 9:12 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 7/16/2021 5:59 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 7/16/2021 3:46 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
> olcott <No...@NoWhere.com> writes:
>
>> On 7/16/2021 5:59 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 7/16/2021 3:46 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 7/16/2021 1:00 PM, Mr Flibble wrote:
>>>>>>> A pathological program that executes a black box decider and returns the
>>>>>>> opposite result can be detected by the black box decider.
>>>>>>> So there are THREE possible results the black box decider can return:
>>>>>>> 1) Program halts
>>>>>>> 2) Program does not halt
>>>>>>> 3) Program is pathological and can be discarded as invalid.
>>>>>>> Halting problem solved.
>>>>>>> Next.
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Rice's theorem says that pathological self-reference is (in at least
>>>>>> some cases) an undecidable property. Unless halting is decidable then
>>>>>> neither is pathological self-reference.
>>>>>>> A pathological program that executes a black box decider and returns the
>>>>>>> opposite result can be detected by the black box decider.
>>>>>>> So there are THREE possible results the black box decider can return:
>>>>>>> 1) Program halts
>>>>>>> 2) Program does not halt
>>>>>>> 3) Program is pathological and can be discarded as invalid.
>>>>>>> Halting problem solved.
>>>>>>> Next.
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Rice's theorem says that pathological self-reference is (in at least
>>>>>> some cases) an undecidable property. Unless halting is decidable then
>>>>>> neither is pathological self-reference.
>>>>> I am cheered to see you've been paying attention.
>>>>>
>>>>>> Halting <is> decidable.
>>>>>
>>>>>> Halting <is> decidable.
>>>>> No, but more specifically, you've told us that your H gets this case
>>>>> wrong:
>>>>
>>>> No you God damned liar I never said that.
>>>
>>> It's true that you never admitted it was wrong, but you told us that
>>>>> wrong:
>>>>
>>>> No you God damned liar I never said that.
>>>
>>> H(P,P) == 0 and that P(P) halts. That's the wrong answer, and you knew
>>> it at the time.
>>
>> I have always known that it is the correct answer, (as shown below) so
>> you lie again.
>
> Well, I can't fathom the mind of someone who can quote those lines from
>>> it at the time.
>>
>> I have always known that it is the correct answer, (as shown below) so
>> you lie again.
>
> Linz, again and again, without knowing what they were saying. Not once
> did you say "this specification for a halt decider is wrong", you just
> quoted those lines and took it from there.
>
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
P((u32)P);
}
The fact is that the above computation never ever halts unless some H
aborts some P thus proving beyond all possible doubt that H[0] does
correctly decide that P[2] (zero based addressing) never halts.
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
}
The fact is that the above computation never ever halts unless some H
aborts some P thus proving beyond all possible doubt that H[0] does
correctly decide that P[2] (zero based addressing) never halts.
if M applied to wM halts, and
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
Unless the simulating halt decider embedded at state Ĥ.qx aborts the
simulation of its input at some point its input never halts thus proving
beyond all possible doubt that the input that was aborted is correctly
decided as never halting.
When a computation only stops running because its simulation was aborted
this counts as a computation that never halts.
> If you say that you have never been talking about the problem for which
> H(P,P) should be true because P(P) halts, but rather about some other
> problem for which H(P,P) == 0 is the correct answer, then so be it. But
> why should anyone care?
>
> When you announced your Great Delusion in Dec 2018, you managed
> (presumably by sheer ignorance since you don't lie) to convince the
> those listening that you had something impossible. Impossible because
> the two "actual Turing machines" H, and H^, that you had "fully encoded"
> were "exactly and precisely as in Linz".
>
> Now, it seems, we are to interpret the Grand Delusion as you simply
> having a TM H that gets the halting of H^ wrong because the right answer
> is not as in Linz, despite your quoting Linz on the subject again and
> again.
>
> A less generous person would consider this the shameless deception of
> narcissistic charlatan, but apparently you knew not what you said. The
> old Usenet adage, that one should never attribute to malice that which
> can be accounted for by ignorance, is working overtime here.
olcott
Jul 20, 2021, 10:22:21 AM7/20/21
to
On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> You said :
>>>>>>> you've told us that your H gets this case wrong:
>> You know damn well that I never said that H gets this case wrong.
>
> You know it gets this case wrong, and you told us exactly how and why:
> olcott <No...@NoWhere.com> writes:
>
>> You said :
>>>>>>> you've told us that your H gets this case wrong:
>> You know damn well that I never said that H gets this case wrong.
>
>
> Me: Every computation that halts, for whatever reason, is a halting
> computation.
>
> You: OK
>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> P((u32)P);
>> }
>>
>> The fact is that the above computation never ever halts unless...
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> P((u32)P);
>> }
>>
>
> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
> to you). That is wrong, and you've known it's wrong for a very long
> time.
>
The above computation that is not under the supervision of H is an
entirely different computation than the one that is under the
supervision of H.
Intuitively it seems that they must be the same yet intuition is simply
incorrect. The fact that their execution trace is different proves that
they are entirely different computations.
H aborts the simulation of its input at the earliest point that its
input demonstrates non-halting behavior.
olcott
Jul 20, 2021, 11:18:28 AM7/20/21
to
On 7/20/2021 9:40 AM, André G. Isaak wrote:
> supposed to decide whether its input halts. That means H(P, P) is
> supposed to determine whether P(P) halts. It isn't supposed to determine
> whether some separate computation, "P(P) being supervised by H" halts.
>
> André
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
[00000c3f](01) c3 ret
Size in bytes:(0027) [00000c3f]
_main()
[00000c45](01) 55 push ebp
[00000c46](02) 8bec mov ebp,esp
[00000c48](05) 68250c0000 push 00000c25 // push P
[00000c4d](05) e8d3ffffff call 00000c25 // call P
[00000c52](03) 83c404 add esp,+04
[00000c55](02) 33c0 xor eax,eax
[00000c57](01) 5d pop ebp
[00000c58](01) c3 ret
Size in bytes:(0020) [00000c58]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c45][001016d6][00000000] 55 push ebp
[00000c46][001016d6][00000000] 8bec mov ebp,esp
[00000c48][001016d2][00000c25] 68250c0000 push 00000c25 // push P
[00000c4d][001016ce][00000c52] e8d3ffffff call 00000c25 // call P0
[00000c25][001016ca][001016d6] 55 push ebp // P0 begins
[00000c26][001016ca][001016d6] 8bec mov ebp,esp
[00000c28][001016ca][001016d6] 8b4508 mov eax,[ebp+08]
[00000c2b][001016c6][00000c25] 50 push eax // push P
[00000c2c][001016c6][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][001016c2][00000c25] 51 push ecx // push P
[00000c30][001016be][00000c35] e820fdffff call 00000955 // call H0
Begin Local Halt Decider Simulation at Machine Address:c25
[00000c25][00211776][0021177a] 55 push ebp // P1 begins
[00000c26][00211776][0021177a] 8bec mov ebp,esp
[00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
[00000c2b][00211772][00000c25] 50 push eax // push P
[00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0021176e][00000c25] 51 push ecx // push P
[00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1
[00000c25][0025c19e][0025c1a2] 55 push ebp // P2 begins
[00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
[00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
[00000c2b][0025c19a][00000c25] 50 push eax // push P
[00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0025c196][00000c25] 51 push ecx // push P
[00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
In the above computation (zero based addressing) H[0] aborts P[2].
[00000c35][001016ca][001016d6] 83c408 add esp,+08
[00000c38][001016ca][001016d6] 85c0 test eax,eax
[00000c3a][001016ca][001016d6] 7402 jz 00000c3e
[00000c3e][001016ce][00000c52] 5d pop ebp
[00000c3f][001016d2][00000c25] c3 ret
[00000c52][001016d6][00000000] 83c404 add esp,+04
[00000c55][001016d6][00000000] 33c0 xor eax,eax
[00000c57][001016da][00100000] 5d pop ebp
[00000c58][001016de][00000084] c3 ret
Number_of_User_Instructions(34)
Number of Instructions Executed(23729)
> On 2021-07-20 08:22, olcott wrote:
>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> You said :
>>>>>>>>> you've told us that your H gets this case wrong:
>>>> You know damn well that I never said that H gets this case wrong.
>>>
>>> You know it gets this case wrong, and you told us exactly how and why:
>>>
>>> Me: Every computation that halts, for whatever reason, is a halting
>>> computation.
>>>
>>> You: OK
>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> P((u32)P);
>>>> }
>>>>
>>>> The fact is that the above computation never ever halts unless...
>>>
>>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
>>> to you). That is wrong, and you've known it's wrong for a very long
>>> time.
>>>
>>
>> The above computation that is not under the supervision of H is an
>> entirely different computation than the one that is under the
>> supervision of H.
>
> In this case your H is answering the wrong question. A halt decider is
>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> You said :
>>>>>>>>> you've told us that your H gets this case wrong:
>>>> You know damn well that I never said that H gets this case wrong.
>>>
>>> You know it gets this case wrong, and you told us exactly how and why:
>>>
>>> Me: Every computation that halts, for whatever reason, is a halting
>>> computation.
>>>
>>> You: OK
>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> P((u32)P);
>>>> }
>>>>
>>>> The fact is that the above computation never ever halts unless...
>>>
>>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
>>> to you). That is wrong, and you've known it's wrong for a very long
>>> time.
>>>
>>
>> The above computation that is not under the supervision of H is an
>> entirely different computation than the one that is under the
>> supervision of H.
>
> supposed to decide whether its input halts. That means H(P, P) is
> supposed to determine whether P(P) halts. It isn't supposed to determine
> whether some separate computation, "P(P) being supervised by H" halts.
>
> André
>
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
P((u32)P);
}
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
P((u32)P);
}
The fact is that the above computation never ever halts unless some H
aborts some P thus proving beyond all possible doubt that H[0] does
correctly decide that P[2] (zero based addressing) never halts.
_P()
aborts some P thus proving beyond all possible doubt that H[0] does
correctly decide that P[2] (zero based addressing) never halts.
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
[00000c3f](01) c3 ret
Size in bytes:(0027) [00000c3f]
_main()
[00000c45](01) 55 push ebp
[00000c46](02) 8bec mov ebp,esp
[00000c48](05) 68250c0000 push 00000c25 // push P
[00000c4d](05) e8d3ffffff call 00000c25 // call P
[00000c52](03) 83c404 add esp,+04
[00000c55](02) 33c0 xor eax,eax
[00000c57](01) 5d pop ebp
[00000c58](01) c3 ret
Size in bytes:(0020) [00000c58]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c45][001016d6][00000000] 55 push ebp
[00000c46][001016d6][00000000] 8bec mov ebp,esp
[00000c48][001016d2][00000c25] 68250c0000 push 00000c25 // push P
[00000c4d][001016ce][00000c52] e8d3ffffff call 00000c25 // call P0
[00000c25][001016ca][001016d6] 55 push ebp // P0 begins
[00000c26][001016ca][001016d6] 8bec mov ebp,esp
[00000c28][001016ca][001016d6] 8b4508 mov eax,[ebp+08]
[00000c2b][001016c6][00000c25] 50 push eax // push P
[00000c2c][001016c6][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][001016c2][00000c25] 51 push ecx // push P
[00000c30][001016be][00000c35] e820fdffff call 00000955 // call H0
Begin Local Halt Decider Simulation at Machine Address:c25
[00000c25][00211776][0021177a] 55 push ebp // P1 begins
[00000c26][00211776][0021177a] 8bec mov ebp,esp
[00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
[00000c2b][00211772][00000c25] 50 push eax // push P
[00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0021176e][00000c25] 51 push ecx // push P
[00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1
[00000c25][0025c19e][0025c1a2] 55 push ebp // P2 begins
[00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
[00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
[00000c2b][0025c19a][00000c25] 50 push eax // push P
[00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0025c196][00000c25] 51 push ecx // push P
[00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
In the above computation (zero based addressing) H[0] aborts P[2].
[00000c35][001016ca][001016d6] 83c408 add esp,+08
[00000c38][001016ca][001016d6] 85c0 test eax,eax
[00000c3a][001016ca][001016d6] 7402 jz 00000c3e
[00000c3e][001016ce][00000c52] 5d pop ebp
[00000c3f][001016d2][00000c25] c3 ret
[00000c52][001016d6][00000000] 83c404 add esp,+04
[00000c55][001016d6][00000000] 33c0 xor eax,eax
[00000c57][001016da][00100000] 5d pop ebp
[00000c58][001016de][00000084] c3 ret
Number_of_User_Instructions(34)
Number of Instructions Executed(23729)
olcott
Jul 21, 2021, 10:48:34 AM7/21/21
to
On 7/20/2021 7:28 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> You said :
>>>>>>>>> you've told us that your H gets this case wrong:
>>>> You know damn well that I never said that H gets this case wrong.
>>> You know it gets this case wrong, and you told us exactly how and why:
>>> Me: Every computation that halts, for whatever reason, is a halting
>>> computation.
>>> You: OK
>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> P((u32)P);
>>>> }
>>>>
>>>> The fact is that the above computation never ever halts unless...
>>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
>>> to you). That is wrong, and you've known it's wrong for a very long
>>> time.
>>
>> The above computation that is not under the supervision of H is an
>> entirely different computation than the one that is under the
>> supervision of H.
>
> Of course. But that does not tell me which of the facts are you now
> olcott <No...@NoWhere.com> writes:
>
>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> You said :
>>>>>>>>> you've told us that your H gets this case wrong:
>>>> You know damn well that I never said that H gets this case wrong.
>>> You know it gets this case wrong, and you told us exactly how and why:
>>> Me: Every computation that halts, for whatever reason, is a halting
>>> computation.
>>> You: OK
>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> P((u32)P);
>>>> }
>>>>
>>>> The fact is that the above computation never ever halts unless...
>>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
>>> to you). That is wrong, and you've known it's wrong for a very long
>>> time.
>>
>> The above computation that is not under the supervision of H is an
>> entirely different computation than the one that is under the
>> supervision of H.
>
> disputing:
>
> (a) P(P) halts.
> (b) H(P, P) == 0.
> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>
> I hope it's (c) so that we can all ignore what say from now on.
>
Even though the outermost P does reach its final state it only reaches
it final state because H correctly decided that its input never halts.
Because of this the argument that the outer P reaches its final state
contradicts that H decided its input correctly DOES NOT HOLD.
There is never a case where H(P,P)==0 is incorrect.
This only applies to people knowing the x86 language:
It can be easily verified that that input to H(P,P) never reaches its
final state whether or not H aborts its simulation of this input.
This conclusively proves that its input never halts thus conclusively
proving that H does correctly decide that this input never halts.
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
olcott
Jul 21, 2021, 9:57:25 PM7/21/21
to
On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> I did not even glance at any of the words
> olcott <No...@NoWhere.com> writes:
>
>
> It's simple. I asked which of these three facts you reject:
>
> (a) P(P) halts.
> (b) H(P, P) == 0.
> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>
> and it seems the answer is (c). This despite your disingenuous
> (a) P(P) halts.
> (b) H(P, P) == 0.
> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>
> (i.e. dishonest) refusal to make your rejection of what halt decider is
> clear. (Details in the parent article for those who do read.)
>
The P of int main() { P(P); } halts
and H(P,P)==0 is the correct halts status.
It is not a contradiction it is a paradox.
We know that it is not a contradiction because we can verify that the
input to H(P,P) cannot possibly ever reach its halt state. This
conclusively proves that the input to H(P,P) never halts.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
_P()
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
[00000c3f](01) c3 ret
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
Size in bytes:(0027) [00000c3f]
olcott
Jul 21, 2021, 11:25:26 PM7/21/21
to
On 7/21/2021 9:57 PM, André G. Isaak wrote:
>
> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
> demonstrates that whatever logic your H is using is *wrong*.
>
If you bothered to pay complete attention you would understand that the
input to H(P,P) cannot possibly reach its final state thus never halts.
> A halt decider H(X,Y) is *defined* as something which answers the
> question 'Does the TM described by X halt on input Y'.
>
> If X(Y) halts, then the *only* correct answer for H(X, Y) to give is
> 'yes, it halts'.
>
> This is a simple matter of definition.
>
If you bothered to pay complete attention you would understand that the
input to H(P,P) cannot possibly reach its final state thus never halts.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]
> It is entirely pointless to argue about your flawed algorithm, your
> silly 'axioms', or your pointless traces given the above. Above you've
> given a crystal clear statement to the effect that your H(P, P) gives
> the *wrong* answer.
>
> André
> On 2021-07-21 19:57, olcott wrote:
>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> I did not even glance at any of the words
>>>
>>> It's simple. I asked which of these three facts you reject:
>>>
>>> (a) P(P) halts.
>>> (b) H(P, P) == 0.
>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>
>>> and it seems the answer is (c). This despite your disingenuous
>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>> clear. (Details in the parent article for those who do read.)
>>>
>>
>> The P of int main() { P(P); } halts
>> and H(P,P)==0 is the correct halts status.
>> It is not a contradiction it is a paradox.
>
> This statement is entirely laughable.
>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> I did not even glance at any of the words
>>>
>>> It's simple. I asked which of these three facts you reject:
>>>
>>> (a) P(P) halts.
>>> (b) H(P, P) == 0.
>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>
>>> and it seems the answer is (c). This despite your disingenuous
>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>> clear. (Details in the parent article for those who do read.)
>>>
>>
>> The P of int main() { P(P); } halts
>> and H(P,P)==0 is the correct halts status.
>> It is not a contradiction it is a paradox.
>
>
> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
> demonstrates that whatever logic your H is using is *wrong*.
>
If you bothered to pay complete attention you would understand that the
input to H(P,P) cannot possibly reach its final state thus never halts.
> A halt decider H(X,Y) is *defined* as something which answers the
> question 'Does the TM described by X halt on input Y'.
>
> If X(Y) halts, then the *only* correct answer for H(X, Y) to give is
> 'yes, it halts'.
>
> This is a simple matter of definition.
>
If you bothered to pay complete attention you would understand that the
input to H(P,P) cannot possibly reach its final state thus never halts.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
_P()
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]
> It is entirely pointless to argue about your flawed algorithm, your
> silly 'axioms', or your pointless traces given the above. Above you've
> given a crystal clear statement to the effect that your H(P, P) gives
> the *wrong* answer.
>
> André
olcott
Jul 22, 2021, 12:41:04 AM7/22/21
to
On 7/21/2021 10:50 PM, André G. Isaak wrote:
>
> A halt decider is *defined* as a TM which takes the description of a
> Turing Machine and an input string and determines whether the
> computation described by those two inputs halts.
>
> In other words, H(P, P) is supposed to answer the question 'Does the
> computation P(P) halt?'
>
> It is *not* concerned with the unrelated question 'Does a simulation of
> P(P) inside of H halt?' or 'Does a simulation of some modified version
> of P(P) halt?' or any other question which you might imagine as part of
> your futile attempt to claim that your H is actually correct.
>
> P(P) halts when run *independently*. That is the *only* thing that
> matters by the very definition of the problem.
>
> Everything else you claim is entirely irrelevant.
>
> André
>
The only reason that P of int main() { P(P); } halts on its input is
that H(P,P) decides its input correctly thus H(P,P)==0 IS NOT WRONG !!!
> On 2021-07-21 21:25, olcott wrote:
>> On 7/21/2021 9:57 PM, André G. Isaak wrote:
>>> On 2021-07-21 19:57, olcott wrote:
>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> I did not even glance at any of the words
>>>>>
>>>>> It's simple. I asked which of these three facts you reject:
>>>>>
>>>>> (a) P(P) halts.
>>>>> (b) H(P, P) == 0.
>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>
>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>> (i.e. dishonest) refusal to make your rejection of what halt
>>>>> decider is
>>>>> clear. (Details in the parent article for those who do read.)
>>>>>
>>>>
>>>> The P of int main() { P(P); } halts
>>>> and H(P,P)==0 is the correct halts status.
>>>> It is not a contradiction it is a paradox.
>>>
>>> This statement is entirely laughable.
>>>
>>> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
>>> demonstrates that whatever logic your H is using is *wrong*.
>>>
>>
>> If you bothered to pay complete attention you would understand that
>> the input to H(P,P) cannot possibly reach its final state thus never
>> halts.
>
> Even if this statement were true, it is entirely irrelevant.
>> On 7/21/2021 9:57 PM, André G. Isaak wrote:
>>> On 2021-07-21 19:57, olcott wrote:
>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> I did not even glance at any of the words
>>>>>
>>>>> It's simple. I asked which of these three facts you reject:
>>>>>
>>>>> (a) P(P) halts.
>>>>> (b) H(P, P) == 0.
>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>
>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>> (i.e. dishonest) refusal to make your rejection of what halt
>>>>> decider is
>>>>> clear. (Details in the parent article for those who do read.)
>>>>>
>>>>
>>>> The P of int main() { P(P); } halts
>>>> and H(P,P)==0 is the correct halts status.
>>>> It is not a contradiction it is a paradox.
>>>
>>> This statement is entirely laughable.
>>>
>>> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
>>> demonstrates that whatever logic your H is using is *wrong*.
>>>
>>
>> If you bothered to pay complete attention you would understand that
>> the input to H(P,P) cannot possibly reach its final state thus never
>> halts.
>
>
> A halt decider is *defined* as a TM which takes the description of a
> Turing Machine and an input string and determines whether the
> computation described by those two inputs halts.
>
> In other words, H(P, P) is supposed to answer the question 'Does the
> computation P(P) halt?'
>
> It is *not* concerned with the unrelated question 'Does a simulation of
> P(P) inside of H halt?' or 'Does a simulation of some modified version
> of P(P) halt?' or any other question which you might imagine as part of
> your futile attempt to claim that your H is actually correct.
>
> P(P) halts when run *independently*. That is the *only* thing that
> matters by the very definition of the problem.
>
> Everything else you claim is entirely irrelevant.
>
> André
>
The only reason that P of int main() { P(P); } halts on its input is
that H(P,P) decides its input correctly thus H(P,P)==0 IS NOT WRONG !!!
olcott
Jul 22, 2021, 9:05:00 AM7/22/21
to
On 7/22/2021 1:55 AM, André G. Isaak wrote:
> Um. No.
>
> The reason that P(P) halts is because it reaches a final state in a
> finite amount of time by mechanically following its program.
>
(a) The reason that it is construed as halting is that it reaches its
final state.
(b) The reason that it reaches its final state is that H(P,P) returns 0;
(c) The reason that H(P,P) returns zero is that the pure simulation of
its input can't possibly reach its final state.
(d) When the pure simulation of an input can't possibly ever reach its
final state then this input never halts.
> To claim the P(P) halts because H(P, P) claims it doesn't halt is absurd.
>
The only reason that P of int main(){ P(P); } halts is because H(P,P)
> halt is even more absurd.
>
> André
>
> The reason that P(P) halts is because it reaches a final state in a
> finite amount of time by mechanically following its program.
>
(a) The reason that it is construed as halting is that it reaches its
final state.
(b) The reason that it reaches its final state is that H(P,P) returns 0;
(c) The reason that H(P,P) returns zero is that the pure simulation of
its input can't possibly reach its final state.
(d) When the pure simulation of an input can't possibly ever reach its
final state then this input never halts.
> To claim the P(P) halts because H(P, P) claims it doesn't halt is absurd.
>
The only reason that P of int main(){ P(P); } halts is because H(P,P)
correctly decided that its input never halts.
> To claim that P(P) halts because H(P, P) *correctly* claims it doesn't
> halt is even more absurd.
>
> André
olcott
Jul 22, 2021, 10:53:03 AM7/22/21
to
On 7/22/2021 9:23 AM, André G. Isaak wrote:
> It isn't just 'construed' as halting. It *is* halting.
> P(P) halts, a pure simulation of P(P) would also halt.
>
That a pure simulation of the input to H(P,P) never reaches a final
state is an easily verified fact.
>>> To claim the P(P) halts because H(P, P) claims it doesn't halt is
>>> absurd.
>>>
>>
>> The only reason that P of int main(){ P(P); } halts is because H(P,P)
>> correctly decided that its input never halts.
>
> So P(P) halts because H(P, P) "correctly" decides that P(P) doesn't halt.
>
Yes, a paradox rather than a contradiction.
"This sentence is not true".
is indeed not true yet that does not make it true.
> I look forward to seeing how you plan on justifying the use of the word
> 'correctly' in the above sentence in your final paper. I'm sure it will
> go over well with whomever you submit this paper to.
>
> André
>
That a correct pure simulation of the input to H(P,P) never reaches a
final state is an easily verified fact. This conclusively proves that
the input never halts.
I am not going to submit the paper to anyone until after it is approved
here. Now that I have at least one very excellent reviewer (you) we will
reach a point of mutual agreement.
>
>> (b) The reason that it reaches its final state is that H(P,P) returns 0;
>>
>> (c) The reason that H(P,P) returns zero is that the pure simulation of
>> its input can't possibly reach its final state.
>>
>> (d) When the pure simulation of an input can't possibly ever reach its
>> final state then this input never halts.
>
> A pure simulation of P(P) would behave exactly as P(P) behaves. Since
>> (b) The reason that it reaches its final state is that H(P,P) returns 0;
>>
>> (c) The reason that H(P,P) returns zero is that the pure simulation of
>> its input can't possibly reach its final state.
>>
>> (d) When the pure simulation of an input can't possibly ever reach its
>> final state then this input never halts.
>
> P(P) halts, a pure simulation of P(P) would also halt.
>
That a pure simulation of the input to H(P,P) never reaches a final
state is an easily verified fact.
>>> To claim the P(P) halts because H(P, P) claims it doesn't halt is
>>> absurd.
>>>
>>
>> The only reason that P of int main(){ P(P); } halts is because H(P,P)
>> correctly decided that its input never halts.
>
>
Yes, a paradox rather than a contradiction.
"This sentence is not true".
is indeed not true yet that does not make it true.
> I look forward to seeing how you plan on justifying the use of the word
> 'correctly' in the above sentence in your final paper. I'm sure it will
> go over well with whomever you submit this paper to.
>
> André
>
That a correct pure simulation of the input to H(P,P) never reaches a
final state is an easily verified fact. This conclusively proves that
the input never halts.
I am not going to submit the paper to anyone until after it is approved
here. Now that I have at least one very excellent reviewer (you) we will
reach a point of mutual agreement.
olcott
Jul 22, 2021, 5:47:12 PM7/22/21
to
On 7/22/2021 3:53 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> I did not even glance at any of the words
>>> It's simple. I asked which of these three facts you reject:
>>> (a) P(P) halts.
>>> (b) H(P, P) == 0.
>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>> and it seems the answer is (c). This despite your disingenuous
>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>> clear. (Details in the parent article for those who do read.)
>>
>> The P of int main() { P(P); } halts
>
> Yes, you've confirmed (a) many times.
> olcott <No...@NoWhere.com> writes:
>
>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> I did not even glance at any of the words
>>> It's simple. I asked which of these three facts you reject:
>>> (a) P(P) halts.
>>> (b) H(P, P) == 0.
>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>> and it seems the answer is (c). This despite your disingenuous
>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>> clear. (Details in the parent article for those who do read.)
>>
>> The P of int main() { P(P); } halts
>
>
>> and H(P,P)==0
>
> Yes, (b) is also not in dispute.
>
>> is the correct halts status.
>> It is not a contradiction it is a paradox.
>
> It's neither. It's just that H is not a halt decider. The fact you
>> is the correct halts status.
>> It is not a contradiction it is a paradox.
>
> reject is (c) -- the definition of a halt decider.
>
> We've known that for ages. The only issue has been your reluctance to
> admit it. You know the game is up unless you can pretend to be still
> talking about the halting problem as defined in Linz, Sipser, Davis,
> Kleene and everyone else except you.
>
> Although, as I've pointed out many times, the game need not be up. Your
> stated specification for the POOH problem is also undecidable. We could
> argue about that for the next 17 years instead.
>
The fact that int main(){ P(P); } only halts because the input to H(P,P)
aborts the simulation of its input has been mutually agreed that H did
decide its input correctly.
On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.
olcott
Jul 22, 2021, 7:22:31 PM7/22/21
to
> Every computation that halts, for whatever reason, is a halting
> computation.
Ah but now with André's suggestion of using the proper definition of
> computation.
halting:
Halting computation: is any computation that eventually reaches its own
final state.
We can know that the input to H(P,P) never halts.
> Every one but you agrees that a halt decider should return
> true for a computation that halts, not matter what the "reason" for that
> halting.
>
> You have reached a dead-end. You have no more options to find
> obfuscating language. H decides something, but it's not what the world
> call halting. What a waste of time.
olcott
Jul 23, 2021, 9:36:14 AM7/23/21
to
On 7/22/2021 7:05 PM, André G. Isaak wrote:
> Ben is already using the exact same definition as I am. Everyone here
> apart from you knows what 'halting' means.
>
I am really happy that you brought that definition up, it puts things in
much sharper focus.
>> Halting computation: is any computation that eventually reaches its
>> own final state.
>>
>> We can know that the input to H(P,P) never halts.
>
> The input to P(P) isn't a computation. Its a *description* of a
> computation.
>
We know that the UTM simulation of the description of a TM on its input
is equivalent to the direct execution of this machine on its input.
Conventional Halt Deciding Axiom:
When the pure simulation of the machine description ⟨P⟩ of a machine P
on its input I never halts we know that P(I) never halts. // based on
UTM(⟨P⟩,I) ≡ P(I)
> H is supposed to tell us whether that computation halts when run
> *outside* of H.
Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to
M is its own description ⟨M⟩. Once D has determined this information,
it does the opposite. (Sipser:1997:165)
When a halt decider only acts as a pure simulator of its input until
after its halt status decision is made there is no feedback loop of back
channel communication between the halt decider and its input that can
prevent a correct halt status decision.
It can be seen that while H(P,P) acts as a pure x86 emulator of its
input that its input cannot possibly reach its final state.
The fact that no P ever halts unless some H aborts some P conclusively
proves that H[0] did abort P[1] and report never halting correctly.
> It does, as you have acknowledged. Therefore, the only
> correct answer for H(P, P) to give is 'true'.
>
> André
> apart from you knows what 'halting' means.
>
I am really happy that you brought that definition up, it puts things in
much sharper focus.
>> Halting computation: is any computation that eventually reaches its
>> own final state.
>>
>> We can know that the input to H(P,P) never halts.
>
> computation.
>
We know that the UTM simulation of the description of a TM on its input
is equivalent to the direct execution of this machine on its input.
Conventional Halt Deciding Axiom:
When the pure simulation of the machine description ⟨P⟩ of a machine P
on its input I never halts we know that P(I) never halts. // based on
UTM(⟨P⟩,I) ≡ P(I)
> H is supposed to tell us whether that computation halts when run
> *outside* of H.
Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to
M is its own description ⟨M⟩. Once D has determined this information,
it does the opposite. (Sipser:1997:165)
When a halt decider only acts as a pure simulator of its input until
after its halt status decision is made there is no feedback loop of back
channel communication between the halt decider and its input that can
prevent a correct halt status decision.
It can be seen that while H(P,P) acts as a pure x86 emulator of its
input that its input cannot possibly reach its final state.
The fact that no P ever halts unless some H aborts some P conclusively
proves that H[0] did abort P[1] and report never halting correctly.
> It does, as you have acknowledged. Therefore, the only
> correct answer for H(P, P) to give is 'true'.
>
> André
olcott
Jul 23, 2021, 10:04:41 AM7/23/21
to
>
The key fact that André changed my mind on is that int main(){ P(P); }
halts. Prior to this I thought that it was reasonably possible to
construe it as not halting even though it stops running. By referring to
the key element of the conventional definition of halting André puts
things in much sharper focus.
> Do you still agree that P(P) halts?
>
> Do you still agree that H(P,P) == 0?
>
> Do you still reject that for H to be a halt decider H(P,I) == 0 only
> when P(I) does not halt?
>
P[0] halts when H[0](P[1],P[1]) is correctly decided as never halting.
Once we make the references totally specific it is no longer even
paradoxical.
> A clear answer would be appreciated. If you are not changing your mind,
> you're at a dead-end.
0 new messages