Alex C <immibis@gmail.com> writes:

> You guys might all be missing something simple: The "correct
> simulation" does halt. So when the decider says it doesn't halt, it's
> wrong.

Who are "you guys"? I see this point being made daily. PO misses that,
but he's not plural!

And there is an even simpler point than this. PO tells us that
H(P,P)==false "even though P(P) halts". He now denies that this is in
anyway significant, but it's the "top-level" reason why he is wrong.

--
Ben.

On 4/19/22 11:59 PM, olcott wrote:
> On 4/19/2022 4:32 PM, Malcolm McLean wrote:
>> On Tuesday, 19 April 2022 at 18:53:15 UTC+1, Jeff Barnett wrote:
>>> On 4/19/2022 9:39 AM, Malcolm McLean wrote:
>>>> On Tuesday, 19 April 2022 at 16:15:38 UTC+1, Ben wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>> <SNIP>
>>>> Slowly, each step built on the next. Don't claim to be a brain
>>>> surgeon when
>>>> a) you have no formal medical qualifications and b) you don't know
>>>> what a
>>>> bed pan looks like.
>>> Since I believe that PO knows what a bedpan looks like, might I conclude
>>> that he's on his way to being a surgeon? If so, he could be more
>>> productive if he added some additional medical newsgroup destinations to
>>> the silly messages he writes. That way he can also seek some information
>>> on his health. (Though I still believe that his cancer claims are just
>>> tools of the troll trade, I could be persuaded otherwise if it were
>>> brain cancer.) In any event, it's food for thought.
>>>
>> I think you haven't been following the threads. PO compared himself to a
>> brain surgeon and specifying a simple Turing machine to changing a
>> bedpan. We don't normally ask surgeons to change bedpans, but we
>> assume that they would be capable of doing so, if it were an emergency
>> and a nurse was not available.
>> The difference is that PO is not a recognised computer scientist.
>> Also, he's
>> shown himself to have some basic misconceptions about Turing machines,
>> like the idea that the normal way to move the head 1000 positions is to
>> have 1000 states. One way to clear that kind of misconception up is to
>> write a few Turing machines. It's not sufficient qualification to be
>> an expert,
>> maybe it's not strictly a necessary qualification, but it's how most
>> people
>> start.
>
> EVERYTHING ELSE IS AN OFF TOPIC DISHONEST DODGE:
> The fact that the correctly simulated input to H(P,P) is provably
> non-halting is an entirely sufficient basis for H to report that it's
> input is non-halting.
>

Except it isn't a fact, so you are just lying.

The CORRECT simulation of the input to H(P,P) will halt if H(P,P)
returns false, so you argument has a false premise and thus is unsound.

You are looking not at the CORRECT simulation of the input, (which will
never be aborted and either halts or runs forever) but the partial (and
thus incorrect) simulation done by H.

If H doesn't abort its simulation, then yes, it can prove that its input
is non-halting, but then it can never report the answer, and thus is
wrong. It is impossible for one machine to both run forever and also
halt to give an answer to the same input.

FAIL.

On 4/20/22 12:00 AM, olcott wrote:
> On 4/19/2022 10:39 AM, Malcolm McLean wrote:
>> On Tuesday, 19 April 2022 at 16:15:38 UTC+1, Ben wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 4/18/2022 4:53 PM, Ben wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 4/17/2022 7:09 PM, Ben wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/17/2022 10:11 AM, Ben wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>>>>>
>>>>>>>>>> That is false.
>>>>>>>>>> H(P,P)==false is correct if an only if its input is non-halting.
>>>>>>>>>
>>>>>>>>> So do you admit that the problem of deciding what the call does is
>>>>>>>>> indeed undecidable? That would be a massive step forwards.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I admit that when you are looking for a white dog in your living
>>>>>>>> room
>>>>>>>> {that the simulated input to H(P,P) halts} it is incorrect to
>>>>>>>> answer
>>>>>>>> this on the basis of cats in your kitchen {the execution of P(P)
>>>>>>>> halts}.
>>>>>>>
>>>>>>> So you have nothing to say about the problem of deciding whether
>>>>>>> P(P)
>>>>>>> halts?
>>>>>>
>>>>>> As long as the input to H(P,P) is non-halting then H(P,P)==false is
>>>>>> necessarily correct.
>>>>>
>>>>> The halting problem does not go away because you declare that P(P)
>>>>> is a
>>>>> "non-input".
>>>>
>>>> In other words you are claiming that a decider computes the mapping
>>>> from non-inputs ?
>>> You really must stop these attempts to paraphrase. I don't think anyone
>>> but you is confused about a property of the "input" is used to define
>>> the correct answer. In fact, I think you know it. I think that's why
>>> you could not define a "prime" decider TM -- you knew you'd have to
>>> specify the correct result in terms of the numerical value /represented/
>>> by the input. And numerical values are non-inputs.
>>>
>>> Is that why you ducked out of specifying that TM, or could you really
>>> not do it?
>>>
>> He needs to write an even-odd decider first. Then try a "divisible by
>> three"
>> decider. Then write a decider which takes numerator and denominator as
>> input (hard). Then a prime decider. After that is achieved, it's time
>> to consider
>> the basic principles on which a UTM could be built. Finally, after we
>> have a
>> UTM, we can consider whether the UTM can be modified with infinite cycle
>> detection logic to create a halt decider.
>> Slowly, each step built on the next. Don't claim to be a brain surgeon
>> when
>> a) you have no formal medical qualifications and b) you don't know what a
>> bed pan looks like.
>>
>
> The fact that the correctly simulated input to H(P,P) is provably
> non-halting is an entirely sufficient basis for H to report that it's
> input is non-halting.
>

No, it isn't. Your 'proof' was unsound, as is your mind.

The CORRECT simulation of the input to H(P,P) will halt if H(P,P)
returns false. This is proven, and you have even published this fact.

You are using the wrong definition of a correct simulation, thinking
that a partial simulation can be correct.

FAIL.

On 4/20/22 12:20 AM, olcott wrote:
> On 4/19/2022 10:05 AM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/18/2022 4:53 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/17/2022 7:08 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/17/2022 10:37 AM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/17/2022 10:09 AM, Ben wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/16/2022 7:45 PM, Ben wrote:
>>>>>>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>>>>>>
>>>>>>>>>>> That requires a halt decider to compute the mapping from
>>>>>>>>>>> non-inputs on
>>>>>>>>>>> the basis of the behavior specified by these non-inputs.
>>>>>>>>>> No.
>>>>>>>>>> Would you like me to explain again?  I won't bother unless you
>>>>>>>>>> ask
>>>>>>>>>> nicely because you've ignored it every time I've done so before.
>>>>>>>>>
>>>>>>>>> P(P) executed independently is not an input to H(P,P) that you
>>>>>>>>> would
>>>>>>>>> say otherwise makes you a bald faced liar.
>>>>>>>> So you don't want me to explain?  OK.  Stay in the dark.  That
>>>>>>>> works for
>>>>>>>> me because nothing makes it more certain that you won't be taken
>>>>>>>> seriously than pretending that the halting problem is not about the
>>>>>>>> computations represented by inputs.
>>>>>>>>
>>>>>>>> Your problem is that you /have/ to find a way to neutralise what
>>>>>>>> you
>>>>>>>> said for years about H(P,P)==false and P(P) halting.  Unless you
>>>>>>>> can
>>>>>>>
>>>>>>> The fact that the correctly simulated input to H(P,P) is non-halting
>>>>>>> is a 100% sufficient reason for H to report that its input does not
>>>>>>> halt.  That you disagree makes you a bald faced liar.
>>>>>>
>>>>>> What makes you think I disagree with that?  You won't say what you
>>>>>> mean,
>>>>>> or more exactly, you mean to be vague.
>>>>>
>>>>> So then you must agree that when H correctly simulates the input to
>>>>> H(P,P) that it would never reach its own final state.
>>>>
>>>> I think you are just cutting and pasting without any thought now.  You
>>>> may not be the sharpest knife in the drawer, but if you'd read what I
>>>> wrote I don't believe even you could not possibly think it logical to
>>>> write that sentence.
>>>
>>> You never do anything besides dodge the point at hand so I continue to
>>> present this point until everyone else realizes that you always only
>>> dodge it and are thereby dishonest.
>>
>> That's a truly silly objective, but I suppose it makes sense to you.  In
>> your position, if I had anything important to say I'd publish in a
>> quality journal rather than obsess about what "everyone else realises"
>> about some random bloke on Usenet!
>>
>> I won't parse, yet again, what it is that's wrong with your recent
>> mantra (I've done so yet again in another reply just a few minutes ago)
>> because you are wrong on far more basic grounds: H(P,P)==false is
>> incorrect because P(P) halts.
>>
>> Nothing you can say can get round this problem.  It's the definition of
>> the problem you took on, and pretending that the correct result is not
>> based on what P(P) (because it's a "non-input") but on some deliberately
>> vague attribute of "the input to H(P,P)" does not make the original
>> problem go away.  H does not fit the specification you originally took
>> on.
>>
>>> Since there are a total of two points that prove that I am correct I
>>> am not going to change the subject away from these two points until
>>> they are fully addressed.
>>
>> Ah, but then you don't know what a proof is, do you?  Do you still think
>> that if A,B,C ⊦ X then A,B,C,~A ⊬ X?
>>
>
> If {an X is a Y} and Z says that {an X is a Y} then Z is necessarily
> correct.
>
> When a sequence of configurations never halts then this sequence is
> non-halting making H(P,P)==0 necessarily correct.
>
>

Nope, in computing "Non-Halting" means will NEVER HALT, even if run for
an unbound number of step.

Your "Sequence of Configurations" seems to include an allowance to stop
processing the input, thus either you are using differing definition, or
you havn't shown your sequence of configurations never halts.

Part of the issue is that the sequence of configurations you look at is
based on a H that will never abort, when the actual H is different as it
DOES abort, so you proved "non-halting" for a different input then the
one you are answering about, since P includes its copy of H, so changing
H changes P, despite that you want to incorrectly exclude it from P,
which just shows you don't understand what a "Program" is, a basic
Computer Science concept.

FAIL.

On 4/20/2022 6:34 AM, Alex C wrote:
> You guys might all be missing something simple: The "correct simulation" does halt. So when the decider says it doesn't halt, it's wrong.

That is the strawman error.

When H(P,P) correctly simulates its input using an x86 emulator does the
simulated P reach its last instruction?

The technical computer science term "halt" means that a program will
reach its last instruction technically called its final state. For P
this would be its machine address [000009f0].

The function named H continues to simulate its input using an x86
emulator until this input either halts on its own or H detects that it
would never halt. If its input halts H returns 1. If H detects that its
input would never halt H returns 0.

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

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

_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]

The simulated input to H(P,P) cannot possibly reach its own final state
of [000009f0] it keeps repeating [000009d6] to [000009e1] until aborted.

Begin Local Halt Decider Simulation
....[000009d6][00211368][0021136c] 55 push ebp // enter P
....[000009d7][00211368][0021136c] 8bec mov ebp,esp
....[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
....[000009dc][00211364][000009d6] 50 push eax // Push P
....[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
....[000009e0][00211360][000009d6] 51 push ecx // Push P
....[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
....[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
....[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
....[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
....[000009dc][0025bd8c][000009d6] 50 push eax // Push P
....[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
....[000009e0][0025bd88][000009d6] 51 push ecx // Push P
....[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Because the correctly simulated input to H(P,P) cannot possibly reach
its own final state at [000009f0] it is necessarily correct for H to
reject this input as non-halting.

--
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 4/20/2022 7:11 AM, Ben wrote:
> Alex C <immibis@gmail.com> writes:
>
>> You guys might all be missing something simple: The "correct
>> simulation" does halt. So when the decider says it doesn't halt, it's
>> wrong.
>
> Who are "you guys"? I see this point being made daily. PO misses that,
> but he's not plural!
>
> And there is an even simpler point than this. PO tells us that
> H(P,P)==false "even though P(P) halts". He now denies that this is in
> anyway significant, but it's the "top-level" reason why he is wrong.
>

Why do you insist that a halt decider must compute the mapping from
non-inputs based on the behavior of these non-inputs when you already
know that this is wrong? WHY LIE ? LYING DEBASES YOURSELF !

Halt deciders must compute the mapping from inputs based on the actual
behavior of these actual inputs. The correctly simulated input to H(P,P)
never halts.

The technical computer science term "halt" means that a program will
reach its last instruction technically called its final state. For P
this would be its machine address [000009f0].

The function named H continues to simulate its input using an x86
emulator until this input either halts on its own or H detects that it
would never halt. If its input halts H returns 1. If H detects that its
input would never halt H returns 0.

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

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

_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]

The simulated input to H(P,P) cannot possibly reach its own final state
of [000009f0] it keeps repeating [000009d6] to [000009e1] until aborted.

Begin Local Halt Decider Simulation
....[000009d6][00211368][0021136c] 55 push ebp // enter P
....[000009d7][00211368][0021136c] 8bec mov ebp,esp
....[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
....[000009dc][00211364][000009d6] 50 push eax // Push P
....[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
....[000009e0][00211360][000009d6] 51 push ecx // Push P
....[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
....[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
....[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
....[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
....[000009dc][0025bd8c][000009d6] 50 push eax // Push P
....[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
....[000009e0][0025bd88][000009d6] 51 push ecx // Push P
....[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Because the correctly simulated input to H(P,P) cannot possibly reach
its own final state at [000009f0] it is necessarily correct for H to
reject this input as non-halting.

--
Copyright 2022 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 4/19/2022 10:05 AM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/18/2022 4:53 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/17/2022 7:08 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/17/2022 10:37 AM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/17/2022 10:09 AM, Ben wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/16/2022 7:45 PM, Ben wrote:
>>>>>>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>>>>>>
>>>>>>>>>>> That requires a halt decider to compute the mapping from non-inputs on
>>>>>>>>>>> the basis of the behavior specified by these non-inputs.
>>>>>>>>>> No.
>>>>>>>>>> Would you like me to explain again? I won't bother unless you ask
>>>>>>>>>> nicely because you've ignored it every time I've done so before.
>>>>>>>>>
>>>>>>>>> P(P) executed independently is not an input to H(P,P) that you would
>>>>>>>>> say otherwise makes you a bald faced liar.
>>>>>>>> So you don't want me to explain? OK. Stay in the dark. That works for
>>>>>>>> me because nothing makes it more certain that you won't be taken
>>>>>>>> seriously than pretending that the halting problem is not about the
>>>>>>>> computations represented by inputs.
>>>>>>>>
>>>>>>>> Your problem is that you /have/ to find a way to neutralise what you
>>>>>>>> said for years about H(P,P)==false and P(P) halting. Unless you can
>>>>>>>
>>>>>>> The fact that the correctly simulated input to H(P,P) is non-halting
>>>>>>> is a 100% sufficient reason for H to report that its input does not
>>>>>>> halt. That you disagree makes you a bald faced liar.
>>>>>>
>>>>>> What makes you think I disagree with that? You won't say what you mean,
>>>>>> or more exactly, you mean to be vague.
>>>>>
>>>>> So then you must agree that when H correctly simulates the input to
>>>>> H(P,P) that it would never reach its own final state.
>>>>
>>>> I think you are just cutting and pasting without any thought now. You
>>>> may not be the sharpest knife in the drawer, but if you'd read what I
>>>> wrote I don't believe even you could not possibly think it logical to
>>>> write that sentence.
>>>
>>> You never do anything besides dodge the point at hand so I continue to
>>> present this point until everyone else realizes that you always only
>>> dodge it and are thereby dishonest.
>>
>> That's a truly silly objective, but I suppose it makes sense to you. In
>> your position, if I had anything important to say I'd publish in a
>> quality journal rather than obsess about what "everyone else realises"
>> about some random bloke on Usenet!

Still talking to me rather than publishing.

>> I won't parse, yet again, what it is that's wrong with your recent
>> mantra (I've done so yet again in another reply just a few minutes ago)
>> because you are wrong on far more basic grounds: H(P,P)==false is
>> incorrect because P(P) halts.
>>
>> Nothing you can say can get round this problem. It's the definition of
>> the problem you took on, and pretending that the correct result is not
>> based on what P(P) (because it's a "non-input") but on some deliberately
>> vague attribute of "the input to H(P,P)" does not make the original
>> problem go away. H does not fit the specification you originally took
>> on.

Nothing to say about this?

>>> Since there are a total of two points that prove that I am correct I
>>> am not going to change the subject away from these two points until
>>> they are fully addressed.
>>
>> Ah, but then you don't know what a proof is, do you? Do you still think
>> that if A,B,C ⊦ X then A,B,C,~A ⊬ X?

So you still stand by this?

> If {an X is a Y} and Z says that {an X is a Y} then Z is necessarily
> correct.

Indeed. And since P(P) (an X) is a halting computation (a Y) and H (AKA
Z) says that P(P) (an x) is /not/ a halting computation (a Y) then H
(AKA Z) is necessarily wrong.

> When a sequence of configurations never halts then this sequence is
> non-halting making H(P,P)==0 necessarily correct.

Of course not. Nothing in this vacuous claim depends on P! This
sentence is just as daft:

When a sequence of configurations never halts then this sequence is
non-halting making H(X42,ZZ)==0 necessarily correct!

H(P,P) is correct or not /depending on some specification/ which you are
currently denying (or pretending to ignore). This is the correct
wording:

When the arguments passed to H represent a non-halting computation[1]
then H(P,P)==0 correct.

[1] Insert waffle about sequences of configurations here if you think it
makes the sentence sound more sciencey.

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

olcott <NoOne@NoWhere.com> writes:

> On 4/20/2022 7:11 AM, Ben wrote:

>> And there is an even simpler point than this. PO tells us that
>> H(P,P)==false "even though P(P) halts". He now denies that this is in
>> anyway significant, but it's the "top-level" reason why he is wrong.
>
> Why do you insist that a halt decider must compute the mapping from
> non-inputs based on the behavior of these non-inputs when you already
> know that this is wrong?

The mapping is from the inputs (in this case function arguments) to a
property (halting or non-halting) of the computation those inputs
represent. You know that. That's the problem you were addressing right
up until you decided you can't sustain justifying the wrong answer
anymore.

> WHY LIE ? LYING DEBASES YOURSELF !

It's true.

It's a very bad look to accuse people of lying. I've stopped calling
you a liar because you admitted that what I called your huge lie was a
case of "poetic license". Now I may doubt that that was what it was,
but I am not prepared to say you were lying without hard evidence, and
"poetic license" means wrong as clearly as your saying "I was wrong".

> Halt deciders must compute the mapping from inputs based on the actual
> behavior of these actual inputs. The correctly simulated input to
> H(P,P) never halts.

Both P(P) and a simulation of P(P) halt. There can be no difference in
terms of halting or not between a computation and a simulation of that
computation. Whatever you are trying to hide behind that matra of "the
input to H(P,P) never halts" has nothing to do with the halting
problem. The fact that you stick to using these junk words suggests you
know you must avoid wording it correctly.

Reminder: there is not input to H(P,P). H is passed two pointers as
arguments in that call. Those pointers neither halt nor do they not
halt, but you dare not say what you really mean.

> The technical computer science term "halt" means that a program will
> reach its last instruction technically called its final state. For P
> this would be its machine address [000009f0].
>
> The function named H continues to simulate its input using an x86
> emulator until this input either halts on its own or H detects that it
> would never halt. If its input halts H returns 1. If H detects that
> its input would never halt H returns 0.

Since P(P) halts, H(P,P) == false is wrong.

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

How do you think this is going to end? You know you have nothing, so
why keep posting? Isn't there something more fun you could be doing?

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

On 4/20/2022 11:20 AM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/20/2022 7:11 AM, Ben wrote:
>
>>> And there is an even simpler point than this. PO tells us that
>>> H(P,P)==false "even though P(P) halts". He now denies that this is in
>>> anyway significant, but it's the "top-level" reason why he is wrong.
>>
>> Why do you insist that a halt decider must compute the mapping from
>> non-inputs based on the behavior of these non-inputs when you already
>> know that this is wrong?
>
> The mapping is from the inputs (in this case function arguments) to a
> property (halting or non-halting) of the computation those inputs
> represent. You know that. That's the problem you were addressing right
> up until you decided you can't sustain justifying the wrong answer
> anymore.

It must be the actual behavior of the actual inputs which is
definitively determined by the correct simulation of these inputs by H.

>
>> WHY LIE ? LYING DEBASES YOURSELF !
>
> It's true.
>

You know that the actual behavior of the actual inputs it ultimately
determined by the correct simulation of these inputs by H, why dodge
this fact? WHY LIE?

> It's a very bad look to accuse people of lying. I've stopped calling
> you a liar because you admitted that what I called your huge lie was a
> case of "poetic license". Now I may doubt that that was what it was,
> but I am not prepared to say you were lying without hard evidence, and
> "poetic license" means wrong as clearly as your saying "I was wrong".
>

According to the objective measures that I have provided you are
directly contradicting the verified facts that you have already agreed
are true.

Anyone that willfully contradicts verified facts that they have already
agreed are true is willfully providing a falsehood that they know is
false, this is the definition of a liar.

>> Halt deciders must compute the mapping from inputs based on the actual
>> behavior of these actual inputs. The correctly simulated input to
>> H(P,P) never halts.
>
> Both P(P) and a simulation of P(P) halt.

Yes you know these neither of these is a correct simulation of the
actual input to H(P,P) itself, and you know this.

> There can be no difference in
> terms of halting or not between a computation and a simulation of that
> computation. Whatever you are trying to hide behind that matra of "the
> input to H(P,P) never halts" has nothing to do with the halting
> problem. The fact that you stick to using these junk words suggests you
> know you must avoid wording it correctly.
>

You keep ignoring that the correct simulation of the input to H(P,P) and
the direct execution of P(P) are computationally distinct different
sequences of configurations thus are by-no-means required to have the
same halting behavior.

Your assumption that they must have the same behavior is refuted by the
fact that they are conclusively proven to not have the same behavior.
It is also conclusively proven the the simulation of the input to H(P,P)
by H is correct on the basis of the semantic meaning of the x86 source
code for P.

> Reminder: there is not input to H(P,P). H is passed two pointers as
> arguments in that call. Those pointers neither halt nor do they not
> halt, but you dare not say what you really mean.
>

This <is> the correct way to specify finite string inputs to a
computable function.

>> The technical computer science term "halt" means that a program will
>> reach its last instruction technically called its final state. For P
>> this would be its machine address [000009f0].
>>
>> The function named H continues to simulate its input using an x86
>> emulator until this input either halts on its own or H detects that it
>> would never halt. If its input halts H returns 1. If H detects that
>> its input would never halt H returns 0.
>
> Since P(P) halts, H(P,P) == false is wrong.
>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>
> How do you think this is going to end? You know you have nothing, so
> why keep posting? Isn't there something more fun you could be doing?
>

I am very obviously correct and you continue to lie.

--
Copyright 2022 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 4/20/2022 11:20 AM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/20/2022 7:11 AM, Ben wrote:
>>
>>>> And there is an even simpler point than this. PO tells us that
>>>> H(P,P)==false "even though P(P) halts". He now denies that this is in
>>>> anyway significant, but it's the "top-level" reason why he is wrong.
>>>
>>> Why do you insist that a halt decider must compute the mapping from
>>> non-inputs based on the behavior of these non-inputs when you already
>>> know that this is wrong?
>> The mapping is from the inputs (in this case function arguments) to a
>> property (halting or non-halting) of the computation those inputs
>> represent. You know that. That's the problem you were addressing right
>> up until you decided you can't sustain justifying the wrong answer
>> anymore.
>
> It must be the actual behavior of the actual inputs which is
> definitively determined by the correct simulation of these inputs by
> H.

There are no inputs to H(P,P). There are arguments to H. They have no
"actual behaviour" because they are just pointers. They can not be
"correctly simulated" because they are just pointers. You won't say
what you mean because you've told us that P(P) halts and yet there is no
other sane interpretation. You must just keep repeating the mantra.
>>> WHY LIE ? LYING DEBASES YOURSELF !
>> It's true.
>
> You know that the actual behavior of the actual inputs it ultimately
> determined by the correct simulation of these inputs by H, why dodge
> this fact? WHY LIE?

Of course I don't. I don't know what the actual behaviour of two
pointers means. I know what the behaviour is of calling one with the
other as an argument, and I know that simulating that call would have
the same behaviour (as far as halting is concerned) but you specifically
reject that interpretation, despite it being the only one that makes
sense.

>> Reminder: there is not input to H(P,P). H is passed two pointers as
>> arguments in that call. Those pointers neither halt nor do they not
>> halt, but you dare not say what you really mean.
>
> This <is> the correct way to specify finite string inputs to a
> computable function.

You should stop using terms you don't understand. And don't cut and
past what Wikipedia (or some other source) says a computable function
is. I already know, even if you don't.

> I am very obviously correct and you continue to lie.

Why talk to me then? I am not important. Just publish. Oh, you can't
because you know you have nothing to say. You just like chatting with
people about this. That's fine.

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

On 4/20/2022 4:59 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/20/2022 11:20 AM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/20/2022 7:11 AM, Ben wrote:
>>>
>>>>> And there is an even simpler point than this. PO tells us that
>>>>> H(P,P)==false "even though P(P) halts". He now denies that this is in
>>>>> anyway significant, but it's the "top-level" reason why he is wrong.
>>>>
>>>> Why do you insist that a halt decider must compute the mapping from
>>>> non-inputs based on the behavior of these non-inputs when you already
>>>> know that this is wrong?
>>> The mapping is from the inputs (in this case function arguments) to a
>>> property (halting or non-halting) of the computation those inputs
>>> represent. You know that. That's the problem you were addressing right
>>> up until you decided you can't sustain justifying the wrong answer
>>> anymore.
>>
>> It must be the actual behavior of the actual inputs which is
>> definitively determined by the correct simulation of these inputs by
>> H.
>
> There are no inputs to H(P,P). There are arguments to H. They have no
> "actual behaviour" because they are just pointers. They can not be
> "correctly simulated" because they are just pointers. You won't say
> what you mean because you've told us that P(P) halts and yet there is no
> other sane interpretation. You must just keep repeating the mantra.
So when I say that the finite strings of machine code pointed to by P
are emulated by an x86 emulator you are so totally clueless about
software engineering that this utterly baffles you beyond all measure.

--
Copyright 2022 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 4/20/2022 4:59 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/20/2022 11:20 AM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/20/2022 7:11 AM, Ben wrote:
>>>>
>>>>>> And there is an even simpler point than this. PO tells us that
>>>>>> H(P,P)==false "even though P(P) halts". He now denies that this is in
>>>>>> anyway significant, but it's the "top-level" reason why he is wrong.
>>>>>
>>>>> Why do you insist that a halt decider must compute the mapping from
>>>>> non-inputs based on the behavior of these non-inputs when you already
>>>>> know that this is wrong?
>>>> The mapping is from the inputs (in this case function arguments) to a
>>>> property (halting or non-halting) of the computation those inputs
>>>> represent. You know that. That's the problem you were addressing right
>>>> up until you decided you can't sustain justifying the wrong answer
>>>> anymore.
>>>
>>> It must be the actual behavior of the actual inputs which is
>>> definitively determined by the correct simulation of these inputs by
>>> H.
>>
>> There are no inputs to H(P,P). There are arguments to H. They have no
>> "actual behaviour" because they are just pointers. They can not be
>> "correctly simulated" because they are just pointers. You won't say
>> what you mean because you've told us that P(P) halts and yet there is no
>> other sane interpretation. You must just keep repeating the mantra.
>
> So when I say that the finite strings of machine code pointed to by P
> are emulated by an x86 emulator you are so totally clueless about
> software engineering that this utterly baffles you beyond all measure.

Of course. You can't attribute any definitive behaviour to the code in
a function if you don't know how it's called. Even you know this.

If you mean simulating the x86 code for P when called with (the address
of) P as the only argument, then, sure, I know what you mean. And I
also know that such a simulation halts (unless it's done wrong) because
you told me that P(P) halts.

Of course this is why you aren't being clear. You have to leave some
ambiguity for the chatting to keep going.

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

On 4/20/22 11:12 AM, olcott wrote:
> On 4/20/2022 7:11 AM, Ben wrote:
>> Alex C <immibis@gmail.com> writes:
>>
>>> You guys might all be missing something simple: The "correct
>>> simulation" does halt. So when the decider says it doesn't halt, it's
>>> wrong.
>>
>> Who are "you guys"?  I see this point being made daily.  PO misses that,
>> but he's not plural!
>>
>> And there is an even simpler point than this.  PO tells us that
>> H(P,P)==false "even though P(P) halts".  He now denies that this is in
>> anyway significant, but it's the "top-level" reason why he is wrong.
>>
>
> Why do you insist that a halt decider must compute the mapping from
> non-inputs based on the behavior of these non-inputs when you already
> know that this is wrong?   WHY LIE ?    LYING DEBASES YOURSELF !

What is 'non-input' about "<H^> <H^>" or (P,P)?

That is what they need to compute the mapping FROM.

The computation to what that input maps TO is, by the definition, the
behavior of H^ applied to <H^> or P(P), that isn't asking about a
mapping FROM a non-input, but of the correct mapping.

Yes, it may be actually IMPOSSIBLE to do that calculation, but that
doesn't make it incorrect to define that as the result of the mapping,
because not all mappings are actually computable.

>
> Halt deciders must compute the mapping from inputs based on the actual
> behavior of these actual inputs. The correctly simulated input to H(P,P)
> never halts.

Except that you use the wrong definition of 'correctly simulated'. as
the REAL definition of correctly simulated as applied to computations,
and in particular the Halting Problem must NEVER abort.

The CORRECT simulatin of the input to H WILL HALT if that H returns the
non-halting answer by the construction of the computation it is deciding on.

>
>
> The technical computer science term "halt" means that a program will
> reach its last instruction technically called its final state. For P
> this would be its machine address [000009f0].

Right, THE PROGRAM, not a 'partial simulation' of it. If you allow
partial simulation then ALL computation can be correct decided to be
non-halting. You can't even use your trying to exclude 'broken deciders'
as by that logic H is broken, since it assumes that the H inside H^/P
will never abort, when we know that it would if allowed to run farther,
since this one does with the exact same input.

>
> The function named H continues to simulate its input using an x86
> emulator until this input either halts on its own or H detects that it
> would never halt. If its input halts H returns 1. If H detects that its
> input would never halt H returns 0.

Except it uses unsound logic to make that conclusion.

First note, that algorithms can't do things like 'prove' or 'detect' an
unspecified pattern. They do exactly what they are programmed to do.

It has been shown that ANY finite pattern that H might see in its
tracing of P(P) that it uses to abort its simulation, will actually be
incorrect as it makes the actual execution of P(P) to halt, as the
H(P,P) that it calls will ALSO make that decision and thus return the
non-halting answer and make P halt.

Thus, either H uses an incorrect pattern, or it simulates for an
unbounded amount of time and fails to give an answer in finite time.

You seem to not understand this basic fact, and just assume that a
pattern must exist (which is just using unsound and invalid logic).

>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [000009d6](01) 55         push ebp
> [000009d7](02) 8bec       mov ebp,esp
> [000009d9](03) 8b4508     mov eax,[ebp+08]
> [000009dc](01) 50         push eax         // push P
> [000009dd](03) 8b4d08     mov ecx,[ebp+08]
> [000009e0](01) 51         push ecx         // push P
> [000009e1](05) e840feffff call 00000826    // call H
> [000009e6](03) 83c408     add esp,+08
> [000009e9](02) 85c0       test eax,eax
> [000009eb](02) 7402       jz 000009ef
> [000009ed](02) ebfe       jmp 000009ed
> [000009ef](01) 5d         pop ebp
> [000009f0](01) c3         ret              // Final state
> Size in bytes:(0027) [000009f0]
>
> The simulated input to H(P,P) cannot possibly reach its own final state
> of [000009f0] it keeps repeating [000009d6] to [000009e1] until aborted.
>
> Begin Local Halt Decider Simulation
> ...[000009d6][00211368][0021136c] 55         push ebp         // enter P
> ...[000009d7][00211368][0021136c] 8bec       mov ebp,esp
> ...[000009d9][00211368][0021136c] 8b4508     mov eax,[ebp+08]
> ...[000009dc][00211364][000009d6] 50         push eax         // Push P
> ...[000009dd][00211364][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][00211360][000009d6] 51         push ecx         // Push P
> ...[000009e1][0021135c][000009e6] e840feffff call 00000826    // Call H
> ...[000009d6][0025bd90][0025bd94] 55         push ebp         // enter P
> ...[000009d7][0025bd90][0025bd94] 8bec       mov ebp,esp
> ...[000009d9][0025bd90][0025bd94] 8b4508     mov eax,[ebp+08]
> ...[000009dc][0025bd8c][000009d6] 50         push eax         // Push P
> ...[000009dd][0025bd8c][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][0025bd88][000009d6] 51         push ecx         // Push P
> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826    // Call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Which shows that this is the trace that an H(P,P) will do, and NOT a
'CORRECT' Simulation of the input to H(P,P).

That simulation would first trace the behavior of H, which is part of
the computation P, and then the return from H, and the to the test and
jz and then to the pop and then the ret, showing that a CORRECT
simulation of this input Halts.

>
> Because the correctly simulated input to H(P,P) cannot possibly reach
> its own final state at [000009f0] it is necessarily correct for H to
> reject this input as non-halting.
>
>
>

Nope, you just don't understand what a CORRECT simulation means, and
just lie that you partial simulation meets the requirements of a CORRECT
simulation, and thus you get an erroneous answer.

FAIL.

On 4/20/22 7:19 PM, olcott wrote:
> On 4/20/2022 4:59 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/20/2022 11:20 AM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/20/2022 7:11 AM, Ben wrote:
>>>>
>>>>>> And there is an even simpler point than this.  PO tells us that
>>>>>> H(P,P)==false "even though P(P) halts".  He now denies that this
>>>>>> is in
>>>>>> anyway significant, but it's the "top-level" reason why he is wrong.
>>>>>
>>>>> Why do you insist that a halt decider must compute the mapping from
>>>>> non-inputs based on the behavior of these non-inputs when you already
>>>>> know that this is wrong?
>>>> The mapping is from the inputs (in this case function arguments) to a
>>>> property (halting or non-halting) of the computation those inputs
>>>> represent.  You know that.  That's the problem you were addressing
>>>> right
>>>> up until you decided you can't sustain justifying the wrong answer
>>>> anymore.
>>>
>>> It must be the actual behavior of the actual inputs which is
>>> definitively determined by the correct simulation of these inputs by
>>> H.
>>
>> There are no inputs to H(P,P).  There are arguments to H.  They have no
>> "actual behaviour" because they are just pointers.  They can not be
>> "correctly simulated" because they are just pointers.  You won't say
>> what you mean because you've told us that P(P) halts and yet there is no
>> other sane interpretation.  You must just keep repeating the mantra.
> So when I say that the finite strings of machine code pointed to by P
> are emulated by an x86 emulator you are so totally clueless about
> software engineering that this utterly baffles you beyond all measure.
>

Except the finite strings of machine code don't ACTUALLY have proper
behaivor as they refer to something that isn't defined, the contents of
the memory at 00000826.

You may SAY that this is obviously the contents of H, but if that isn't
included in the string, it doesn't actually define a behavior.

Thus, you LIE when you say it has a specific behavior, because it
doesn't, it only has a behavior in the context of a SPECIFIC H.

And, if H aborts and returns 0, then the H that P calls must do the
same, but that isn't what you 'correct' simulation shows, so it isn't a
correct simulation.

On 4/20/22 11:00 AM, olcott wrote:
> On 4/20/2022 6:34 AM, Alex C wrote:
>> You guys might all be missing something simple: The "correct
>> simulation" does halt. So when the decider says it doesn't halt, it's
>> wrong.
>
> That is the strawman error.
>
> When H(P,P) correctly simulates its input using an x86 emulator does the
> simulated P reach its last instruction?
>
> The technical computer science term "halt" means that a program will
> reach its last instruction technically called its final state. For P
> this would be its machine address [000009f0].
>
> The function named H continues to simulate its input using an x86
> emulator until this input either halts on its own or H detects that it
> would never halt. If its input halts H returns 1. If H detects that its
> input would never halt H returns 0.
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [000009d6](01) 55         push ebp
> [000009d7](02) 8bec       mov ebp,esp
> [000009d9](03) 8b4508     mov eax,[ebp+08]
> [000009dc](01) 50         push eax         // push P
> [000009dd](03) 8b4d08     mov ecx,[ebp+08]
> [000009e0](01) 51         push ecx         // push P
> [000009e1](05) e840feffff call 00000826    // call H
> [000009e6](03) 83c408     add esp,+08
> [000009e9](02) 85c0       test eax,eax
> [000009eb](02) 7402       jz 000009ef
> [000009ed](02) ebfe       jmp 000009ed
> [000009ef](01) 5d         pop ebp
> [000009f0](01) c3         ret              // Final state
> Size in bytes:(0027) [000009f0]
>
> The simulated input to H(P,P) cannot possibly reach its own final state
> of [000009f0] it keeps repeating [000009d6] to [000009e1] until aborted.
>
> Begin Local Halt Decider Simulation
> ...[000009d6][00211368][0021136c] 55         push ebp         // enter P
> ...[000009d7][00211368][0021136c] 8bec       mov ebp,esp
> ...[000009d9][00211368][0021136c] 8b4508     mov eax,[ebp+08]
> ...[000009dc][00211364][000009d6] 50         push eax         // Push P
> ...[000009dd][00211364][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][00211360][000009d6] 51         push ecx         // Push P
> ...[000009e1][0021135c][000009e6] e840feffff call 00000826    // Call H
> ...[000009d6][0025bd90][0025bd94] 55         push ebp         // enter P
> ...[000009d7][0025bd90][0025bd94] 8bec       mov ebp,esp
> ...[000009d9][0025bd90][0025bd94] 8b4508     mov eax,[ebp+08]
> ...[000009dc][0025bd8c][000009d6] 50         push eax         // Push P
> ...[000009dd][0025bd8c][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][0025bd88][000009d6] 51         push ecx         // Push P
> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826    // Call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> Because the correctly simulated input to H(P,P) cannot possibly reach
> its own final state at [000009f0] it is necessarily correct for H to
> reject this input as non-halting.
>

WRONG, it only never completes if H doesn't abort, at which point H
isn't correct because it doesn't answer.

If H does abort, then it does so incorrectly as it can be shown that if
H does abort then the CORRECT simulation of the input halts.

Which way is it wrong?