On Monday, 29 August 2022 at 20:29:32 UTC+2, Ben Bacarisse wrote:
> Skep Dick <skepd...@gmail.com> writes:
>
> > On Monday, 29 August 2022 at 16:29:57 UTC+2, Ben Bacarisse wrote:
> >> In PO's model
> > That's impossible.
> Eh?
It is impossible that YOU are working in his model. Because YOUR are disagreeing with the results of his functions.

> > There is no decider in PO's model which determines this. How have you
> > arrived at this answer?
> From PO's words: H(P,P) == false is correct "even though P(P) halts".
So that's just a negation away from being correct?!? Man, that's a super-easy bugfix! I thought you had a serious objection.

Just negate the return value!

Alernatively re-calibrate your understanding of WHICH question H is answering.

Maybe H doesn't answers "Does P(P) halt?" True - it halts. False - it doesn't halt.
Maybe H answers "Does P(P) NOT halt?" True - it does NOT halt. False - it halts.

> > He hasn't persuaded me.
> Great. Is there some point of disagreement between us on PO's non-result?
Absolutely there is! I am neither agreeing nor disagreeing with PO (beyond wearing different hats/perspectives) - It's his model/topos, he can interpret it however he likes; and do within it as he pleases.

On the other hand you do seem to be disagreeing. Quite strongly at that. To the point where you use moral judgments like "right" and "wrong".

> > "I don't understand the difference between Nat -> Nat -> Bool and Nat
> > -> Nat -> Nat!" (Ben Bacarisse, Aug 2022)
> That's dishonest. I think you should aim higher.
Why is it "dishonest"? That was entirely the essence of your disagreement. Was it not?

On Monday, August 29, 2022 at 7:41:35 PM UTC+1, olcott wrote:
> On 8/29/2022 8:09 AM, Paul N wrote:
> > On Sunday, August 28, 2022 at 8:47:18 PM UTC+1, olcott wrote:
> >> Since Turing machines are mathematical objects that only exist in the
> >> mind people can have contradictory thus incoherent ideas about these
> >> abstract mathematical objects and never realize that their ideas are
> >> incoherent.
> >
> > I think it might help to look at things a different way.
> >
> > In most of your posts, you are looking at the problem from the point of view of the simulator. For many programs, a human can look at the program and see whether it halts or not. So it is tempting to think that a program ought to be able to look at another program, run it carefully and decide whether or not it halts. You, of course, think that you have already perfected such a program, but even if you didn't it is quite understandable that you would think you were at least nearly there and that only a little bit more tinkering was required.
> >
> > Let's look instead that the function P we are considering. This is copied from one of your earlier posts, it's not quite the same as the one in the post I'm replying to, but it sets it all out very neatly:
> >
> >
> > typedef void (*ptr)();
> > int H(ptr p, ptr i); // simulating halt decider
> >
> > // P does the opposite of whatever H decides
> > void P(ptr x)
> > {
> > int Halt_Status = H(x, x);
> > if (Halt_Status) // if H(P,P) reports that its input halts
> > HERE: goto HERE; // P loops and never halts
> > return; // else P halts
> > }
> >
> > int main()
> > {
> > Output("Input_Halts = ", H(P, P));
> > }
> >
> > P is a nice simple function. It calls H and branches on the result. You have told us that H(P, P) is zero, so Halt_Status is set to zero, the "if" fails, we get to the "return" and the function ends. All nice and simple. The problem is that H(P, P) being zero is supposed to say that P does not halt.
> >
> > So does H get it wrong? Well, we can imagine what would happen if H(P, P) were non-zero - Halt_Status is set to non-zero, the "if" succeeds, we go into the loop and the function never ends. This time the problem is that H(P, P) being non-zero is supposed to say that P does halt.
> >
> > When we look at it this way, it seems clearer that there is no way H can work properly. You have tried two different techniques to explain things away. Sometimes you say that P is not the program that H(P, P) is considering - even going so far sometimes to say that it is a "non-input", but this is clearly nonsense, if P is the first argument then P is the program being considered. The other approach is to say that, although P halts, in some sense it doesn't really halt. Sometime you "prove" this by asserting both that your simulator is correct and that it says P does not halt, instead of recognising this as a contradiction. Other times you talk about simulations - your simulator aborts when if (supposedly) works out that P is not going to halt, and so the results you get are somehow not what really happens.
> >
> > I think considering the function that P actually is gives a much better understanding of what is going on than simply talking about simulations and posting traces.
> *THIS IS KNOWN TO BE TRUE ON THE BASIS OF THE MEANING OF ITS WORDS*
> The UTM SIMULATION of a machine description always provides the actual
> behavior specified by this machine description.
>
> When-so-ever a simulating halt decider must abort the simulation of its
> input to prevent the infinite execution of this input it has correctly
> predicted the actual behavior of this input because a simulating halt
> decider that never aborts its simulation is a UTM.

I wrote about why H can never be correct, and I thought what I had written was nice and clear.

You've written some stuff about simulations which doesn't even seem to make grammatical sense. It certainly doesn't attempt to rebut what I wrote.

H is being given an impossible job to do. You can't rebut that simply by asserting that your simulator is right.

On 8/29/2022 2:17 PM, Paul N wrote:
> On Monday, August 29, 2022 at 7:41:35 PM UTC+1, olcott wrote:
>> On 8/29/2022 8:09 AM, Paul N wrote:
>>> On Sunday, August 28, 2022 at 8:47:18 PM UTC+1, olcott wrote:
>>>> Since Turing machines are mathematical objects that only exist in the
>>>> mind people can have contradictory thus incoherent ideas about these
>>>> abstract mathematical objects and never realize that their ideas are
>>>> incoherent.
>>>
>>> I think it might help to look at things a different way.
>>>
>>> In most of your posts, you are looking at the problem from the point of view of the simulator. For many programs, a human can look at the program and see whether it halts or not. So it is tempting to think that a program ought to be able to look at another program, run it carefully and decide whether or not it halts. You, of course, think that you have already perfected such a program, but even if you didn't it is quite understandable that you would think you were at least nearly there and that only a little bit more tinkering was required.
>>>
>>> Let's look instead that the function P we are considering. This is copied from one of your earlier posts, it's not quite the same as the one in the post I'm replying to, but it sets it all out very neatly:
>>>
>>>
>>> typedef void (*ptr)();
>>> int H(ptr p, ptr i); // simulating halt decider
>>>
>>> // P does the opposite of whatever H decides
>>> void P(ptr x)
>>> {
>>> int Halt_Status = H(x, x);
>>> if (Halt_Status) // if H(P,P) reports that its input halts
>>> HERE: goto HERE; // P loops and never halts
>>> return; // else P halts
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>> P is a nice simple function. It calls H and branches on the result. You have told us that H(P, P) is zero, so Halt_Status is set to zero, the "if" fails, we get to the "return" and the function ends. All nice and simple. The problem is that H(P, P) being zero is supposed to say that P does not halt.
>>>
>>> So does H get it wrong? Well, we can imagine what would happen if H(P, P) were non-zero - Halt_Status is set to non-zero, the "if" succeeds, we go into the loop and the function never ends. This time the problem is that H(P, P) being non-zero is supposed to say that P does halt.
>>>
>>> When we look at it this way, it seems clearer that there is no way H can work properly. You have tried two different techniques to explain things away. Sometimes you say that P is not the program that H(P, P) is considering - even going so far sometimes to say that it is a "non-input", but this is clearly nonsense, if P is the first argument then P is the program being considered. The other approach is to say that, although P halts, in some sense it doesn't really halt. Sometime you "prove" this by asserting both that your simulator is correct and that it says P does not halt, instead of recognising this as a contradiction. Other times you talk about simulations - your simulator aborts when if (supposedly) works out that P is not going to halt, and so the results you get are somehow not what really happens.
>>>
>>> I think considering the function that P actually is gives a much better understanding of what is going on than simply talking about simulations and posting traces.
>> *THIS IS KNOWN TO BE TRUE ON THE BASIS OF THE MEANING OF ITS WORDS*
>> The UTM SIMULATION of a machine description always provides the actual
>> behavior specified by this machine description.
>>
>> When-so-ever a simulating halt decider must abort the simulation of its
>> input to prevent the infinite execution of this input it has correctly
>> predicted the actual behavior of this input because a simulating halt
>> decider that never aborts its simulation is a UTM.
>
> I wrote about why H can never be correct, and I thought what I had written was nice and clear.
>
> You've written some stuff about simulations which doesn't even seem to make grammatical sense. It certainly doesn't attempt to rebut what I wrote.

That you do not understand that H bases its halt status decision on the
UTM simulation of its input and that the UTM simulation of its input is
the ultimate measure of the actual behavior of this input is NO REBUTTAL
AT ALL.

>
> H is being given an impossible job to do. You can't rebut that simply by asserting that your simulator is right.
>

That you do not understand that when the simulator derives a
line-by-line execution trace that exactly matches the line-by-line x86
source-code of P conclusively proves that the simulation is correct is
again NO REBUTTAL AT ALL.

--
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 Monday, 29 August 2022 at 21:43:48 UTC+2, olcott wrote:
> That you do not understand that when the simulator derives a
> line-by-line execution trace that exactly matches the line-by-line x86
> source-code of P conclusively proves that the simulation is correct is
> again NO REBUTTAL AT ALL.
Neither they get it.
Nor you get it.

The result of the sumulation is precisely what the result of the simulattion is. Neither more. Nor less.
The function returns precisely the answer that it returns which signals precisely whatever H is configured to detect.

That doesn't make H "correct" or "incorrect". It makes H map some peculiarity about the execution of P to a Boolean.

YOU (the human/oracle) are DEFINING that result as "correct". You are injecting your own meaning into the system.

Skep Dick <skepdick22@gmail.com> writes:

> On Monday, 29 August 2022 at 20:29:32 UTC+2, Ben Bacarisse wrote:
>> Skep Dick <skepd...@gmail.com> writes:
<cut>
>> > He hasn't persuaded me.
>> Great. Is there some point of disagreement between us on PO's non-result?
>
> Absolutely there is! I am neither agreeing nor disagreeing with PO
> (beyond wearing different hats/perspectives) - It's his model/topos,
> he can interpret it however he likes; and do within it as he pleases.

Ah then we agree. He can say any old junk he likes. The trouble is
that PO thinks someone might be interested in his model and his
interpretation of it (as you put it).

But I'm going to guess that you are neither interested nor are you not
interested in it (since I doubt you've ever seen a fence you didn't want
to sit on) so we disagree about that?

> On the other hand you do seem to be disagreeing. Quite strongly at
> that.

No, you are quite right. He can make up any old model and interpret it
in any way he pleases. But /PO/ disagrees because he wants to be
talking about the conventional model and the conventional results. He's
never been interested in being right about some junk model and some
silly interpretation of it. He wants to be right about the usual models
(or at least one of them).

>> > "I don't understand the difference between Nat -> Nat -> Bool and Nat
>> > -> Nat -> Nat!" (Ben Bacarisse, Aug 2022)
>> That's dishonest. I think you should aim higher.
>
> Why is it "dishonest"?

Oh dear. You don't even know when you are being dishonest (or so you
claim). Well, I think others can decide for themselves.

--
Ben.
"What's the 0th integer greater than 4? It's 4!" (Skep Dick, Aug 2022)

Message-ID: <a3d63c9e-a151-4fc6-adb8-64dd7325e38dn@googlegroups.com>

