Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.theory,comp.ai.philosophy,comp.ai.nat-lang,sci.lang.semantics Subject: Re: Simply defining =?utf-8?Q?G=C3=B6del?= Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Date: Mon, 10 Aug 2020 10:55:37 -0700 Organization: None to speak of Lines: 248 Message-ID: <87d03y4c86.fsf@nosuchdomain.example.com> References: <877du8fw5d.fsf@bsb.me.uk> <87sgcveqcz.fsf@bsb.me.uk> <87a6z3edvq.fsf@bsb.me.uk> <87d03z5wa0.fsf@nosuchdomain.example.com> <878sen5lij.fsf@nosuchdomain.example.com> <87y2mn417q.fsf@nosuchdomain.example.com> <87tuxb3yng.fsf@nosuchdomain.example.com> <87pn7z3wjg.fsf@nosuchdomain.example.com> <87lfin3uy8.fsf@nosuchdomain.example.com> <9YudnWkJupFsfq3CnZ2dnUU7-K_NnZ2d@giganews.com> <87h7tb3ttk.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="9a8e452c1518fb0522423c029e73ba21"; logging-data="28673"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX191zy26I7KsqVNBgaQTaGoB" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:/28vulMGoTEvIGz0FldrOMqUEGo= sha1:wjajci9kMgxZ475JqseufjY3ogo= Xref: csiph.com comp.theory:22277 comp.ai.philosophy:22309 comp.ai.nat-lang:2640 olcott writes: > On 8/10/2020 1:20 AM, Keith Thompson wrote: >> olcott writes: >>> On 8/10/2020 12:56 AM, Keith Thompson wrote: >>>> olcott writes: >>>>> On 8/10/2020 12:22 AM, Keith Thompson wrote: >>>>>> olcott writes: >>>>>>> On 8/9/2020 11:36 PM, Keith Thompson wrote: >>>>>>>> olcott writes: >>>>>>>>> On 8/9/2020 10:41 PM, Keith Thompson wrote: >>>>>>>>>> olcott writes: >>>>>>>>>>> On 8/9/2020 8:37 PM, Keith Thompson wrote: >>>>>>>>>>>> olcott writes: >>>>>>>>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote: >>>>>>>>>>>>>> olcott writes: >>>>>>>>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>>> You don't have, and have never had, a Turing machine with the properties >>>>>>>>>>>>>>>> you claim. It would be good if you admitted that and moved on because >>>>>>>>>>>>>>>> attempting to defend the indefensible is taking up a lot of your time. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have a finite state machine that implements computationally >>>>>>>>>>>>>>> equivalent code to the Peter Linz H_Hat such that this computational >>>>>>>>>>>>>>> equivalent correctly decides halting on itself showing exactly how the >>>>>>>>>>>>>>> standard self-referential halting problem counter-example can be >>>>>>>>>>>>>>> defeated. >>>>>>>>>>>>>> >>>>>>>>>>>>>> As I recall, you've claimed to have pseudocode that you were going >>>>>>>>>>>>>> to translate into working software. Did you ever actually get it >>>>>>>>>>>>>> written and running? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do you have a finite state machine, or do you merely have an *idea* >>>>>>>>>>>>>> for a finite state machine? >>>>>>>>>>>>> >>>>>>>>>>>>> I translated the finite state equivalent of the same self-referential >>>>>>>>>>>>> counter-example that all the Halting Problem proofs are based on into >>>>>>>>>>>>> "C". I am using a very excellent x86 interpreter to run the machine >>>>>>>>>>>>> code of this "C" function. It turns out that Visual "C++" generates >>>>>>>>>>>>> machine code that is easier to understand than g++. >>>>>>>>>>>> >>>>>>>>>>>> So now you have a "C" function. >>>>>>>>>>>> >>>>>>>>>>>> The quotation marks around C seem odd. Are they significant, and if >>>>>>>>>>>> so, what's the difference between a "C" function and a C function? >>>>>>>>>>>> I presume you're referring to the C programming language. >>>>>>>>>>>> >>>>>>>>>>>> How many lines of C code are in this function? I presume posting >>>>>>>>>>>> that number wouldn't harm its "trade secret" status. (I'm not >>>>>>>>>>>> interested in any answer to this question that isn't a specific >>>>>>>>>>>> positive integer.) >>>>>>>>>>> >>>>>>>>>>> I can't finish the halt decider until its master UTM is complete. >>>>>>>>>>> The details of the greatly enhanced halt decider have been designed >>>>>>>>>>> for many months. >>>>>>>>>>> >>>>>>>>>>>> Does this function conform to the C language standard? Which edition >>>>>>>>>>>> (C90, C99, C11, ...)? >>>>>>>>>>>> >>>>>>>>>>>> Does this "C" function exist in the context of a C program that >>>>>>>>>>>> you can compile, link, and execute? Have you done so? >>>>>>>>>>> >>>>>>>>>>> It can only be correctly executed inside the master UTM and this is >>>>>>>>>>> not quite built yet. >>>>>>>>>>> >>>>>>>>>>>> Why do you need an x86 interpreter to "run the machine code of this >>>>>>>>>>>> "C" function"? Why can't you just compile it with an ordinary C >>>>>>>>>>> >>>>>>>>>>> I need to function to examine its own machine code because the control >>>>>>>>>>> flow of machine code is straight forward. I need an x86 interpreter as >>>>>>>>>>> the basis of the master UTM. >>>>>>>>>>> >>>>>>>>>>>> compiler and execute it? I understand that the goal is to feed >>>>>>>>>>>> your program its own machine code as input (correct?), but are you >>>>>>>>>>>> able to create an executable that can be run with, for example, >>>>>>>>>>>> empty input? (I understand that it might fail with empty input, >>>>>>>>>>>> but the ability to run the program *at all* is a significant step.) >>>>>>>>>>>> >>>>>>>>>>>>> The machine code examines itself and decides halting on itself. >>>>>>>>>>>>> The key part that I have been working on for the last week is building >>>>>>>>>>>>> the context switching aspect of the master UTM such that one UTM can >>>>>>>>>>>>> execute another UTM and this can be to arbitrary depth. I am guessing >>>>>>>>>>>>> that this will be done very soon. Although this is the most difficult >>>>>>>>>>>>> part that remains it is standard operating system software >>>>>>>>>>>>> engineering. >>>>>>>>>>>>> >>>>>>>>>>>>> Converting an x86 interpreter into a UTM that can execute a chain of >>>>>>>>>>>>> UTMs of arbitrary depth has taken most of my time. Half of this time >>>>>>>>>>>>> was learning the internals of the x86 interpreter well enough that I >>>>>>>>>>>>> can make the changes needed. Less that 10% of my time was spent on >>>>>>>>>>>>> anything directly related to halt deciding. >>>>>>>>>> >>>>>>>>>> Nothing you've written actually responds to anything I asked. >>>>>>>>>> >>>>>>>>>> I'll just conclude that you have a vague "design" for some code that >>>>>>>>>> you eventually intend to write, and that you haven't yet written >>>>>>>>>> an actual C function of any kind. >>>>>>>>> >>>>>>>>> If you understand what the x86 language is and you understand what a >>>>>>>>> UTM is then you can put them together and know what I have. If you >>>>>>>>> don't understand what these are then you cannot begin to understand >>>>>>>>> what I have. >>>>>>>> >>>>>>>> Nonsense. >>>>>>> >>>>>>> That is exactly the answer that would be expected from someone that >>>>>>> does not know the underlying subject matter. I have been working with >>>>>>> the x86 language since the early 1980's. This was back when 64K was >>>>>>> the maximum segment size. Boy is it a relief to have 4 GB segments, >>>>>>> switching between 64K segments was so tedious. >>>>>> >>>>>> Resorting to insults means you don't have to explain anything, right? >>>>> >>>>> Merely an objective assessment. >>>> >>>> Whatever. I'm not going to follow that particular digression any further. >>>> >>>>>> I've noticed you tend to do that when someone pushes you to answer a >>>>>> simple question. >>>>>> >>>>>> Here's an easy one. You've used the phrase >>>>>> a "C" function >>>>>> Is there any significant difference in meaning between that and >>>>>> a C function >>>>>> ? >>>>> >>>>> No, it is merely easier to read. >>>> >>>> Great. >>>> >>>> Is there a number of times I have to ask a straightforward question >>>> before you'll answer it? Would it help if I just ask it that >>>> many times in a single post? (This doesn't imply I'd be willing >>>> to do that.) Yes, I'm being a bit sarcastic, but if you'll read >>>> the quoted material in this post, I think you'll see that you've >>>> been extraordinarily unwilling to answer simple questions (and >>>> that has led me to make certain inferences that I won't get into >>>> for the moment). >>>> >>>> FWIW, putting quotation marks around C does not make it easier >>>> to read. As you can see my my response, all it does is make me >>>> think that there's some significance to them. But now that I know >>>> that there isn't: >>>> >>>> You've referred to a C function. Have you written this C function? >>>> Is it, or is it intended to be, in standard C? Which edition of the >>>> standard does it attempt to conform to? How many lines long is it? >>>> (If you were willing to share the function itself that would be >>>> great, but I presume you won't do that.) >>>> >>>> I'll leave questions about what the function is supposed to do >>>> for later. >>> >>> I can't write the function yet because its operating system is not >>> finished. >> >> So you have no C function. Got it. >> >>> The function itself is in very standard very simple c. >> >> You mean it *will be* in very standard very simple C. > > Some of the code is written and executing. You said "I can't write the function yet". "Some of the code" could mean anything. You don't have a C function. > >> It is the same c since the first ansi c. I began writing c back when >>> it was K&R c. >> >> Great, so did I. I'm not sure what you mean by "the same c". >> If you mean that this C function that you haven't written yet will >> be compatible with the first ANSI C standard and with all later >> standards, that's fine. > > I can't write the halt deciding aspects of the code until after I have > added heap allocation and process context switching support. Their > detailed design has been complete for many months. This has been very > significanlty augmented from the 2018_12_13 initial specification. > >> If you mean that the language itself hasn't >> changed, that's simply incorrect. I'll explain further if and only >> if you ask me to. > > It is and has been the x86 language for many months. When I finish > adding minimal operating system support it will be a UTM having the > x86 language as its Turing Machine Description language. with at least > two (build from scratch) operating system functions that can be > invoked from this language: (1) Allocation for the heap (2) Process > context switching from one UTM to another. You were talking about C. I responded with more information about C. In response, you talk about "the x86 language". What exactly do you mean by "the x86 language"? Please don't assume I'm ignorant (I'm not), merely that I don't know just what you mean by the phrase. >>>> I've already asked you these questions, and you ignored them. >>>> I presume that it's important *to you* to communicate something >>>> about what you're working on. It's less important to me. So I'm >>>> not going to be as persistent about getting you to answer these >>>> simple questions. >>> >>> I told you that I can't write the function because its operating >>> system is not finished. >>> >>>>>> I'm just asking you to explain the quotation marks. If they don't >>>>>> mean anything, that's fine. >> >> You claimed to have a C function. You don't. You acknowledge that >> you haven't written it. No doubt you have some design or idea, or >> perhaps something written down in some kind of pseudocode, and >> we could discuss that if you like, but you don't have a C function. > > I have a c function that is fully executable except for those aspects > that depends on operating system support. In other words you don't have an executable C function. Your goal is to solve the halting problem, right? *Almost* solving the halting problem is easy (and uninteresting). >> I *think* you've said or implied that this C function is the same >> thing as the "fully encoded Turing Machine" you've been making >> claims about (because C is Turing-complete, and you therefore think >> you can call any chunk of C code a "fully encoded Turing machine"). >> Is that correct? So you never had your Turing machine either. > > All c code is Turing complete except for processes such as counting to > infinity and storing the result. If a machine had x-bit relative > addressing and no direct memory addressing then c could be easily > mapped to an actual Turing machine. I think you mean the C language, not "All c code". This is C code: int main(void) { } As you know, it is not Turing complete. My point is that precision is important, and if you write "All c code" when you really mean "The C programming language", it's impossible to to know what else you've written that means something else. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */