On 8/30/22 12:38 AM, olcott wrote:
> On 8/29/2022 11:09 PM, Richard Damon wrote:
>> On 8/29/22 11:52 PM, olcott wrote:
>>> 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.
>>>>
>>>
>>> The complete simulation of the input to H never stops.
>>
>> That isn't the input we were giving to H, so you are just lying
>> because you are caught in the trap you made for yourself.
>>
>
> The input is ALWAYS these machine code bytes:
> 558bec518b4508508b4d0851e82ffdffff83c4088945fc837dfc007402ebfe8be55dc3
>
>
>

Nope, that input doesn't fully define the behavior if you are defining
it as just an x86 machine language representation, as it includes a call
outside the byte stream.

Also, you need to specify the loading address of that byte stream, since
it wasn't generated as position independent code.

If you want that to be the input byte stream, the in addition to the
definition of the input as x86 machine language, you also need to
specify as fixed knowns the loading address and the full contents of the
rest of memory, which means you aren't ALLOWED to change your H to make
the non-aborting version, unless you don't touch the existing version at
the address it was at.

You just don't understand the actual meaning of the words you are claiming.

FAIL.