On 8/29/22 1:12 PM, olcott wrote:
> On 8/28/2022 10:18 PM, Richard Damon wrote:
>> On 8/28/22 11:15 PM, olcott wrote:
>>> On 8/28/2022 10:01 PM, Richard Damon wrote:
>>>> On 8/28/22 10:47 PM, olcott wrote:
>>>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Since Turing machines are mathematical objects that only
>>>>>>>>>>>>> exist in the
>>>>>>>>>>>>> mind people can have contradictory thus incoherent ideas
>>>>>>>>>>>>> about these
>>>>>>>>>>>>> abstract mathematical objects and never realize that their
>>>>>>>>>>>>> ideas are
>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When we study the theory of computation using physically
>>>>>>>>>>>>> existing
>>>>>>>>>>>>> machines such as the x86 architecture then the incoherent
>>>>>>>>>>>>> abstract
>>>>>>>>>>>>> ideas are shown to be incoherent in that they cannot be
>>>>>>>>>>>>> physically
>>>>>>>>>>>>> implemented.
>>>>>>>>>>>>>
>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>> return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> If a decider must always return a value whenever it is
>>>>>>>>>>>>> called this
>>>>>>>>>>>>> requires H to return a value to Px even though H is called in
>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This even requires that the function call from Px to
>>>>>>>>>>>>> H(Px,Px) must
>>>>>>>>>>>>> return a value to Px even if this function call to H is not
>>>>>>>>>>>>> even
>>>>>>>>>>>>> executed. In the physical model of computation it is an
>>>>>>>>>>>>> axiom the
>>>>>>>>>>>>> programs that are not executed never return values because
>>>>>>>>>>>>> it is
>>>>>>>>>>>>> physically impossible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When simulating halt decider H sees that Px is about to
>>>>>>>>>>>>> call H(Px,Px)
>>>>>>>>>>>>> in infinite recursion H aborts its simulation of Px before
>>>>>>>>>>>>> this call
>>>>>>>>>>>>> is executed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>>>>> Computer science says that H must still return a value to
>>>>>>>>>>>>> Px even
>>>>>>>>>>>>> though the call to H is not even executed because all
>>>>>>>>>>>>> deciders must
>>>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>>>
>>>>>>>>>>>> Computer science is correct on this point, what is incorrect
>>>>>>>>>>>> is your
>>>>>>>>>>>> implementation of H.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>> So you are saying the a computer program that is never even
>>>>>>>>>>> executed
>>>>>>>>>>> must still return a result?
>>>>>>>>>>
>>>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>>>>>
>>>>>>>>>> No problem - is just a definition.
>>>>>>>>>
>>>>>>>>> H(Px,Px) returns 0 to main. Some people have said that the when
>>>>>>>>> Px calls H(Px,Px) that H must return a value to Px even though
>>>>>>>>> this function call from Px to H is never executed.
>>>>>>>>
>>>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS
>>>>>>>> executed.
>>>>>>>>
>>>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior
>>>>>>>> that H determines.
>>>>>>>>
>>>>>>>
>>>>>>> You said that H must always return a result to its caller even if
>>>>>>> this call is never actually executed.
>>>>>>>
>>>>>>
>>>>>> You don't HAVE a caller unless you execute the call instruction.
>>>>>
>>>>> DON'T CHANGE THE SUBJECT
>>>>> DON'T CHANGE THE SUBJECT
>>>>> DON'T CHANGE THE SUBJECT
>>>>
>>>> I DIDN'T. I don't think you know what a subject is.
>>>>
>>>>>
>>>>> A decider must always return to its caller:
>>>>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY EXECUTED*
>>>>>
>>>>
>>>> So, you don't think that Px calls H?
>>>
>>> The call to H(Px,Px) from P is never executed, thus H need not return
>>> to Px.
>>>
>>>
>>
>> But it is in the complete simulation of the input to H(Px,Px), and
>> that is what matters for the answer that H is supposed to give.
>>
>
> *This thread had nothing to do with that*
> The question is whether or not H must return a value to Px when the call
> to H(Px,Px) from Px is never invoked.
>
>

Which is a meaningless question except in the context of a complete
simulation/execution.

As I said before, if H aborts its simulation, it doesn't need to reach
the returnn from H, but its logic needs to take into account that a
complete simulation WILL do that.

You somehow think there are lots of rules about what a decider does
inside itself to make its determination. It could play Dixie for all we
care, the quesiton is does the answer match the required one.

This is also why the correct answer is NEVER correctly framed in terms
of something the decider does, because that is irrelevant. What IS
relevent is the ACTUAL INPUT, and the ACTUAL BEHAVIOR of the input,
which, for a Halt Decider is defined by the running of the ACTUAL
machine, or the simulation of the input by an ACTUAL UTM (not just H
playing one on TV).

The ACTUAL BEHAVIOR of the ACTUAL INPUT to H(Px, Px) halts, thus the
ONLY CORRECT answer for H to give is Halting. Thus it returning 0 as
WRONG BY DEFINTION.

On 8/29/22 9:28 AM, Skep Dick wrote:
> On Monday, 29 August 2022 at 13:37:20 UTC+2, richar...@gmail.com wrote:
>> Translation: I can't express it without revealing my stupidity.
> Translation to the translation: I reveal my own stupidity when I show utter ignorance of the problem with ALL static abstractions.
>
> https://en.wikipedia.org/wiki/Expression_problem

Since *I* am not talking "Programming Languages" that doesn't matter to me.

Its YOUR problem.

On 8/29/2022 6:18 PM, Richard Damon wrote:
>
> On 8/29/22 1:12 PM, olcott wrote:
>> On 8/28/2022 10:18 PM, Richard Damon wrote:
>>> On 8/28/22 11:15 PM, olcott wrote:
>>>> On 8/28/2022 10:01 PM, Richard Damon wrote:
>>>>> On 8/28/22 10:47 PM, olcott wrote:
>>>>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Since Turing machines are mathematical objects that only
>>>>>>>>>>>>>> exist in the
>>>>>>>>>>>>>> mind people can have contradictory thus incoherent ideas
>>>>>>>>>>>>>> about these
>>>>>>>>>>>>>> abstract mathematical objects and never realize that their
>>>>>>>>>>>>>> ideas are
>>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When we study the theory of computation using physically
>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>> machines such as the x86 architecture then the incoherent
>>>>>>>>>>>>>> abstract
>>>>>>>>>>>>>> ideas are shown to be incoherent in that they cannot be
>>>>>>>>>>>>>> physically
>>>>>>>>>>>>>> implemented.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If a decider must always return a value whenever it is
>>>>>>>>>>>>>> called this
>>>>>>>>>>>>>> requires H to return a value to Px even though H is called in
>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This even requires that the function call from Px to
>>>>>>>>>>>>>> H(Px,Px) must
>>>>>>>>>>>>>> return a value to Px even if this function call to H is
>>>>>>>>>>>>>> not even
>>>>>>>>>>>>>> executed. In the physical model of computation it is an
>>>>>>>>>>>>>> axiom the
>>>>>>>>>>>>>> programs that are not executed never return values because
>>>>>>>>>>>>>> it is
>>>>>>>>>>>>>> physically impossible.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When simulating halt decider H sees that Px is about to
>>>>>>>>>>>>>> call H(Px,Px)
>>>>>>>>>>>>>> in infinite recursion H aborts its simulation of Px before
>>>>>>>>>>>>>> this call
>>>>>>>>>>>>>> is executed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>>>>>> Computer science says that H must still return a value to
>>>>>>>>>>>>>> Px even
>>>>>>>>>>>>>> though the call to H is not even executed because all
>>>>>>>>>>>>>> deciders must
>>>>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Computer science is correct on this point, what is
>>>>>>>>>>>>> incorrect is your
>>>>>>>>>>>>> implementation of H.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>> So you are saying the a computer program that is never even
>>>>>>>>>>>> executed
>>>>>>>>>>>> must still return a result?
>>>>>>>>>>>
>>>>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>>>>>>
>>>>>>>>>>> No problem - is just a definition.
>>>>>>>>>>
>>>>>>>>>> H(Px,Px) returns 0 to main. Some people have said that the
>>>>>>>>>> when Px calls H(Px,Px) that H must return a value to Px even
>>>>>>>>>> though this function call from Px to H is never executed.
>>>>>>>>>
>>>>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS
>>>>>>>>> executed.
>>>>>>>>>
>>>>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior
>>>>>>>>> that H determines.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You said that H must always return a result to its caller even
>>>>>>>> if this call is never actually executed.
>>>>>>>>
>>>>>>>
>>>>>>> You don't HAVE a caller unless you execute the call instruction.
>>>>>>
>>>>>> DON'T CHANGE THE SUBJECT
>>>>>> DON'T CHANGE THE SUBJECT
>>>>>> DON'T CHANGE THE SUBJECT
>>>>>
>>>>> I DIDN'T. I don't think you know what a subject is.
>>>>>
>>>>>>
>>>>>> A decider must always return to its caller:
>>>>>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY EXECUTED*
>>>>>>
>>>>>
>>>>> So, you don't think that Px calls H?
>>>>
>>>> The call to H(Px,Px) from P is never executed, thus H need not
>>>> return to Px.
>>>>
>>>>
>>>
>>> But it is in the complete simulation of the input to H(Px,Px), and
>>> that is what matters for the answer that H is supposed to give.
>>>
>>
>> *This thread had nothing to do with that*
>> The question is whether or not H must return a value to Px when the
>> call to H(Px,Px) from Px is never invoked.
>>
>>
>
> Which is a meaningless question except in the context of a complete
> simulation/execution.
Does the fact that the invocation of H(Px,Px) from Px that is never
executed prevent H from being a decider?

No of course not. A decider must not and is forbidden from returning any
value to any caller when this call is never executed.

--
Copyright 2022 Pete Olcott

On 8/29/22 7:28 PM, olcott wrote:
> On 8/29/2022 6:18 PM, Richard Damon wrote:
>>
>> On 8/29/22 1:12 PM, olcott wrote:
>>> On 8/28/2022 10:18 PM, Richard Damon wrote:
>>>> On 8/28/22 11:15 PM, olcott wrote:
>>>>> On 8/28/2022 10:01 PM, Richard Damon wrote:
>>>>>> On 8/28/22 10:47 PM, olcott wrote:
>>>>>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since Turing machines are mathematical objects that only
>>>>>>>>>>>>>>> exist in the
>>>>>>>>>>>>>>> mind people can have contradictory thus incoherent ideas
>>>>>>>>>>>>>>> about these
>>>>>>>>>>>>>>> abstract mathematical objects and never realize that
>>>>>>>>>>>>>>> their ideas are
>>>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When we study the theory of computation using physically
>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>> machines such as the x86 architecture then the incoherent
>>>>>>>>>>>>>>> abstract
>>>>>>>>>>>>>>> ideas are shown to be incoherent in that they cannot be
>>>>>>>>>>>>>>> physically
>>>>>>>>>>>>>>> implemented.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If a decider must always return a value whenever it is
>>>>>>>>>>>>>>> called this
>>>>>>>>>>>>>>> requires H to return a value to Px even though H is
>>>>>>>>>>>>>>> called in
>>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This even requires that the function call from Px to
>>>>>>>>>>>>>>> H(Px,Px) must
>>>>>>>>>>>>>>> return a value to Px even if this function call to H is
>>>>>>>>>>>>>>> not even
>>>>>>>>>>>>>>> executed. In the physical model of computation it is an
>>>>>>>>>>>>>>> axiom the
>>>>>>>>>>>>>>> programs that are not executed never return values
>>>>>>>>>>>>>>> because it is
>>>>>>>>>>>>>>> physically impossible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When simulating halt decider H sees that Px is about to
>>>>>>>>>>>>>>> call H(Px,Px)
>>>>>>>>>>>>>>> in infinite recursion H aborts its simulation of Px
>>>>>>>>>>>>>>> before this call
>>>>>>>>>>>>>>> is executed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>>>>>>> Computer science says that H must still return a value to
>>>>>>>>>>>>>>> Px even
>>>>>>>>>>>>>>> though the call to H is not even executed because all
>>>>>>>>>>>>>>> deciders must
>>>>>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Computer science is correct on this point, what is
>>>>>>>>>>>>>> incorrect is your
>>>>>>>>>>>>>> implementation of H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>> So you are saying the a computer program that is never even
>>>>>>>>>>>>> executed
>>>>>>>>>>>>> must still return a result?
>>>>>>>>>>>>
>>>>>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>>>>>>>
>>>>>>>>>>>> No problem - is just a definition.
>>>>>>>>>>>
>>>>>>>>>>> H(Px,Px) returns 0 to main. Some people have said that the
>>>>>>>>>>> when Px calls H(Px,Px) that H must return a value to Px even
>>>>>>>>>>> though this function call from Px to H is never executed.
>>>>>>>>>>
>>>>>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS
>>>>>>>>>> executed.
>>>>>>>>>>
>>>>>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior
>>>>>>>>>> that H determines.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You said that H must always return a result to its caller even
>>>>>>>>> if this call is never actually executed.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You don't HAVE a caller unless you execute the call instruction.
>>>>>>>
>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>
>>>>>> I DIDN'T. I don't think you know what a subject is.
>>>>>>
>>>>>>>
>>>>>>> A decider must always return to its caller:
>>>>>>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY
>>>>>>> EXECUTED*
>>>>>>>
>>>>>>
>>>>>> So, you don't think that Px calls H?
>>>>>
>>>>> The call to H(Px,Px) from P is never executed, thus H need not
>>>>> return to Px.
>>>>>
>>>>>
>>>>
>>>> But it is in the complete simulation of the input to H(Px,Px), and
>>>> that is what matters for the answer that H is supposed to give.
>>>>
>>>
>>> *This thread had nothing to do with that*
>>> The question is whether or not H must return a value to Px when the
>>> call to H(Px,Px) from Px is never invoked.
>>>
>>>
>>
>> Which is a meaningless question except in the context of a complete
>> simulation/execution.
> Does the fact that the invocation of H(Px,Px) from Px that is never
> executed prevent H from being a decider?

