On Wednesday, 18 August 2021 at 07:09:58 UTC+8, olcott wrote:
> On 8/17/2021 6: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.
> It is stupid to narrowly define an operating system this way.
> > 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...
> I totally understand all of the 80386 instructions that I am discussing,
> I am not emulating them I am calling a function that I wrote that calls
> another 3rd party x86 emulator.

Ok, Q1 might be indirectly answered.

> > 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.)
> >
> You are (as least currently) a mere jackass troll.

Fact: No one (except you) knows whether your H exists or not.
We are not talking about fantasy, do we?

> > 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?
> >
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein