On 8/17/2021 4:01 PM, wij wrote:
> On Wednesday, 18 August 2021 at 05:00:44 UTC+8, olcott wrote:
>> On 8/17/2021 12:35 AM, wij wrote:
>>> On Tuesday, 17 August 2021 at 06:58:05 UTC+8, olcott wrote:
>>>> On 8/16/2021 1:27 AM, wij wrote:
>>>>> On Monday, 16 August 2021 at 00:44:43 UTC+8, olcott wrote:
>>>>>> On 8/15/2021 9:45 AM, wij wrote:
>>>>>>> On Sunday, 15 August 2021 at 21:45:09 UTC+8, olcott wrote:
>>>>>>>> On 8/15/2021 2:50 AM, wij wrote:
>>>>>>>>> On Sunday, 15 August 2021 at 02:24:42 UTC+8, olcott wrote:
>>>>>>>>>> On 8/14/2021 1:09 PM, wij wrote:
>>>>>>>>>>> On Sunday, 15 August 2021 at 01:22:11 UTC+8, olcott wrote:
>>>>>>>>>>>> On 8/14/2021 11:35 AM, wij wrote:
>>>>>>>>>>>>> On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
>>>>>>>>>>>>>> On 8/14/2021 11:05 AM, wij wrote:
>>>>>>>>>>>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>>>>>>>>>>>>> This exact same analysis always applies to the input to H(P,P) no matter
>>>>>>>>>>>>>>>> how it is called including this example:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> P((u32)P);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> the Turing machine halting problem. Simply stated, the problem
>>>>>>>>>>>>>>>> is: given the description of a Turing machine M and an input w,
>>>>>>>>>>>>>>>> does M, when started in the initial configuration q0w, perform a
>>>>>>>>>>>>>>>> computation that eventually halts? (Linz:1990:317).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>>>>>>>>> determining, from a description of an arbitrary computer program
>>>>>>>>>>>>>>>> and an input, whether the program will finish running, or continue
>>>>>>>>>>>>>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because the halting problem only requires that the (at least partial)
>>>>>>>>>>>>>>>> halt decider decide its input correctly the fact that the direct
>>>>>>>>>>>>>>>> invocation of P(P) is not an input to H, means that it is not relevant
>>>>>>>>>>>>>>>> to the halting problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I do not know English well, but I (almost every programmer) am sure the halting
>>>>>>>>>>>>>>> problem means a program H decides whether P(input) will halt or not.
>>>>>>>>>>>>>>> If the quoted texts is read to you differently, it is the problem of that texts.
>>>>>>>>>>>>>>> Submit message to the authors.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The quoted texts are accurate. The (at least partial) halt decider must
>>>>>>>>>>>>>> only correctly decide the halt status of its input. Computations that
>>>>>>>>>>>>>> are not inputs to the halt decider do not pertain to the halting problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Obviously the quoted text means differently to you and almost all programmers in
>>>>>>>>>>>>> the world. You are addressing your own interpretation. This is OK, but the
>>>>>>>>>>>>> interpretation is meaningless.
>>>>>>>>>>>> "the description of a Turing machine M" does not mean Turing machine M.
>>>>>>>>>>>> If people interpret this to mean Turing machine M they are wrong.
>>>>>>>>>>>
>>>>>>>>>>> Then, both Linz and the author of https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>> are also wrong, I and almost all programmers in the world can guarantee you this.
>>>>>>>>>>>
>>>>>>>>>>> If both authors are also wrong, replying the rest message is meaningless.
>>>>>>>>>>> You need to submit your interpretation to Linz and the author of the wiki.
>>>>>>>>>>>
>>>>>>>>>> I think that the problem is that your English is not so good.
>>>>>>>>>> The Linz text and the Wiki text are correct.
>>>>>>>>>> Linz retired many years ago.
>>>>>>>>>
>>>>>>>>> In your recent post somewhere, you said:
>>>>>>>>> "I made my refutation of Linz a little more clear by changing all of the
>>>>>>>>> subscripts to be numeric. My refutation of Linz cannot be properly
>>>>>>>>> understood until after my refutation of simplified Linz / Strachey is
>>>>>>>>> first understood..."
>>>>>>>>> Now, you changed mind to say "The Linz text and the Wiki text are correct."
>>>>>>>>>
>>>>>>>> This text right here is correct:
>>>>>>>> the Turing machine halting problem. Simply stated, the problem
>>>>>>>> is: given the description of a Turing machine M and an input w,
>>>>>>>> does M, when started in the initial configuration q0w, perform a
>>>>>>>> computation that eventually halts? (Linz:1990:317).
>>>>>>>>
>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>> determining, from a description of an arbitrary computer program
>>>>>>>> and an input, whether the program will finish running, or continue
>>>>>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>> All of the rest of the text that "proves" the halting problem cannot be
>>>>>>>> solved it incorrect.
>>>>>>>
>>>>>>> Which one did you mean:
>>>>>>> 1. All of the rest of the text that "proves" the halting problem cannot be
>>>>>>> solved incorrect. (still ambiguous)
>>>>>>> 2. All of the rest of the text that "proves" the halting problem cannot
>>>>>>> solve incorrect. (ambiguous)
>>>>>>> 3. All of the rest of the text that "proves" the halting problem cannot be
>>>>>>> solved, it is incorrect.
>>>>>>>
>>>>>>
>>>>>> All of the rest of the text that "proves" the halting problem cannot be
>>>>>> solved <IS> incorrect.
>>>>>>>>> There are much more inconsistent statements in your posts, like "H is a total
>>>>>>>>> function",...,etc. (I do not have time to re-find them).
>>>>>>>>>
>>>>>>>> H is a pure function of its inputs in that all of the nested simulations
>>>>>>>> are simply data derived entirely on the basis of this inputs.
>>>>>>>
>>>>>>> From your description:
>>>>>>> "The x86utm operating system uses a single contiguous block of RAM to
>>>>>>> most precisely map to the concept of a single contiguous Turing machine
>>>>>>> tape. All of the code and data of the virtual machines that it executes
>>>>>>> are contained in this single contiguous block. There is no virtual
>>>>>>> memory paging in the x86utm operating system."
>>>>>>>
>>>>>>> I believe your H is a 'pure function', you are actually dealing with two "C"
>>>>>>> function calls. H is not really a simulator as you keeps calling it so.
>>>>>>> Show me how H(P,P) takes its input P as 'simple data'.
>>>>>>>
>>>>>> The x86utm operating system is build from an x86 emulator capable of
>>>>>> emulating all of the 80386 instructions using 4 GB of RAM.
>>>>>
>>>>> Firstly, 'x86utm operating system'(all from power on) is likely a misleading name .
>>>>> Secondly, if 'x86 emulator' do exist, it is likely a bought commodity, because
>>>>> I do not believe you can build a machine or software capable of emulating ALL of
>>>>> the 80386 instructions. Therefore, I assume all you have is a simulating
>>>>> application.
>>>>>
>>>>>> The following x86utm operating system function calls the x86 emulator to
>>>>>> emulate exactly one instruction of the slave process and then return to
>>>>>> the calling process. It also decodes the slave instruction that was
>>>>>> emulated so that it can be stored in the execution trace.
>>>>>>
>>>>>> u32 DebugStep(Registers* master_state,
>>>>>> Registers* slave_state,
>>>>>> Decoded_Line_Of_Code* decoded) {}
>>>>>
>>>>> The question how H(P,P) treats its argument P,P as data is still not answered.
>>>> The details need not be specified to understand that all the simulations
>>>> of the executed simulator are data belonging to the executed H. Details
>>>> merely provide the means for endless digression away from the key point.
>>>>> E.g. does H contain a call to DebugStep to decode P pointed byte string data?
>>>>> Actually, there are many implementing problems for your simulator H and P to
>>>>> be a valid proof. But, I saw your reply to Mike Terry that you seem to 'realize'
>>>>> the simulation is not necessary for the proof.
>>>>>
>>>> The code does what it specifies that it does that alone is complete
>>>> proof. We can know for sure that H does perform a pure simulation of P
>>>> because the x86 code specified by P is exactly exactly as this code
>>>> specifies.
>>>
>>> What is the 'proof'? What is exactly the 'code'?
>>>
>>> 1. You are not capable of creating a "x86utm operating system".
>>> 2. You are not capable of understanding all 80386 instructions (no even 80186,80286).
>>> 3. You do not even understand C function and TM language properly.
>>> 4. You do not know logic.
>>> 5. You do not have a real H and P.
>>> 6. What you have are brainless talk and lies.
>>>
>>> Tell everyone, which one of the above is false.
>> I take the above as your indication that you intend to only act like a
>> troll and thing else..
>
> I intended to point you to the true thing that you keep blocking yourself.
> So, I put them again in more suspicious/polite way. One reason is that you are
> too cunning in argument.
>
> 1. Did you actually created a "x86utm operating system"? An OS means the software
>  BIOS passes to immediately after power on.
> 2. Do you really understand all 80386 instructions? I remember you said you
> have 'emulated' them. I am sure you are not capable of doing this, but you keep
> questioning people do not understand x86 assembly, thus do not understand your
> proof. Actually, I do not believe you can emulate any of the less powerful x86
> assembly 80286,80186,8086,8088,8048...
> 3. You do not seem to understand C function and TM language properly.
> 4. You do not seem to know the basic Logic.
> 5. You do not have a real H and P that match your description
> 6. What you have are brainless talk and lies. (This is actually your accusation
>   to others.)
>
> Tell everyone, WHICH ONE of the above is false.
> --
> Another hint you missed:
>>> Can God create a stone He cannot lift?
>>> https://en.wikipedia.org/wiki/Omnipotence_paradox
>>>
>> Yes and then after that he can no longer lift this stone.
>
> But you think you can. Do you see the relevance?
>

Can he emulate lock cmpxchg?