On 8/29/22 2:01 PM, olcott wrote:
> On 8/29/2022 6:24 AM, Juha Nieminen wrote:
>> In comp.lang.c++ olcott <NoOne@nowhere.com> wrote:
>>> Since Turing machines are mathematical objects that only exist in the
>>> mind people can have contradictory thus incoherent ideas about these
>>> abstract mathematical objects and never realize that their ideas are
>>> incoherent.
>>>
>>> When we study the theory of computation using physically existing
>>> machines such as the x86 architecture then the incoherent abstract ideas
>>> are shown to be incoherent in that they cannot be physically
>>> implemented.
>>
>> You can't limit yourself to a particular computer architecture because if
>> you do, then your results are useless.
>>
>> If, for example, we limit ourselves to the x86 computer architecture,
>> then
>> in principle every single algorithm is technically either O(1) or
>> can't be
>> computed. Which is a completely useless result.
>
> By moving from an abstract model of computation where every detail is
> merely imagined and never concretely demonstrated it is possible to
> imaging that a decider must return a result to every caller even in the
> case where the function call is not even executed.

Except that Turing Machine CAN be concretely demonstrated, you have even
used a program that showed it (and then decided that you needed to
re-write it because you disagreed on how it worked).

>
> When we move to a concrete model of computation we know that it is
> utterly ridiculous that a program that is never executed produces any
> output. From this we can know that decider are not supposed to return
> any values when a function call to them is never actually executed.

But we can ask what output it would generate if run.

>
> void P(ptr x)
> {
>   H(x, x);

See, P calls H

>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
>
> _Px()
> [00001102](01)  55             push ebp
> [00001103](02)  8bec           mov ebp,esp
> [00001105](03)  8b4508         mov eax,[ebp+08]
> [00001108](01)  50             push eax       // push P
> [00001109](03)  8b4d08         mov ecx,[ebp+08]
> [0000110c](01)  51             push ecx       // push P
> [0000110d](05)  e880fdffff     call 00000e92  // call H
> [00001112](03)  83c408         add esp,+08
> [00001115](01)  5d             pop ebp
> [00001116](01)  c3             ret
> Size in bytes:(0021) [00001116]
>
> H aborts its simulation of P as soon as H sees that P would call H at
> machine address [0000110d] before this call is even executed.
>
> According to what two people have said computer science requires
> deciders to return values to their callers even if the call is never
> executed.
>

But you seem to think that H aborting its simulation stopped the actual
program from ever going farther. In Reality, the Program P(P) Will
continue pass the call that H stopped at and H will the eventually
return 0 and then P will halt.

THus the RIGHT answer to does the input to H(P,P) Halt is YES.

By YOUR logic, a simulator that halted it simulation immediately would
be correct to call ALL computation non-halting.

That means even your H.

That means your H is not a decider as it doesn't always return an answer.

That is why aborted simulation don't define halting behavior.

Note in particular, the Halting problem isn't about a given (partial)
simulation of a program, but about the actual behavior of the program,
as that is something that is consistent.

We can also substitute the UTM simulation of the representation of the
program, as that ALWAYS exactly duplicates the behavior of the direct
exectution.

H, since it aborts its simulation, is therefore NOT a UTM.

Yes, you can sometimes use CORRECT logic to determine in finite time
that the UTM simulation would go on forever, line in infinit_loop or
infinite_recursion. But the logic you try to use on P isn't correct, as
is shown by the fact that UTM(P,P) Halts, so there CAN'T be a trace in
that simulation that "proves" that it will be non-halting.

On 8/29/2022 7:50 PM, Richard Damon wrote:
>
> On 8/29/22 7:28 PM, olcott wrote:
>> On 8/29/2022 6:18 PM, Richard Damon wrote:
>>>
>>> On 8/29/22 1:12 PM, olcott wrote:
>>>> On 8/28/2022 10:18 PM, Richard Damon wrote:
>>>>> On 8/28/22 11:15 PM, olcott wrote:
>>>>>> On 8/28/2022 10:01 PM, Richard Damon wrote:
>>>>>>> On 8/28/22 10:47 PM, olcott wrote:
>>>>>>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>>>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Since Turing machines are mathematical objects that only
>>>>>>>>>>>>>>>> exist in the
>>>>>>>>>>>>>>>> mind people can have contradictory thus incoherent ideas
>>>>>>>>>>>>>>>> about these
>>>>>>>>>>>>>>>> abstract mathematical objects and never realize that
>>>>>>>>>>>>>>>> their ideas are
>>>>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When we study the theory of computation using physically
>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>> machines such as the x86 architecture then the
>>>>>>>>>>>>>>>> incoherent abstract
>>>>>>>>>>>>>>>> ideas are shown to be incoherent in that they cannot be
>>>>>>>>>>>>>>>> physically
>>>>>>>>>>>>>>>> implemented.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If a decider must always return a value whenever it is
>>>>>>>>>>>>>>>> called this
>>>>>>>>>>>>>>>> requires H to return a value to Px even though H is
>>>>>>>>>>>>>>>> called in
>>>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This even requires that the function call from Px to
>>>>>>>>>>>>>>>> H(Px,Px) must
>>>>>>>>>>>>>>>> return a value to Px even if this function call to H is
>>>>>>>>>>>>>>>> not even
>>>>>>>>>>>>>>>> executed. In the physical model of computation it is an
>>>>>>>>>>>>>>>> axiom the
>>>>>>>>>>>>>>>> programs that are not executed never return values
>>>>>>>>>>>>>>>> because it is
>>>>>>>>>>>>>>>> physically impossible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When simulating halt decider H sees that Px is about to
>>>>>>>>>>>>>>>> call H(Px,Px)
>>>>>>>>>>>>>>>> in infinite recursion H aborts its simulation of Px
>>>>>>>>>>>>>>>> before this call
>>>>>>>>>>>>>>>> is executed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>>>>>>>> Computer science says that H must still return a value
>>>>>>>>>>>>>>>> to Px even
>>>>>>>>>>>>>>>> though the call to H is not even executed because all
>>>>>>>>>>>>>>>> deciders must
>>>>>>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Computer science is correct on this point, what is
>>>>>>>>>>>>>>> incorrect is your
>>>>>>>>>>>>>>> implementation of H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So you are saying the a computer program that is never
>>>>>>>>>>>>>> even executed
>>>>>>>>>>>>>> must still return a result?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No problem - is just a definition.
>>>>>>>>>>>>
>>>>>>>>>>>> H(Px,Px) returns 0 to main. Some people have said that the
>>>>>>>>>>>> when Px calls H(Px,Px) that H must return a value to Px even
>>>>>>>>>>>> though this function call from Px to H is never executed.
>>>>>>>>>>>
>>>>>>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS
>>>>>>>>>>> executed.
>>>>>>>>>>>
>>>>>>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior
>>>>>>>>>>> that H determines.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You said that H must always return a result to its caller even
>>>>>>>>>> if this call is never actually executed.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You don't HAVE a caller unless you execute the call instruction.
>>>>>>>>
>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>
>>>>>>> I DIDN'T. I don't think you know what a subject is.
>>>>>>>
>>>>>>>>
>>>>>>>> A decider must always return to its caller:
>>>>>>>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY
>>>>>>>> EXECUTED*
>>>>>>>>
>>>>>>>
>>>>>>> So, you don't think that Px calls H?
>>>>>>
>>>>>> The call to H(Px,Px) from P is never executed, thus H need not
>>>>>> return to Px.
>>>>>>
>>>>>>
>>>>>
>>>>> But it is in the complete simulation of the input to H(Px,Px), and
>>>>> that is what matters for the answer that H is supposed to give.
>>>>>
>>>>
>>>> *This thread had nothing to do with that*
>>>> The question is whether or not H must return a value to Px when the
>>>> call to H(Px,Px) from Px is never invoked.
>>>>
>>>>
>>>
>>> Which is a meaningless question except in the context of a complete
>>> simulation/execution.
>> Does the fact that the invocation of H(Px,Px) from Px that is never
>> executed prevent H from being a decider?
>
> What do you meen it never "gets executed"?
>

On 8/29/22 2:41 PM, olcott wrote:
> On 8/29/2022 8:09 AM, Paul N wrote:
>> On Sunday, August 28, 2022 at 8:47:18 PM UTC+1, olcott wrote:
>>> Since Turing machines are mathematical objects that only exist in the
>>> mind people can have contradictory thus incoherent ideas about these
>>> abstract mathematical objects and never realize that their ideas are
>>> incoherent.
>>
>> I think it might help to look at things a different way.
>>
>> In most of your posts, you are looking at the problem from the point
>> of view of the simulator. For many programs, a human can look at the
>> program and see whether it halts or not. So it is tempting to think
>> that a program ought to be able to look at another program, run it
>> carefully and decide whether or not it halts. You, of course, think
>> that you have already perfected such a program, but even if you didn't
>> it is quite understandable that you would think you were at least
>> nearly there and that only a little bit more tinkering was required.
>>
>> Let's look instead that the function P we are considering. This is
>> copied from one of your earlier posts, it's not quite the same as the
>> one in the post I'm replying to, but it sets it all out very neatly:
>>
>>
>> typedef void (*ptr)();
>> int H(ptr p, ptr i); // simulating halt decider
>>
>> // P does the opposite of whatever H decides
>> void P(ptr x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status) // if H(P,P) reports that its input halts
>> HERE: goto HERE; // P loops and never halts
>> return; // else P halts
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> }
>>
>> P is a nice simple function. It calls H and branches on the result.
>> You have told us that H(P, P) is zero, so Halt_Status is set to zero,
>> the "if" fails, we get to the "return" and the function ends. All nice
>> and simple. The problem is that H(P, P) being zero is supposed to say
>> that P does not halt.
>>
>> So does H get it wrong? Well, we can imagine what would happen if H(P,
>> P) were non-zero - Halt_Status is set to non-zero, the "if" succeeds,
>> we go into the loop and the function never ends. This time the problem
>> is that H(P, P) being non-zero is supposed to say that P does halt.
>>
>> When we look at it this way, it seems clearer that there is no way H
>> can work properly. You have tried two different techniques to explain
>> things away. Sometimes you say that P is not the program that H(P, P)
>> is considering - even going so far sometimes to say that it is a
>> "non-input", but this is clearly nonsense, if P is the first argument
>> then P is the program being considered. The other approach is to say
>> that, although P halts, in some sense it doesn't really halt. Sometime
>> you "prove" this by asserting both that your simulator is correct and
>> that it says P does not halt, instead of recognising this as a
>> contradiction. Other times you talk about simulations - your simulator
>> aborts when if (supposedly) works out that P is not going to halt, and
>> so the results you get are somehow not what really happens.
>>
>> I think considering the function that P actually is gives a much
>> better understanding of what is going on than simply talking about
>> simulations and posting traces.
>
> *THIS IS KNOWN TO BE TRUE ON THE BASIS OF THE MEANING OF ITS WORDS*
> The UTM SIMULATION of a machine description always provides the actual
> behavior specified by this machine description.

Yes, and UTM(P,P) will Halt since H(P,P) returns 0.

>
> When-so-ever a simulating halt decider must abort the simulation of its
> input to prevent the infinite execution of this input it has correctly
> predicted the actual behavior of this input because a simulating halt
> decider that never aborts its simulation is a UTM.
>
>

Nope, at least not as you are using it, because in this case THIS copy
of H doesn't need to abort its simulation, because the copy of H on the
input will and return 0 and cause P(P) to Halt.

You action of CHANING THE INPUT (by changing H in your hypothetical), is
an invalid step, as H is no longer looking at the ACTUAL BEHAVIOR of the
ACTUAL INPUT.

In fact, your ruse only appear to work because you broke the rules
earlier and didn't put a COPY of H into P, but intertwined the two
programs in a way that they are no longer two separate programs.

This means that you H can NOT be converted to a Turing Machine that
meets the definition, as it doesn't actually take an input, but the P
you call its input is part of the program that calls H.

