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?