On 8/29/2022 8:02 PM, Richard Damon wrote:
>
> On 8/29/22 2:01 PM, olcott wrote:
>> On 8/29/2022 6:24 AM, Juha Nieminen wrote:
>>> In comp.lang.c++ olcott <NoOne@nowhere.com> wrote:
>>>> Since Turing machines are mathematical objects that only exist in the
>>>> mind people can have contradictory thus incoherent ideas about these
>>>> abstract mathematical objects and never realize that their ideas are
>>>> incoherent.
>>>>
>>>> When we study the theory of computation using physically existing
>>>> machines such as the x86 architecture then the incoherent abstract
>>>> ideas
>>>> are shown to be incoherent in that they cannot be physically
>>>> implemented.
>>>
>>> You can't limit yourself to a particular computer architecture
>>> because if
>>> you do, then your results are useless.
>>>
>>> If, for example, we limit ourselves to the x86 computer architecture,
>>> then
>>> in principle every single algorithm is technically either O(1) or
>>> can't be
>>> computed. Which is a completely useless result.
>>
>> By moving from an abstract model of computation where every detail is
>> merely imagined and never concretely demonstrated it is possible to
>> imaging that a decider must return a result to every caller even in
>> the case where the function call is not even executed.
>
> Except that Turing Machine CAN be concretely demonstrated, you have even
> used a program that showed it (and then decided that you needed to
> re-write it because you disagreed on how it worked).
>
>>
>> When we move to a concrete model of computation we know that it is
>> utterly ridiculous that a program that is never executed produces any
>> output. From this we can know that decider are not supposed to return
>> any values when a function call to them is never actually executed.
>
> But we can ask what output it would generate if run.
>
>
>
>>
>> void P(ptr x)
>> {
>>    H(x, x);
>
> See, P calls H
>
>>    return;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H(P, P));
>> }
>>
>>
>> _Px()
>> [00001102](01)  55             push ebp
>> [00001103](02)  8bec           mov ebp,esp
>> [00001105](03)  8b4508         mov eax,[ebp+08]
>> [00001108](01)  50             push eax       // push P
>> [00001109](03)  8b4d08         mov ecx,[ebp+08]
>> [0000110c](01)  51             push ecx       // push P
>> [0000110d](05)  e880fdffff     call 00000e92  // call H
>> [00001112](03)  83c408         add esp,+08
>> [00001115](01)  5d             pop ebp
>> [00001116](01)  c3             ret
>> Size in bytes:(0021) [00001116]
>>
>> H aborts its simulation of P as soon as H sees that P would call H at
>> machine address [0000110d] before this call is even executed.
>>
>> According to what two people have said computer science requires
>> deciders to return values to their callers even if the call is never
>> executed.
>>
>
> But you seem to think that H aborting its simulation stopped the actual
> program from ever going farther.

It stopped infinitely recursive simulation that still makes it
impossible for a correct decider to return a value to its caller.

--
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 8/29/22 3:53 PM, Skep Dick wrote:
> On Monday, 29 August 2022 at 21:43:48 UTC+2, olcott wrote:
>> That you do not understand that when the simulator derives a
>> line-by-line execution trace that exactly matches the line-by-line x86
>> source-code of P conclusively proves that the simulation is correct is
>> again NO REBUTTAL AT ALL.
> Neither they get it.
> Nor you get it.
>
> The result of the sumulation is precisely what the result of the simulattion is. Neither more. Nor less.
> The function returns precisely the answer that it returns which signals precisely whatever H is configured to detect.
>
> That doesn't make H "correct" or "incorrect". It makes H map some peculiarity about the execution of P to a Boolean.
>
> YOU (the human/oracle) are DEFINING that result as "correct". You are injecting your own meaning into the system.
>
>

No, the AUTHOR of the program made a claim that it answers a particular
question.

The answer it gives does not match the correct answer to that question,
so it is just wrong in answering that question.

It may be answering some other question correctly, but the question it
was said to answer, it did not.

On 8/29/22 9:05 PM, olcott wrote:
> On 8/29/2022 7:50 PM, Richard Damon wrote:
>>
>> On 8/29/22 7:28 PM, olcott wrote:
>>> On 8/29/2022 6:18 PM, Richard Damon wrote:
>>>>
>>>> On 8/29/22 1:12 PM, olcott wrote:
>>>>> On 8/28/2022 10:18 PM, Richard Damon wrote:
>>>>>> On 8/28/22 11:15 PM, olcott wrote:
>>>>>>> On 8/28/2022 10:01 PM, Richard Damon wrote:
>>>>>>>> On 8/28/22 10:47 PM, olcott wrote:
>>>>>>>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>>>>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>>>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Since Turing machines are mathematical objects that
>>>>>>>>>>>>>>>>> only exist in the
>>>>>>>>>>>>>>>>> mind people can have contradictory thus incoherent
>>>>>>>>>>>>>>>>> ideas about these
>>>>>>>>>>>>>>>>> abstract mathematical objects and never realize that
>>>>>>>>>>>>>>>>> their ideas are
>>>>>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When we study the theory of computation using
>>>>>>>>>>>>>>>>> physically existing
>>>>>>>>>>>>>>>>> machines such as the x86 architecture then the
>>>>>>>>>>>>>>>>> incoherent abstract
>>>>>>>>>>>>>>>>> ideas are shown to be incoherent in that they cannot be
>>>>>>>>>>>>>>>>> physically
>>>>>>>>>>>>>>>>> implemented.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If a decider must always return a value whenever it is
>>>>>>>>>>>>>>>>> called this
>>>>>>>>>>>>>>>>> requires H to return a value to Px even though H is
>>>>>>>>>>>>>>>>> called in
>>>>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This even requires that the function call from Px to
>>>>>>>>>>>>>>>>> H(Px,Px) must
>>>>>>>>>>>>>>>>> return a value to Px even if this function call to H is
>>>>>>>>>>>>>>>>> not even
>>>>>>>>>>>>>>>>> executed. In the physical model of computation it is an
>>>>>>>>>>>>>>>>> axiom the
>>>>>>>>>>>>>>>>> programs that are not executed never return values
>>>>>>>>>>>>>>>>> because it is
>>>>>>>>>>>>>>>>> physically impossible.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When simulating halt decider H sees that Px is about to
>>>>>>>>>>>>>>>>> call H(Px,Px)
>>>>>>>>>>>>>>>>> in infinite recursion H aborts its simulation of Px
>>>>>>>>>>>>>>>>> before this call
>>>>>>>>>>>>>>>>> is executed.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>>>>>>>>> Computer science says that H must still return a value
>>>>>>>>>>>>>>>>> to Px even
>>>>>>>>>>>>>>>>> though the call to H is not even executed because all
>>>>>>>>>>>>>>>>> deciders must
>>>>>>>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Computer science is correct on this point, what is
>>>>>>>>>>>>>>>> incorrect is your
>>>>>>>>>>>>>>>> implementation of H.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So you are saying the a computer program that is never
>>>>>>>>>>>>>>> even executed
>>>>>>>>>>>>>>> must still return a result?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>>>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No problem - is just a definition.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H(Px,Px) returns 0 to main. Some people have said that the
>>>>>>>>>>>>> when Px calls H(Px,Px) that H must return a value to Px
>>>>>>>>>>>>> even though this function call from Px to H is never executed.
>>>>>>>>>>>>
>>>>>>>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS
>>>>>>>>>>>> executed.
>>>>>>>>>>>>
>>>>>>>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the
>>>>>>>>>>>> behavior that H determines.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You said that H must always return a result to its caller
>>>>>>>>>>> even if this call is never actually executed.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You don't HAVE a caller unless you execute the call instruction.
>>>>>>>>>
>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>
>>>>>>>> I DIDN'T. I don't think you know what a subject is.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> A decider must always return to its caller:
>>>>>>>>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY
>>>>>>>>> EXECUTED*
>>>>>>>>>
>>>>>>>>
>>>>>>>> So, you don't think that Px calls H?
>>>>>>>
>>>>>>> The call to H(Px,Px) from P is never executed, thus H need not
>>>>>>> return to Px.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> But it is in the complete simulation of the input to H(Px,Px), and
>>>>>> that is what matters for the answer that H is supposed to give.
>>>>>>
>>>>>
>>>>> *This thread had nothing to do with that*
>>>>> The question is whether or not H must return a value to Px when the
>>>>> call to H(Px,Px) from Px is never invoked.
>>>>>
>>>>>
>>>>
>>>> Which is a meaningless question except in the context of a complete
>>>> simulation/execution.
>>> Does the fact that the invocation of H(Px,Px) from Px that is never
>>> executed prevent H from being a decider?
>>
>> What do you meen it never "gets executed"?
>>
>
> H(Px,Px) cannot return any value to the correctly simulated Px because
> the correctly simulated Px is aborted before its call to H(Px,Px) is
> executed.

On 8/29/22 9:08 PM, olcott wrote:
> On 8/29/2022 8:02 PM, Richard Damon wrote:
>>
>> On 8/29/22 2:01 PM, olcott wrote:
>>> On 8/29/2022 6:24 AM, Juha Nieminen wrote:
>>>> In comp.lang.c++ olcott <NoOne@nowhere.com> wrote:
>>>>> Since Turing machines are mathematical objects that only exist in the
>>>>> mind people can have contradictory thus incoherent ideas about these
>>>>> abstract mathematical objects and never realize that their ideas are
>>>>> incoherent.
>>>>>
>>>>> When we study the theory of computation using physically existing
>>>>> machines such as the x86 architecture then the incoherent abstract
>>>>> ideas
>>>>> are shown to be incoherent in that they cannot be physically
>>>>> implemented.
>>>>
>>>> You can't limit yourself to a particular computer architecture
>>>> because if
>>>> you do, then your results are useless.
>>>>
>>>> If, for example, we limit ourselves to the x86 computer
>>>> architecture, then
>>>> in principle every single algorithm is technically either O(1) or
>>>> can't be
>>>> computed. Which is a completely useless result.
>>>
>>> By moving from an abstract model of computation where every detail is
>>> merely imagined and never concretely demonstrated it is possible to
>>> imaging that a decider must return a result to every caller even in
>>> the case where the function call is not even executed.
>>
>> Except that Turing Machine CAN be concretely demonstrated, you have
>> even used a program that showed it (and then decided that you needed
>> to re-write it because you disagreed on how it worked).
>>
>>>
>>> When we move to a concrete model of computation we know that it is
>>> utterly ridiculous that a program that is never executed produces any
>>> output. From this we can know that decider are not supposed to return
>>> any values when a function call to them is never actually executed.
>>
>> But we can ask what output it would generate if run.
>>
>>
>>
>>>
>>> void P(ptr x)
>>> {
>>>    H(x, x);
>>
>> See, P calls H
>>
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>>
>>> _Px()
>>> [00001102](01)  55             push ebp
>>> [00001103](02)  8bec           mov ebp,esp
>>> [00001105](03)  8b4508         mov eax,[ebp+08]
>>> [00001108](01)  50             push eax       // push P
>>> [00001109](03)  8b4d08         mov ecx,[ebp+08]
>>> [0000110c](01)  51             push ecx       // push P
>>> [0000110d](05)  e880fdffff     call 00000e92  // call H
>>> [00001112](03)  83c408         add esp,+08
>>> [00001115](01)  5d             pop ebp
>>> [00001116](01)  c3             ret
>>> Size in bytes:(0021) [00001116]
>>>
>>> H aborts its simulation of P as soon as H sees that P would call H at
>>> machine address [0000110d] before this call is even executed.
>>>
>>> According to what two people have said computer science requires
>>> deciders to return values to their callers even if the call is never
>>> executed.
>>>
>>
>> But you seem to think that H aborting its simulation stopped the
>> actual program from ever going farther.
>
> It stopped infinitely recursive simulation that still makes it
> impossible for a correct decider to return a value to its caller.
>
>

But there was no infinite recursion, because H is DEFINED to do that
abort, thus breaking up the POTENTIAL infinite recursion. Only a
DIFFERENT H ends up in the infinite recursion, and would be correct to
say non-halting, it is just that since it doesn't abort, it can't give
the answer.

Yes, in one sense you are right, it is impossible for H to be a correct
halting decider, but that is because it is trying to compute a
non-computable mapping, whichis exactly what the Halting Theorem says.

On 8/29/2022 8:50 PM, Richard Damon wrote:
> On 8/29/22 9:05 PM, olcott wrote:
>> On 8/29/2022 7:50 PM, Richard Damon wrote:
>>>
>>> On 8/29/22 7:28 PM, olcott wrote:
>>>> On 8/29/2022 6:18 PM, Richard Damon wrote:
>>>>>
>>>>> On 8/29/22 1:12 PM, olcott wrote:
>>>>>> On 8/28/2022 10:18 PM, Richard Damon wrote:
>>>>>>> On 8/28/22 11:15 PM, olcott wrote:
>>>>>>>> On 8/28/2022 10:01 PM, Richard Damon wrote:
>>>>>>>>> On 8/28/22 10:47 PM, olcott wrote:
>>>>>>>>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>>>>>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>>>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Since Turing machines are mathematical objects that
>>>>>>>>>>>>>>>>>> only exist in the
>>>>>>>>>>>>>>>>>> mind people can have contradictory thus incoherent
>>>>>>>>>>>>>>>>>> ideas about these
>>>>>>>>>>>>>>>>>> abstract mathematical objects and never realize that
>>>>>>>>>>>>>>>>>> their ideas are
>>>>>>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When we study the theory of computation using
>>>>>>>>>>>>>>>>>> physically existing
>>>>>>>>>>>>>>>>>> machines such as the x86 architecture then the
>>>>>>>>>>>>>>>>>> incoherent abstract
>>>>>>>>>>>>>>>>>> ideas are shown to be incoherent in that they cannot
>>>>>>>>>>>>>>>>>> be physically
>>>>>>>>>>>>>>>>>> implemented.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If a decider must always return a value whenever it is
>>>>>>>>>>>>>>>>>> called this
>>>>>>>>>>>>>>>>>> requires H to return a value to Px even though H is
>>>>>>>>>>>>>>>>>> called in
>>>>>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This even requires that the function call from Px to
>>>>>>>>>>>>>>>>>> H(Px,Px) must
>>>>>>>>>>>>>>>>>> return a value to Px even if this function call to H
>>>>>>>>>>>>>>>>>> is not even
>>>>>>>>>>>>>>>>>> executed. In the physical model of computation it is
>>>>>>>>>>>>>>>>>> an axiom the
>>>>>>>>>>>>>>>>>> programs that are not executed never return values
>>>>>>>>>>>>>>>>>> because it is
>>>>>>>>>>>>>>>>>> physically impossible.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When simulating halt decider H sees that Px is about
>>>>>>>>>>>>>>>>>> to call H(Px,Px)
>>>>>>>>>>>>>>>>>> in infinite recursion H aborts its simulation of Px
>>>>>>>>>>>>>>>>>> before this call
>>>>>>>>>>>>>>>>>> is executed.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>>>>>>>>>> Computer science says that H must still return a value
>>>>>>>>>>>>>>>>>> to Px even
>>>>>>>>>>>>>>>>>> though the call to H is not even executed because all
>>>>>>>>>>>>>>>>>> deciders must
>>>>>>>>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Computer science is correct on this point, what is
>>>>>>>>>>>>>>>>> incorrect is your
>>>>>>>>>>>>>>>>> implementation of H.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So you are saying the a computer program that is never
>>>>>>>>>>>>>>>> even executed
>>>>>>>>>>>>>>>> must still return a result?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>>>>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No problem - is just a definition.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H(Px,Px) returns 0 to main. Some people have said that the
>>>>>>>>>>>>>> when Px calls H(Px,Px) that H must return a value to Px
>>>>>>>>>>>>>> even though this function call from Px to H is never
>>>>>>>>>>>>>> executed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the call
>>>>>>>>>>>>> IS executed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the
>>>>>>>>>>>>> behavior that H determines.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You said that H must always return a result to its caller
>>>>>>>>>>>> even if this call is never actually executed.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You don't HAVE a caller unless you execute the call instruction.
>>>>>>>>>>
>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>
>>>>>>>>> I DIDN'T. I don't think you know what a subject is.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> A decider must always return to its caller:
>>>>>>>>>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY
>>>>>>>>>> EXECUTED*
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So, you don't think that Px calls H?
>>>>>>>>
>>>>>>>> The call to H(Px,Px) from P is never executed, thus H need not
>>>>>>>> return to Px.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> But it is in the complete simulation of the input to H(Px,Px),
>>>>>>> and that is what matters for the answer that H is supposed to give.
>>>>>>>
>>>>>>
>>>>>> *This thread had nothing to do with that*
>>>>>> The question is whether or not H must return a value to Px when
>>>>>> the call to H(Px,Px) from Px is never invoked.
>>>>>>
>>>>>>
>>>>>
>>>>> Which is a meaningless question except in the context of a complete
>>>>> simulation/execution.
>>>> Does the fact that the invocation of H(Px,Px) from Px that is never
>>>> executed prevent H from being a decider?
>>>
>>> What do you meen it never "gets executed"?
>>>
>>
>> H(Px,Px) cannot return any value to the correctly simulated Px because
>> the correctly simulated Px is aborted before its call to H(Px,Px) is
>> executed.
>
> Nope. because the actual behavior of Px is to directly call H(Px,Px)
>

On 8/29/2022 8:54 PM, Richard Damon wrote:
>
> On 8/29/22 9:08 PM, olcott wrote:
>> On 8/29/2022 8:02 PM, Richard Damon wrote:
>>>
>>> On 8/29/22 2:01 PM, olcott wrote:
>>>> On 8/29/2022 6:24 AM, Juha Nieminen wrote:
>>>>> In comp.lang.c++ olcott <NoOne@nowhere.com> wrote:
>>>>>> Since Turing machines are mathematical objects that only exist in the
>>>>>> mind people can have contradictory thus incoherent ideas about these
>>>>>> abstract mathematical objects and never realize that their ideas are
>>>>>> incoherent.
>>>>>>
>>>>>> When we study the theory of computation using physically existing
>>>>>> machines such as the x86 architecture then the incoherent abstract
>>>>>> ideas
>>>>>> are shown to be incoherent in that they cannot be physically
>>>>>> implemented.
>>>>>
>>>>> You can't limit yourself to a particular computer architecture
>>>>> because if
>>>>> you do, then your results are useless.
>>>>>
>>>>> If, for example, we limit ourselves to the x86 computer
>>>>> architecture, then
>>>>> in principle every single algorithm is technically either O(1) or
>>>>> can't be
>>>>> computed. Which is a completely useless result.
>>>>
>>>> By moving from an abstract model of computation where every detail
>>>> is merely imagined and never concretely demonstrated it is possible
>>>> to imaging that a decider must return a result to every caller even
>>>> in the case where the function call is not even executed.
>>>
>>> Except that Turing Machine CAN be concretely demonstrated, you have
>>> even used a program that showed it (and then decided that you needed
>>> to re-write it because you disagreed on how it worked).
>>>
>>>>
>>>> When we move to a concrete model of computation we know that it is
>>>> utterly ridiculous that a program that is never executed produces
>>>> any output. From this we can know that decider are not supposed to
>>>> return any values when a function call to them is never actually
>>>> executed.
>>>
>>> But we can ask what output it would generate if run.
>>>
>>>
>>>
>>>>
>>>> void P(ptr x)
>>>> {
>>>>    H(x, x);
>>>
>>> See, P calls H
>>>
>>>>    return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H(P, P));
>>>> }
>>>>
>>>>
>>>> _Px()
>>>> [00001102](01)  55             push ebp
>>>> [00001103](02)  8bec           mov ebp,esp
>>>> [00001105](03)  8b4508         mov eax,[ebp+08]
>>>> [00001108](01)  50             push eax       // push P
>>>> [00001109](03)  8b4d08         mov ecx,[ebp+08]
>>>> [0000110c](01)  51             push ecx       // push P
>>>> [0000110d](05)  e880fdffff     call 00000e92  // call H
>>>> [00001112](03)  83c408         add esp,+08
>>>> [00001115](01)  5d             pop ebp
>>>> [00001116](01)  c3             ret
>>>> Size in bytes:(0021) [00001116]
>>>>
>>>> H aborts its simulation of P as soon as H sees that P would call H
>>>> at machine address [0000110d] before this call is even executed.
>>>>
>>>> According to what two people have said computer science requires
>>>> deciders to return values to their callers even if the call is never
>>>> executed.
>>>>
>>>
>>> But you seem to think that H aborting its simulation stopped the
>>> actual program from ever going farther.
>>
>> It stopped infinitely recursive simulation that still makes it
>> impossible for a correct decider to return a value to its caller.
>>
>>
>
> But there was no infinite recursion,

Then show all of the detail of the precise steps where H returns a value
to its simulated Px.

--
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 8/29/22 10:16 PM, olcott wrote:
> On 8/29/2022 8:50 PM, Richard Damon wrote:
>> On 8/29/22 9:05 PM, olcott wrote:
>>> On 8/29/2022 7:50 PM, Richard Damon wrote:
>>>>
>>>> On 8/29/22 7:28 PM, olcott wrote:
>>>>> On 8/29/2022 6:18 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 8/29/22 1:12 PM, olcott wrote:
>>>>>>> On 8/28/2022 10:18 PM, Richard Damon wrote:
>>>>>>>> On 8/28/22 11:15 PM, olcott wrote:
>>>>>>>>> On 8/28/2022 10:01 PM, Richard Damon wrote:
>>>>>>>>>> On 8/28/22 10:47 PM, olcott wrote:
>>>>>>>>>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>>>>>>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>>>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>>>>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Since Turing machines are mathematical objects that
>>>>>>>>>>>>>>>>>>> only exist in the
>>>>>>>>>>>>>>>>>>> mind people can have contradictory thus incoherent
>>>>>>>>>>>>>>>>>>> ideas about these
>>>>>>>>>>>>>>>>>>> abstract mathematical objects and never realize that
>>>>>>>>>>>>>>>>>>> their ideas are
>>>>>>>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When we study the theory of computation using
>>>>>>>>>>>>>>>>>>> physically existing
>>>>>>>>>>>>>>>>>>> machines such as the x86 architecture then the
>>>>>>>>>>>>>>>>>>> incoherent abstract
>>>>>>>>>>>>>>>>>>> ideas are shown to be incoherent in that they cannot
>>>>>>>>>>>>>>>>>>> be physically
>>>>>>>>>>>>>>>>>>> implemented.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If a decider must always return a value whenever it
>>>>>>>>>>>>>>>>>>> is called this
>>>>>>>>>>>>>>>>>>> requires H to return a value to Px even though H is
>>>>>>>>>>>>>>>>>>> called in
>>>>>>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This even requires that the function call from Px to
>>>>>>>>>>>>>>>>>>> H(Px,Px) must
>>>>>>>>>>>>>>>>>>> return a value to Px even if this function call to H
>>>>>>>>>>>>>>>>>>> is not even
>>>>>>>>>>>>>>>>>>> executed. In the physical model of computation it is
>>>>>>>>>>>>>>>>>>> an axiom the
>>>>>>>>>>>>>>>>>>> programs that are not executed never return values
>>>>>>>>>>>>>>>>>>> because it is
>>>>>>>>>>>>>>>>>>> physically impossible.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When simulating halt decider H sees that Px is about
>>>>>>>>>>>>>>>>>>> to call H(Px,Px)
>>>>>>>>>>>>>>>>>>> in infinite recursion H aborts its simulation of Px
>>>>>>>>>>>>>>>>>>> before this call
>>>>>>>>>>>>>>>>>>> is executed.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>>>>>>>>>>> Computer science says that H must still return a
>>>>>>>>>>>>>>>>>>> value to Px even
>>>>>>>>>>>>>>>>>>> though the call to H is not even executed because all
>>>>>>>>>>>>>>>>>>> deciders must
>>>>>>>>>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Computer science is correct on this point, what is
>>>>>>>>>>>>>>>>>> incorrect is your
>>>>>>>>>>>>>>>>>> implementation of H.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So you are saying the a computer program that is never
>>>>>>>>>>>>>>>>> even executed
>>>>>>>>>>>>>>>>> must still return a result?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>>>>>>>>>> This is equivalent of treating non-termination as an
>>>>>>>>>>>>>>>> effect.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No problem - is just a definition.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H(Px,Px) returns 0 to main. Some people have said that
>>>>>>>>>>>>>>> the when Px calls H(Px,Px) that H must return a value to
>>>>>>>>>>>>>>> Px even though this function call from Px to H is never
>>>>>>>>>>>>>>> executed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the call
>>>>>>>>>>>>>> IS executed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the
>>>>>>>>>>>>>> behavior that H determines.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You said that H must always return a result to its caller
>>>>>>>>>>>>> even if this call is never actually executed.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You don't HAVE a caller unless you execute the call
>>>>>>>>>>>> instruction.
>>>>>>>>>>>
>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>
>>>>>>>>>> I DIDN'T. I don't think you know what a subject is.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> A decider must always return to its caller:
>>>>>>>>>>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY
>>>>>>>>>>> EXECUTED*
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, you don't think that Px calls H?
>>>>>>>>>
>>>>>>>>> The call to H(Px,Px) from P is never executed, thus H need not
>>>>>>>>> return to Px.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> But it is in the complete simulation of the input to H(Px,Px),
>>>>>>>> and that is what matters for the answer that H is supposed to give.
>>>>>>>>
>>>>>>>
>>>>>>> *This thread had nothing to do with that*
>>>>>>> The question is whether or not H must return a value to Px when
>>>>>>> the call to H(Px,Px) from Px is never invoked.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Which is a meaningless question except in the context of a
>>>>>> complete simulation/execution.
>>>>> Does the fact that the invocation of H(Px,Px) from Px that is never
>>>>> executed prevent H from being a decider?
>>>>
>>>> What do you meen it never "gets executed"?
>>>>
>>>
>>> H(Px,Px) cannot return any value to the correctly simulated Px
>>> because the correctly simulated Px is aborted before its call to
>>> H(Px,Px) is executed.
>>
>> Nope. because the actual behavior of Px is to directly call H(Px,Px)
>>
>
> There is no actual behavior of Px such that H can possibly return any
> value to its simulated Px.
>
>
Your being illogical again.

On 8/29/22 10:21 PM, olcott wrote:
> On 8/29/2022 8:54 PM, Richard Damon wrote:
>>
>> On 8/29/22 9:08 PM, olcott wrote:
>>> On 8/29/2022 8:02 PM, Richard Damon wrote:
>>>>
>>>> On 8/29/22 2:01 PM, olcott wrote:
>>>>> On 8/29/2022 6:24 AM, Juha Nieminen wrote:
>>>>>> In comp.lang.c++ olcott <NoOne@nowhere.com> wrote:
>>>>>>> Since Turing machines are mathematical objects that only exist in
>>>>>>> the
>>>>>>> mind people can have contradictory thus incoherent ideas about these
>>>>>>> abstract mathematical objects and never realize that their ideas are
>>>>>>> incoherent.
>>>>>>>
>>>>>>> When we study the theory of computation using physically existing
>>>>>>> machines such as the x86 architecture then the incoherent
>>>>>>> abstract ideas
>>>>>>> are shown to be incoherent in that they cannot be physically
>>>>>>> implemented.
>>>>>>
>>>>>> You can't limit yourself to a particular computer architecture
>>>>>> because if
>>>>>> you do, then your results are useless.
>>>>>>
>>>>>> If, for example, we limit ourselves to the x86 computer
>>>>>> architecture, then
>>>>>> in principle every single algorithm is technically either O(1) or
>>>>>> can't be
>>>>>> computed. Which is a completely useless result.
>>>>>
>>>>> By moving from an abstract model of computation where every detail
>>>>> is merely imagined and never concretely demonstrated it is possible
>>>>> to imaging that a decider must return a result to every caller even
>>>>> in the case where the function call is not even executed.
>>>>
>>>> Except that Turing Machine CAN be concretely demonstrated, you have
>>>> even used a program that showed it (and then decided that you needed
>>>> to re-write it because you disagreed on how it worked).
>>>>
>>>>>
>>>>> When we move to a concrete model of computation we know that it is
>>>>> utterly ridiculous that a program that is never executed produces
>>>>> any output. From this we can know that decider are not supposed to
>>>>> return any values when a function call to them is never actually
>>>>> executed.
>>>>
>>>> But we can ask what output it would generate if run.
>>>>
>>>>
>>>>
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>    H(x, x);
>>>>
>>>> See, P calls H
>>>>
>>>>>    return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>>
>>>>>
>>>>> _Px()
>>>>> [00001102](01)  55             push ebp
>>>>> [00001103](02)  8bec           mov ebp,esp
>>>>> [00001105](03)  8b4508         mov eax,[ebp+08]
>>>>> [00001108](01)  50             push eax       // push P
>>>>> [00001109](03)  8b4d08         mov ecx,[ebp+08]
>>>>> [0000110c](01)  51             push ecx       // push P
>>>>> [0000110d](05)  e880fdffff     call 00000e92  // call H
>>>>> [00001112](03)  83c408         add esp,+08
>>>>> [00001115](01)  5d             pop ebp
>>>>> [00001116](01)  c3             ret
>>>>> Size in bytes:(0021) [00001116]
>>>>>
>>>>> H aborts its simulation of P as soon as H sees that P would call H
>>>>> at machine address [0000110d] before this call is even executed.
>>>>>
>>>>> According to what two people have said computer science requires
>>>>> deciders to return values to their callers even if the call is
>>>>> never executed.
>>>>>
>>>>
>>>> But you seem to think that H aborting its simulation stopped the
>>>> actual program from ever going farther.
>>>
>>> It stopped infinitely recursive simulation that still makes it
>>> impossible for a correct decider to return a value to its caller.
>>>
>>>
>>
>> But there was no infinite recursion,
>
> Then show all of the detail of the precise steps where H returns a value
> to its simulated Px.
>
>

Never said it did.

A simulate Px can call a simualte H(Px,Px) and get an answer, its just
that H can't do that simulation, because it aborts and thus isn't a
source of actual behavior.

You err in thinking that the simulation that H does means anything other
than to H to help it make its decision.

NO behvavior of the input is based on the SIMUALATION that H does, only
the final answer it gives.

How H works is a internal private detail.

I have shown a detailed description of the steps that a CORRECT AND
COMPLETE simulation of Px(Px) calling H(Px,Px) and getting the answer
and halting would go.

Maybe not x86 instruction by x86 instruction, but as you say, the volume
of pages doesn't actualy add anything that the CORREcT consise
description gives.

You haven't pointed out an error in it, so I am presuming that you
accept it (or at least can't point out an actual error in it).

On 8/29/2022 9:32 PM, Richard Damon wrote:
>
> On 8/29/22 10:16 PM, olcott wrote:
>> On 8/29/2022 8:50 PM, Richard Damon wrote:
>>> On 8/29/22 9:05 PM, olcott wrote:
>>>> On 8/29/2022 7:50 PM, Richard Damon wrote:
>>>>>
>>>>> On 8/29/22 7:28 PM, olcott wrote:
>>>>>> On 8/29/2022 6:18 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 8/29/22 1:12 PM, olcott wrote:
>>>>>>>> On 8/28/2022 10:18 PM, Richard Damon wrote:
>>>>>>>>> On 8/28/22 11:15 PM, olcott wrote:
>>>>>>>>>> On 8/28/2022 10:01 PM, Richard Damon wrote:
>>>>>>>>>>> On 8/28/22 10:47 PM, olcott wrote:
>>>>>>>>>>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>>>>>>>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>>>>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>>>>>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Since Turing machines are mathematical objects that
>>>>>>>>>>>>>>>>>>>> only exist in the
>>>>>>>>>>>>>>>>>>>> mind people can have contradictory thus incoherent
>>>>>>>>>>>>>>>>>>>> ideas about these
>>>>>>>>>>>>>>>>>>>> abstract mathematical objects and never realize that
>>>>>>>>>>>>>>>>>>>> their ideas are
>>>>>>>>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> When we study the theory of computation using
>>>>>>>>>>>>>>>>>>>> physically existing
>>>>>>>>>>>>>>>>>>>> machines such as the x86 architecture then the
>>>>>>>>>>>>>>>>>>>> incoherent abstract
>>>>>>>>>>>>>>>>>>>> ideas are shown to be incoherent in that they cannot
>>>>>>>>>>>>>>>>>>>> be physically
>>>>>>>>>>>>>>>>>>>> implemented.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If a decider must always return a value whenever it
>>>>>>>>>>>>>>>>>>>> is called this
>>>>>>>>>>>>>>>>>>>> requires H to return a value to Px even though H is
>>>>>>>>>>>>>>>>>>>> called in
>>>>>>>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This even requires that the function call from Px to
>>>>>>>>>>>>>>>>>>>> H(Px,Px) must
>>>>>>>>>>>>>>>>>>>> return a value to Px even if this function call to H
>>>>>>>>>>>>>>>>>>>> is not even
>>>>>>>>>>>>>>>>>>>> executed. In the physical model of computation it is
>>>>>>>>>>>>>>>>>>>> an axiom the
>>>>>>>>>>>>>>>>>>>> programs that are not executed never return values
>>>>>>>>>>>>>>>>>>>> because it is
>>>>>>>>>>>>>>>>>>>> physically impossible.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> When simulating halt decider H sees that Px is about
>>>>>>>>>>>>>>>>>>>> to call H(Px,Px)
>>>>>>>>>>>>>>>>>>>> in infinite recursion H aborts its simulation of Px
>>>>>>>>>>>>>>>>>>>> before this call
>>>>>>>>>>>>>>>>>>>> is executed.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>>>>>>>>>>>> Computer science says that H must still return a
>>>>>>>>>>>>>>>>>>>> value to Px even
>>>>>>>>>>>>>>>>>>>> though the call to H is not even executed because
>>>>>>>>>>>>>>>>>>>> all deciders must
>>>>>>>>>>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Computer science is correct on this point, what is
>>>>>>>>>>>>>>>>>>> incorrect is your
>>>>>>>>>>>>>>>>>>> implementation of H.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So you are saying the a computer program that is never
>>>>>>>>>>>>>>>>>> even executed
>>>>>>>>>>>>>>>>>> must still return a result?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>>>>>>>>>>> This is equivalent of treating non-termination as an
>>>>>>>>>>>>>>>>> effect.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No problem - is just a definition.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H(Px,Px) returns 0 to main. Some people have said that
>>>>>>>>>>>>>>>> the when Px calls H(Px,Px) that H must return a value to
>>>>>>>>>>>>>>>> Px even though this function call from Px to H is never
>>>>>>>>>>>>>>>> executed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the call
>>>>>>>>>>>>>>> IS executed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the
>>>>>>>>>>>>>>> behavior that H determines.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You said that H must always return a result to its caller
>>>>>>>>>>>>>> even if this call is never actually executed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You don't HAVE a caller unless you execute the call
>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>
>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>
>>>>>>>>>>> I DIDN'T. I don't think you know what a subject is.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> A decider must always return to its caller:
>>>>>>>>>>>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY
>>>>>>>>>>>> EXECUTED*
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, you don't think that Px calls H?
>>>>>>>>>>
>>>>>>>>>> The call to H(Px,Px) from P is never executed, thus H need not
>>>>>>>>>> return to Px.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But it is in the complete simulation of the input to H(Px,Px),
>>>>>>>>> and that is what matters for the answer that H is supposed to
>>>>>>>>> give.
>>>>>>>>>
>>>>>>>>
>>>>>>>> *This thread had nothing to do with that*
>>>>>>>> The question is whether or not H must return a value to Px when
>>>>>>>> the call to H(Px,Px) from Px is never invoked.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Which is a meaningless question except in the context of a
>>>>>>> complete simulation/execution.
>>>>>> Does the fact that the invocation of H(Px,Px) from Px that is
>>>>>> never executed prevent H from being a decider?
>>>>>
>>>>> What do you meen it never "gets executed"?
>>>>>
>>>>
>>>> H(Px,Px) cannot return any value to the correctly simulated Px
>>>> because the correctly simulated Px is aborted before its call to
>>>> H(Px,Px) is executed.
>>>
>>> Nope. because the actual behavior of Px is to directly call H(Px,Px)
>>>
>>
>> There is no actual behavior of Px such that H can possibly return any
>> value to its simulated Px.
>>
>>
> Your being illogical again.
>

On 8/29/22 10:39 PM, olcott wrote:
> On 8/29/2022 9:32 PM, Richard Damon wrote:
>>
>> On 8/29/22 10:16 PM, olcott wrote:
>>> On 8/29/2022 8:50 PM, Richard Damon wrote:
>>>> On 8/29/22 9:05 PM, olcott wrote:
>>>>> On 8/29/2022 7:50 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 8/29/22 7:28 PM, olcott wrote:
>>>>>>> On 8/29/2022 6:18 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 8/29/22 1:12 PM, olcott wrote:
>>>>>>>>> On 8/28/2022 10:18 PM, Richard Damon wrote:
>>>>>>>>>> On 8/28/22 11:15 PM, olcott wrote:
>>>>>>>>>>> On 8/28/2022 10:01 PM, Richard Damon wrote:
>>>>>>>>>>>> On 8/28/22 10:47 PM, olcott wrote:
>>>>>>>>>>>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>>>>>>>>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>>>>>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Since Turing machines are mathematical objects that
>>>>>>>>>>>>>>>>>>>>> only exist in the
>>>>>>>>>>>>>>>>>>>>> mind people can have contradictory thus incoherent
>>>>>>>>>>>>>>>>>>>>> ideas about these
>>>>>>>>>>>>>>>>>>>>> abstract mathematical objects and never realize
>>>>>>>>>>>>>>>>>>>>> that their ideas are
>>>>>>>>>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> When we study the theory of computation using
>>>>>>>>>>>>>>>>>>>>> physically existing
>>>>>>>>>>>>>>>>>>>>> machines such as the x86 architecture then the
>>>>>>>>>>>>>>>>>>>>> incoherent abstract
>>>>>>>>>>>>>>>>>>>>> ideas are shown to be incoherent in that they
>>>>>>>>>>>>>>>>>>>>> cannot be physically
>>>>>>>>>>>>>>>>>>>>> implemented.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If a decider must always return a value whenever it
>>>>>>>>>>>>>>>>>>>>> is called this
>>>>>>>>>>>>>>>>>>>>> requires H to return a value to Px even though H is
>>>>>>>>>>>>>>>>>>>>> called in
>>>>>>>>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> This even requires that the function call from Px
>>>>>>>>>>>>>>>>>>>>> to H(Px,Px) must
>>>>>>>>>>>>>>>>>>>>> return a value to Px even if this function call to
>>>>>>>>>>>>>>>>>>>>> H is not even
>>>>>>>>>>>>>>>>>>>>> executed. In the physical model of computation it
>>>>>>>>>>>>>>>>>>>>> is an axiom the
>>>>>>>>>>>>>>>>>>>>> programs that are not executed never return values
>>>>>>>>>>>>>>>>>>>>> because it is
>>>>>>>>>>>>>>>>>>>>> physically impossible.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> When simulating halt decider H sees that Px is
>>>>>>>>>>>>>>>>>>>>> about to call H(Px,Px)
>>>>>>>>>>>>>>>>>>>>> in infinite recursion H aborts its simulation of Px
>>>>>>>>>>>>>>>>>>>>> before this call
>>>>>>>>>>>>>>>>>>>>> is executed.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>>>>>>>>>>>>> Computer science says that H must still return a
>>>>>>>>>>>>>>>>>>>>> value to Px even
>>>>>>>>>>>>>>>>>>>>> though the call to H is not even executed because
>>>>>>>>>>>>>>>>>>>>> all deciders must
>>>>>>>>>>>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Computer science is correct on this point, what is
>>>>>>>>>>>>>>>>>>>> incorrect is your
>>>>>>>>>>>>>>>>>>>> implementation of H.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So you are saying the a computer program that is
>>>>>>>>>>>>>>>>>>> never even executed
>>>>>>>>>>>>>>>>>>> must still return a result?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>>>>>>>>>>>> This is equivalent of treating non-termination as an
>>>>>>>>>>>>>>>>>> effect.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No problem - is just a definition.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H(Px,Px) returns 0 to main. Some people have said that
>>>>>>>>>>>>>>>>> the when Px calls H(Px,Px) that H must return a value
>>>>>>>>>>>>>>>>> to Px even though this function call from Px to H is
>>>>>>>>>>>>>>>>> never executed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the
>>>>>>>>>>>>>>>> call IS executed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the
>>>>>>>>>>>>>>>> behavior that H determines.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You said that H must always return a result to its caller
>>>>>>>>>>>>>>> even if this call is never actually executed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You don't HAVE a caller unless you execute the call
>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>
>>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>>
>>>>>>>>>>>> I DIDN'T. I don't think you know what a subject is.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> A decider must always return to its caller:
>>>>>>>>>>>>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY
>>>>>>>>>>>>> EXECUTED*
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So, you don't think that Px calls H?
>>>>>>>>>>>
>>>>>>>>>>> The call to H(Px,Px) from P is never executed, thus H need
>>>>>>>>>>> not return to Px.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> But it is in the complete simulation of the input to H(Px,Px),
>>>>>>>>>> and that is what matters for the answer that H is supposed to
>>>>>>>>>> give.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *This thread had nothing to do with that*
>>>>>>>>> The question is whether or not H must return a value to Px when
>>>>>>>>> the call to H(Px,Px) from Px is never invoked.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Which is a meaningless question except in the context of a
>>>>>>>> complete simulation/execution.
>>>>>>> Does the fact that the invocation of H(Px,Px) from Px that is
>>>>>>> never executed prevent H from being a decider?
>>>>>>
>>>>>> What do you meen it never "gets executed"?
>>>>>>
>>>>>
>>>>> H(Px,Px) cannot return any value to the correctly simulated Px
>>>>> because the correctly simulated Px is aborted before its call to
>>>>> H(Px,Px) is executed.
>>>>
>>>> Nope. because the actual behavior of Px is to directly call H(Px,Px)
>>>>
>>>
>>> There is no actual behavior of Px such that H can possibly return any
>>> value to its simulated Px.
>>>
>>>
>> Your being illogical again.
>>
>
> Ah so you admit that you lied when you said that H(Px,Px) eventually
> returns a value to its simulated input.
>

On 8/29/2022 10:13 PM, Richard Damon wrote:
> On 8/29/22 10:39 PM, olcott wrote:
>> On 8/29/2022 9:32 PM, Richard Damon wrote:
>>>
>>> On 8/29/22 10:16 PM, olcott wrote:
>>>> On 8/29/2022 8:50 PM, Richard Damon wrote:
>>>>> On 8/29/22 9:05 PM, olcott wrote:
>>>>>> On 8/29/2022 7:50 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 8/29/22 7:28 PM, olcott wrote:
>>>>>>>> On 8/29/2022 6:18 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 8/29/22 1:12 PM, olcott wrote:
>>>>>>>>>> On 8/28/2022 10:18 PM, Richard Damon wrote:
>>>>>>>>>>> On 8/28/22 11:15 PM, olcott wrote:
>>>>>>>>>>>> On 8/28/2022 10:01 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 8/28/22 10:47 PM, olcott wrote:
>>>>>>>>>>>>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>>>>>>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Since Turing machines are mathematical objects
>>>>>>>>>>>>>>>>>>>>>> that only exist in the
>>>>>>>>>>>>>>>>>>>>>> mind people can have contradictory thus incoherent
>>>>>>>>>>>>>>>>>>>>>> ideas about these
>>>>>>>>>>>>>>>>>>>>>> abstract mathematical objects and never realize
>>>>>>>>>>>>>>>>>>>>>> that their ideas are
>>>>>>>>>>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> When we study the theory of computation using
>>>>>>>>>>>>>>>>>>>>>> physically existing
>>>>>>>>>>>>>>>>>>>>>> machines such as the x86 architecture then the
>>>>>>>>>>>>>>>>>>>>>> incoherent abstract
>>>>>>>>>>>>>>>>>>>>>> ideas are shown to be incoherent in that they
>>>>>>>>>>>>>>>>>>>>>> cannot be physically
>>>>>>>>>>>>>>>>>>>>>> implemented.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If a decider must always return a value whenever
>>>>>>>>>>>>>>>>>>>>>> it is called this
>>>>>>>>>>>>>>>>>>>>>> requires H to return a value to Px even though H
>>>>>>>>>>>>>>>>>>>>>> is called in
>>>>>>>>>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> This even requires that the function call from Px
>>>>>>>>>>>>>>>>>>>>>> to H(Px,Px) must
>>>>>>>>>>>>>>>>>>>>>> return a value to Px even if this function call to
>>>>>>>>>>>>>>>>>>>>>> H is not even
>>>>>>>>>>>>>>>>>>>>>> executed. In the physical model of computation it
>>>>>>>>>>>>>>>>>>>>>> is an axiom the
>>>>>>>>>>>>>>>>>>>>>> programs that are not executed never return values
>>>>>>>>>>>>>>>>>>>>>> because it is
>>>>>>>>>>>>>>>>>>>>>> physically impossible.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> When simulating halt decider H sees that Px is
>>>>>>>>>>>>>>>>>>>>>> about to call H(Px,Px)
>>>>>>>>>>>>>>>>>>>>>> in infinite recursion H aborts its simulation of
>>>>>>>>>>>>>>>>>>>>>> Px before this call
>>>>>>>>>>>>>>>>>>>>>> is executed.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>>>>>>>>>>>>>> Computer science says that H must still return a
>>>>>>>>>>>>>>>>>>>>>> value to Px even
>>>>>>>>>>>>>>>>>>>>>> though the call to H is not even executed because
>>>>>>>>>>>>>>>>>>>>>> all deciders must
>>>>>>>>>>>>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Computer science is correct on this point, what is
>>>>>>>>>>>>>>>>>>>>> incorrect is your
>>>>>>>>>>>>>>>>>>>>> implementation of H.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So you are saying the a computer program that is
>>>>>>>>>>>>>>>>>>>> never even executed
>>>>>>>>>>>>>>>>>>>> must still return a result?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>>>>>>>>>>>>> This is equivalent of treating non-termination as an
>>>>>>>>>>>>>>>>>>> effect.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No problem - is just a definition.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H(Px,Px) returns 0 to main. Some people have said that
>>>>>>>>>>>>>>>>>> the when Px calls H(Px,Px) that H must return a value
>>>>>>>>>>>>>>>>>> to Px even though this function call from Px to H is
>>>>>>>>>>>>>>>>>> never executed.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the
>>>>>>>>>>>>>>>>> call IS executed.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the
>>>>>>>>>>>>>>>>> behavior that H determines.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You said that H must always return a result to its
>>>>>>>>>>>>>>>> caller even if this call is never actually executed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You don't HAVE a caller unless you execute the call
>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>>>
>>>>>>>>>>>>> I DIDN'T. I don't think you know what a subject is.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A decider must always return to its caller:
>>>>>>>>>>>>>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS
>>>>>>>>>>>>>> ACTUALLY EXECUTED*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, you don't think that Px calls H?
>>>>>>>>>>>>
>>>>>>>>>>>> The call to H(Px,Px) from P is never executed, thus H need
>>>>>>>>>>>> not return to Px.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> But it is in the complete simulation of the input to
>>>>>>>>>>> H(Px,Px), and that is what matters for the answer that H is
>>>>>>>>>>> supposed to give.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *This thread had nothing to do with that*
>>>>>>>>>> The question is whether or not H must return a value to Px
>>>>>>>>>> when the call to H(Px,Px) from Px is never invoked.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Which is a meaningless question except in the context of a
>>>>>>>>> complete simulation/execution.
>>>>>>>> Does the fact that the invocation of H(Px,Px) from Px that is
>>>>>>>> never executed prevent H from being a decider?
>>>>>>>
>>>>>>> What do you meen it never "gets executed"?
>>>>>>>
>>>>>>
>>>>>> H(Px,Px) cannot return any value to the correctly simulated Px
>>>>>> because the correctly simulated Px is aborted before its call to
>>>>>> H(Px,Px) is executed.
>>>>>
>>>>> Nope. because the actual behavior of Px is to directly call H(Px,Px)
>>>>>
>>>>
>>>> There is no actual behavior of Px such that H can possibly return
>>>> any value to its simulated Px.
>>>>
>>>>
>>> Your being illogical again.
>>>
>>
>> Ah so you admit that you lied when you said that H(Px,Px) eventually
>> returns a value to its simulated input.
>>
>
> No, I didn't say that, I said every call to H(Px,Px) needs to see the 0
> returned.
>
> I said NOTHING about "to its simulated input" because that is just
> non-sense.

On 8/29/22 11:27 PM, olcott wrote:
> On 8/29/2022 10:13 PM, Richard Damon wrote:
>> On 8/29/22 10:39 PM, olcott wrote:
>>> On 8/29/2022 9:32 PM, Richard Damon wrote:
>>>>
>>>> On 8/29/22 10:16 PM, olcott wrote:
>>>>> On 8/29/2022 8:50 PM, Richard Damon wrote:
>>>>>> On 8/29/22 9:05 PM, olcott wrote:
>>>>>>> On 8/29/2022 7:50 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 8/29/22 7:28 PM, olcott wrote:
>>>>>>>>> On 8/29/2022 6:18 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 8/29/22 1:12 PM, olcott wrote:
>>>>>>>>>>> On 8/28/2022 10:18 PM, Richard Damon wrote:
>>>>>>>>>>>> On 8/28/22 11:15 PM, olcott wrote:
>>>>>>>>>>>>> On 8/28/2022 10:01 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 8/28/22 10:47 PM, olcott wrote:
>>>>>>>>>>>>>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>>>>>>>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Since Turing machines are mathematical objects
>>>>>>>>>>>>>>>>>>>>>>> that only exist in the
>>>>>>>>>>>>>>>>>>>>>>> mind people can have contradictory thus
>>>>>>>>>>>>>>>>>>>>>>> incoherent ideas about these
>>>>>>>>>>>>>>>>>>>>>>> abstract mathematical objects and never realize
>>>>>>>>>>>>>>>>>>>>>>> that their ideas are
>>>>>>>>>>>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> When we study the theory of computation using
>>>>>>>>>>>>>>>>>>>>>>> physically existing
>>>>>>>>>>>>>>>>>>>>>>> machines such as the x86 architecture then the
>>>>>>>>>>>>>>>>>>>>>>> incoherent abstract
>>>>>>>>>>>>>>>>>>>>>>> ideas are shown to be incoherent in that they
>>>>>>>>>>>>>>>>>>>>>>> cannot be physically
>>>>>>>>>>>>>>>>>>>>>>> implemented.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If a decider must always return a value whenever
>>>>>>>>>>>>>>>>>>>>>>> it is called this
>>>>>>>>>>>>>>>>>>>>>>> requires H to return a value to Px even though H
>>>>>>>>>>>>>>>>>>>>>>> is called in
>>>>>>>>>>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> This even requires that the function call from Px
>>>>>>>>>>>>>>>>>>>>>>> to H(Px,Px) must
>>>>>>>>>>>>>>>>>>>>>>> return a value to Px even if this function call
>>>>>>>>>>>>>>>>>>>>>>> to H is not even
>>>>>>>>>>>>>>>>>>>>>>> executed. In the physical model of computation it
>>>>>>>>>>>>>>>>>>>>>>> is an axiom the
>>>>>>>>>>>>>>>>>>>>>>> programs that are not executed never return
>>>>>>>>>>>>>>>>>>>>>>> values because it is
>>>>>>>>>>>>>>>>>>>>>>> physically impossible.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> When simulating halt decider H sees that Px is
>>>>>>>>>>>>>>>>>>>>>>> about to call H(Px,Px)
>>>>>>>>>>>>>>>>>>>>>>> in infinite recursion H aborts its simulation of
>>>>>>>>>>>>>>>>>>>>>>> Px before this call
>>>>>>>>>>>>>>>>>>>>>>> is executed.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> *Clearly computer science is incorrect on this
>>>>>>>>>>>>>>>>>>>>>>> point*
>>>>>>>>>>>>>>>>>>>>>>> Computer science says that H must still return a
>>>>>>>>>>>>>>>>>>>>>>> value to Px even
>>>>>>>>>>>>>>>>>>>>>>> though the call to H is not even executed because
>>>>>>>>>>>>>>>>>>>>>>> all deciders must
>>>>>>>>>>>>>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Computer science is correct on this point, what is
>>>>>>>>>>>>>>>>>>>>>> incorrect is your
>>>>>>>>>>>>>>>>>>>>>> implementation of H.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> So you are saying the a computer program that is
>>>>>>>>>>>>>>>>>>>>> never even executed
>>>>>>>>>>>>>>>>>>>>> must still return a result?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>>>>>>>>>>>>>> This is equivalent of treating non-termination as an
>>>>>>>>>>>>>>>>>>>> effect.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No problem - is just a definition.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> H(Px,Px) returns 0 to main. Some people have said
>>>>>>>>>>>>>>>>>>> that the when Px calls H(Px,Px) that H must return a
>>>>>>>>>>>>>>>>>>> value to Px even though this function call from Px to
>>>>>>>>>>>>>>>>>>> H is never executed.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the
>>>>>>>>>>>>>>>>>> call IS executed.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the
>>>>>>>>>>>>>>>>>> behavior that H determines.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You said that H must always return a result to its
>>>>>>>>>>>>>>>>> caller even if this call is never actually executed.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You don't HAVE a caller unless you execute the call
>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I DIDN'T. I don't think you know what a subject is.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A decider must always return to its caller:
>>>>>>>>>>>>>>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS
>>>>>>>>>>>>>>> ACTUALLY EXECUTED*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, you don't think that Px calls H?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The call to H(Px,Px) from P is never executed, thus H need
>>>>>>>>>>>>> not return to Px.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> But it is in the complete simulation of the input to
>>>>>>>>>>>> H(Px,Px), and that is what matters for the answer that H is
>>>>>>>>>>>> supposed to give.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *This thread had nothing to do with that*
>>>>>>>>>>> The question is whether or not H must return a value to Px
>>>>>>>>>>> when the call to H(Px,Px) from Px is never invoked.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Which is a meaningless question except in the context of a
>>>>>>>>>> complete simulation/execution.
>>>>>>>>> Does the fact that the invocation of H(Px,Px) from Px that is
>>>>>>>>> never executed prevent H from being a decider?
>>>>>>>>
>>>>>>>> What do you meen it never "gets executed"?
>>>>>>>>
>>>>>>>
>>>>>>> H(Px,Px) cannot return any value to the correctly simulated Px
>>>>>>> because the correctly simulated Px is aborted before its call to
>>>>>>> H(Px,Px) is executed.
>>>>>>
>>>>>> Nope. because the actual behavior of Px is to directly call H(Px,Px)
>>>>>>
>>>>>
>>>>> There is no actual behavior of Px such that H can possibly return
>>>>> any value to its simulated Px.
>>>>>
>>>>>
>>>> Your being illogical again.
>>>>
>>>
>>> Ah so you admit that you lied when you said that H(Px,Px) eventually
>>> returns a value to its simulated input.
>>>
>>
>> No, I didn't say that, I said every call to H(Px,Px) needs to see the
>> 0 returned.
>>
>> I said NOTHING about "to its simulated input" because that is just
>> non-sense.
>
> On 8/28/2022 7:02 PM, Richard Damon wrote:
> > Yes, the COMPLETE simulation of the input will see
> > that call and return, yes. If it saw the Call, it
> > will see the Return.
>
> This was in the context of a simulated P returning to its simulated H.
>

On 8/29/2022 10:44 PM, Richard Damon wrote:
>
> On 8/29/22 11:27 PM, olcott wrote:
>> On 8/29/2022 10:13 PM, Richard Damon wrote:
>>> On 8/29/22 10:39 PM, olcott wrote:
>>>> On 8/29/2022 9:32 PM, Richard Damon wrote:
>>>>>
>>>>> On 8/29/22 10:16 PM, olcott wrote:
>>>>>> On 8/29/2022 8:50 PM, Richard Damon wrote:
>>>>>>> On 8/29/22 9:05 PM, olcott wrote:
>>>>>>>> On 8/29/2022 7:50 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 8/29/22 7:28 PM, olcott wrote:
>>>>>>>>>> On 8/29/2022 6:18 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 8/29/22 1:12 PM, olcott wrote:
>>>>>>>>>>>> On 8/28/2022 10:18 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 8/28/22 11:15 PM, olcott wrote:
>>>>>>>>>>>>>> On 8/28/2022 10:01 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 8/28/22 10:47 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>>>>>>>>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Since Turing machines are mathematical objects
>>>>>>>>>>>>>>>>>>>>>>>> that only exist in the
>>>>>>>>>>>>>>>>>>>>>>>> mind people can have contradictory thus
>>>>>>>>>>>>>>>>>>>>>>>> incoherent ideas about these
>>>>>>>>>>>>>>>>>>>>>>>> abstract mathematical objects and never realize
>>>>>>>>>>>>>>>>>>>>>>>> that their ideas are
>>>>>>>>>>>>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> When we study the theory of computation using
>>>>>>>>>>>>>>>>>>>>>>>> physically existing
>>>>>>>>>>>>>>>>>>>>>>>> machines such as the x86 architecture then the
>>>>>>>>>>>>>>>>>>>>>>>> incoherent abstract
>>>>>>>>>>>>>>>>>>>>>>>> ideas are shown to be incoherent in that they
>>>>>>>>>>>>>>>>>>>>>>>> cannot be physically
>>>>>>>>>>>>>>>>>>>>>>>> implemented.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> If a decider must always return a value whenever
>>>>>>>>>>>>>>>>>>>>>>>> it is called this
>>>>>>>>>>>>>>>>>>>>>>>> requires H to return a value to Px even though H
>>>>>>>>>>>>>>>>>>>>>>>> is called in
>>>>>>>>>>>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> This even requires that the function call from
>>>>>>>>>>>>>>>>>>>>>>>> Px to H(Px,Px) must
>>>>>>>>>>>>>>>>>>>>>>>> return a value to Px even if this function call
>>>>>>>>>>>>>>>>>>>>>>>> to H is not even
>>>>>>>>>>>>>>>>>>>>>>>> executed. In the physical model of computation
>>>>>>>>>>>>>>>>>>>>>>>> it is an axiom the
>>>>>>>>>>>>>>>>>>>>>>>> programs that are not executed never return
>>>>>>>>>>>>>>>>>>>>>>>> values because it is
>>>>>>>>>>>>>>>>>>>>>>>> physically impossible.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> When simulating halt decider H sees that Px is
>>>>>>>>>>>>>>>>>>>>>>>> about to call H(Px,Px)
>>>>>>>>>>>>>>>>>>>>>>>> in infinite recursion H aborts its simulation of
>>>>>>>>>>>>>>>>>>>>>>>> Px before this call
>>>>>>>>>>>>>>>>>>>>>>>> is executed.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> *Clearly computer science is incorrect on this
>>>>>>>>>>>>>>>>>>>>>>>> point*
>>>>>>>>>>>>>>>>>>>>>>>> Computer science says that H must still return a
>>>>>>>>>>>>>>>>>>>>>>>> value to Px even
>>>>>>>>>>>>>>>>>>>>>>>> though the call to H is not even executed
>>>>>>>>>>>>>>>>>>>>>>>> because all deciders must
>>>>>>>>>>>>>>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Computer science is correct on this point, what
>>>>>>>>>>>>>>>>>>>>>>> is incorrect is your
>>>>>>>>>>>>>>>>>>>>>>> implementation of H.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So you are saying the a computer program that is
>>>>>>>>>>>>>>>>>>>>>> never even executed
>>>>>>>>>>>>>>>>>>>>>> must still return a result?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>>>>>>>>>>>>>>> This is equivalent of treating non-termination as
>>>>>>>>>>>>>>>>>>>>> an effect.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No problem - is just a definition.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H(Px,Px) returns 0 to main. Some people have said
>>>>>>>>>>>>>>>>>>>> that the when Px calls H(Px,Px) that H must return a
>>>>>>>>>>>>>>>>>>>> value to Px even though this function call from Px
>>>>>>>>>>>>>>>>>>>> to H is never executed.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the
>>>>>>>>>>>>>>>>>>> call IS executed.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the
>>>>>>>>>>>>>>>>>>> behavior that H determines.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You said that H must always return a result to its
>>>>>>>>>>>>>>>>>> caller even if this call is never actually executed.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You don't HAVE a caller unless you execute the call
>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>>>>>> DON'T CHANGE THE SUBJECT
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I DIDN'T. I don't think you know what a subject is.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A decider must always return to its caller:
>>>>>>>>>>>>>>>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS
>>>>>>>>>>>>>>>> ACTUALLY EXECUTED*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, you don't think that Px calls H?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The call to H(Px,Px) from P is never executed, thus H need
>>>>>>>>>>>>>> not return to Px.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> But it is in the complete simulation of the input to
>>>>>>>>>>>>> H(Px,Px), and that is what matters for the answer that H is
>>>>>>>>>>>>> supposed to give.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *This thread had nothing to do with that*
>>>>>>>>>>>> The question is whether or not H must return a value to Px
>>>>>>>>>>>> when the call to H(Px,Px) from Px is never invoked.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Which is a meaningless question except in the context of a
>>>>>>>>>>> complete simulation/execution.
>>>>>>>>>> Does the fact that the invocation of H(Px,Px) from Px that is
>>>>>>>>>> never executed prevent H from being a decider?
>>>>>>>>>
>>>>>>>>> What do you meen it never "gets executed"?
>>>>>>>>>
>>>>>>>>
>>>>>>>> H(Px,Px) cannot return any value to the correctly simulated Px
>>>>>>>> because the correctly simulated Px is aborted before its call to
>>>>>>>> H(Px,Px) is executed.
>>>>>>>
>>>>>>> Nope. because the actual behavior of Px is to directly call H(Px,Px)
>>>>>>>
>>>>>>
>>>>>> There is no actual behavior of Px such that H can possibly return
>>>>>> any value to its simulated Px.
>>>>>>
>>>>>>
>>>>> Your being illogical again.
>>>>>
>>>>
>>>> Ah so you admit that you lied when you said that H(Px,Px) eventually
>>>> returns a value to its simulated input.
>>>>
>>>
>>> No, I didn't say that, I said every call to H(Px,Px) needs to see the
>>> 0 returned.
>>>
>>> I said NOTHING about "to its simulated input" because that is just
>>> non-sense.
>>
>> On 8/28/2022 7:02 PM, Richard Damon wrote:
>>  > Yes, the COMPLETE simulation of the input will see
>>  > that call and return, yes. If it saw the Call, it
>>  > will see the Return.
>>
>> This was in the context of a simulated P returning to its simulated H.
>>
>
> And what did I say?
>
> The COMPLETE simulation will see the call and return.
>