| olcott <polcott2@gmail.com>: Sep 16 11:17AM -0500 void Px(ptr x) { int Halt_Status = Hx(x, x); if (Halt_Status) HERE: goto HERE; return; } int main() { Output("Input_Halts = ", Hx(Px, Px)); } *Understanding the above code proves this* There are zero elements of infinite set of Hx/Px pairs such that the correct *partial or complete* simulation of Px by Hx reaches the final state of Px. *THIS LOGICALLY FOLLOWS (as a subset) FROM ABOVE* (A) Every element of the infinite set of Hx/Px pairs that does a correct and complete simulation of its input never reaches the final state of this input. *THIS IS THE DEFINITION OF A UTM THUS KNOWN TO BE TRUE* (B) A correct and complete simulation of Px by Hx derives the actual behavior of Px. *THIS LOGICALLY FOLLOWS FROM (A) AND (B) PREMISES* (C) The actual behavior of this input never reaches the final state of this input. When the criteria for a simulating halt decider (SHD) is to correctly predict that its complete and correct simulation of its input would never reach the final state of this simulated input then: void Infinite_Loop() { HERE: goto HERE; } *H0(Infinite_Loop)==0 // is correct* void Infinite_Recursion(int N) { Infinite_Recursion(N); } *H(Infinite_Recursion, 0x777)==0 // is correct* Every Hx that returns zero correctly predicts that every Px correctly and completely simulated by any Hx never reaches the final state of Px. *Hx(Px,Px)==0 // is correct* computation that halts … the Turing machine will halt whenever it enters a final state. (Linz:1990:234) The particular instance of Hx named H and contained in Halt7.c does correctly predict that the arguments to H(P,P) cannot possibly reach their own final state. H makes this prediction on the basis of correctly matching a correct infinite-behavior pattern. *complete halt deciding system including* *(a) x86utm operating system* *(b) complete x86 emulator* *(c) All of the various halt deciders and their inputs are contained in Halt7.c* https://liarparadox.org/2022_09_07.zip This system currently only compiles under: Microsoft Visual Studio Community 2017 https://visualstudio.microsoft.com/vs/older-downloads/ *Halting problem proofs refuted on the basis of software engineering* ? https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (317-320) -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 16 05:25PM +0100 > void Px(ptr x) > { > int Halt_Status = Hx(x, x); And so on... Just a heads-up: this thread is not about C or C++ and if you feel the need to reply do so on comp.theory (Followup-To set). The OP also set followup-to (so kudos there), but he's just fishing for new people to talk to, as all but one have stopped replying on comp.theory. If you feel the urge, I invite to review his >18-year history of posting on this topic first. -- Ben. |
| olcott <polcott2@gmail.com>: Sep 16 11:38AM -0500 On 9/16/2022 11:25 AM, Ben Bacarisse wrote: > talk to, as all but one have stopped replying on comp.theory. If you > feel the urge, I invite to review his >18-year history of posting on > this topic first. No one has found any error in the above and have given up responding on this basis because they were only ever interested in forming rebuttals to my work. I post to comp.lang.c and comp.lang.c++ because the proof that my work is correct can now be understood on the basis of ordinary software engineering in these two languages. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| gazelle@shell.xmission.com (Kenny McCormack): Sep 16 04:58PM In article <875yhnnv6k.fsf@bsb.me.uk>, >talk to, as all but one have stopped replying on comp.theory. If you >feel the urge, I invite to review his >18-year history of posting on >this topic first. So, what do you think of the new version of "The Little Mermaid", with a black girl in the lead role? -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/DanaC |
| olcott <polcott2@gmail.com>: Sep 16 12:37PM -0500 On 9/16/2022 11:58 AM, Kenny McCormack wrote: >> this topic first. > So, what do you think of the new version of "The Little Mermaid", with a > black girl in the lead role? I think that it is great. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Juha Nieminen <nospam@thanks.invalid>: Sep 16 06:08AM > What is it that you are hoping to accomplish by writing these > responses? If you have no idea why people keep responding to > his (or her) posts, why do you continue to respond to them? If nobody else replied to her posts and just ignored her, I wouldn't reply to them either. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 16 01:43PM +0200 Am 16.09.2022 um 08:08 schrieb Juha Nieminen: >> his (or her) posts, why do you continue to respond to them? > If nobody else replied to her posts and just ignored her, I wouldn't > reply to them either. You don't write because of others, you write because you're obsessed. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Sep 16 06:57AM -0700 >> his (or her) posts, why do you continue to respond to them? > If nobody else replied to her posts and just ignored her, I > wouldn't reply to them either. This statement doesn't address either of my questions. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 16 10:13AM -0700 >> his (or her) posts, why do you continue to respond to them? > If nobody else replied to her posts and just ignored her, I wouldn't > reply to them either. How does other people replying to her posts compel you to do so? Assuming you agree that the ideal solution (short of her either going away or becoming reasonable) would be for everyone to ignore her, why do you not want to help bring that about? A lot of us never see here posts in the first place. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| Juha Nieminen <nospam@thanks.invalid>: Sep 16 06:02AM > It seems, what you consider "professional language" I'd consider boring > and bureaucratic. Or, may be, not. In order to know for sure you have to > give me an example of what you consider well-written style guide. An official documentation intended for use by companies and individual people from all around the world, both hobbyists and professionals, from a wide variety of fields of industry, from a wide variety of backgrounds, countries, cultures and customs, *should* be as professional and neutral as possible. It *should* be "boring and bureaucratic". When you write things like "I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it's a great symbolic gesture" or "Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged [...] No wonder MicroSoft makes buggy programs" the only thing you are doing is alienating people. (And those are just two examples of many.) Also, how many big respectable international corporations would put this kind of language in their official documentation for the wider public? The Linux kernel is not a small hobby project for some small group of nerds anymore. It hasn't been for like a couple decades now. And it isn't even intended to be. The very coding style document itself advocates for the use of Linux (over other OS's like Windows), and clearly would want to be as widely used as possible. Thus, it makes absolutely no sense to use unprofessional cringe and alienating language like that in an official document intended for the wider public. Imagine going to some giant megacorporation to try to sell some idea or product of yours, and in your presentation you used language like that. |
| Muttley@dastardlyhq.com: Sep 16 10:37AM On Fri, 16 Sep 2022 06:02:12 -0000 (UTC) >from a wide variety of fields of industry, from a wide variety of >backgrounds, countries, cultures and customs, *should* be as professional >and neutral as possible. It *should* be "boring and bureaucratic". Bollocks. A lot of the people writing linux code are hobbiests and if you want to attract those sorts of people a light hearted approach is a good approach. The LAST thing you want is dull, tedious documentation that drones on to the point where people just stop reading it. >"Encoding the type of a function into the name (so-called Hungarian >notation) is brain damaged [...] No wonder MicroSoft makes buggy programs" >the only thing you are doing is alienating people. (And those are just You might be alienating some aspies with zero social skills but for most people it'll elicit a chuckle and keep them reading. >two examples of many.) Also, how many big respectable international >corporations would put this kind of language in their official >documentation for the wider public? You're confusing business products with an open source project. One you pay for, one you don't. >The Linux kernel is not a small hobby project for some small group of >nerds anymore. It hasn't been for like a couple decades now. And it >isn't even intended to be. The very coding style document itself Except plenty of people who work on the kernel ARE hobbyists. >Imagine going to some giant megacorporation to try to sell some idea >or product of yours, and in your presentation you used language >like that. Oh do bore off. |
| Juha Nieminen <nospam@thanks.invalid>: Sep 16 11:05AM > want to attract those sorts of people a light hearted approach is a good > approach. The LAST thing you want is dull, tedious documentation that drones > on to the point where people just stop reading it. The majority of current contributors to the Linux kernel are giant international megacorporations (including companies like Intel, Google, Huawei, Red Hat, Linaro, Samsung and IBM). Hobbyists are *not* the majority of contributors, and haven't been for quite a while. Even then, I have really hard time believing that some hobbyist would decide not to contribute to the Linux kernel because its code style guideline page uses neutral to-the-point professional language. I find the opposite notion to be bizarre and silly. The contrary may well be true: Someone may find the infantile tone of such documentation disgraceful and unprofessional, and dismiss the whole thing as just a toy project. >>documentation for the wider public? > You're confusing business products with an open source project. One you pay > for, one you don't. This has nothing to do with price. Linux *is* a business project, like it or not. Just because it doesn't cost anything doesn't change that fact. (Tons of corporations have business offering products for free, such as Google, Microsoft and others.) But even if it weren't, using infantile cringle language that's likely to just alienate people makes no sense, no matter how "open source" the project may be. I don't even understand why you are defending that web page. It makes no sense. |
| David Brown <david.brown@hesbynett.no>: Sep 16 01:10PM +0200 > want to attract those sorts of people a light hearted approach is a good > approach. The LAST thing you want is dull, tedious documentation that drones > on to the point where people just stop reading it. It is possible to be light-hearted while remaining professional. It is /decades/ since the core of Linux development was done by hobby programmers. The great majority of the work on the kernel, excluding support for more obscure hardware, is done by people who are paid to write the code. It is important for the project that "small" programmers don't feel alienated, or that it is too bureaucratic, but it is also important to remember it is a professional project, run by professionals, and used by professionals. Fortunately, the style guide here is something only the actual technical coders will look at - and even then, most contributors will copy the existing code style rather than looking at the guide. They are much more likely to laugh at it than "corporate leader" types who might wonder if this is the kind of project they can bet their company's future on. It's worth noting that Linus Torvalds has gradually developed a more mature, diplomatic and professional style of leadership and of communication with the outside world, while still maintaining a unique development environment. I would expect that sooner or later, this guide will also get cleaned up (as well as being modernised to include C11, now that it is the standard for the kernel). >> documentation for the wider public? > You're confusing business products with an open source project. One you pay > for, one you don't. Much of the Linux world is professional and paid-for. When you buy a server from IBM with Red Hat Linux, you pay a /lot/. Linux is not driven by zero-cost usage of software written by people for free. Open source is not primarily about zero cost (though the fact that you can use it for zero cost hugely increases its popularity) - it is about an open development model, and sharing the cost and sharing the results. >> nerds anymore. It hasn't been for like a couple decades now. And it >> isn't even intended to be. The very coding style document itself > Except plenty of people who work on the kernel ARE hobbyists. They outnumber the professionals in terms of numbers of contributors - but the professionals outnumber the hobbyists in terms of the work done and code committed. And if you look at in terms of the key parts of the kernel, used by everyone, the difference is vastly greater. The style of this coding guide was fine when it was written, but the Linux project has moved on and changed enormously since then. I doubt if it has caused much real negative reaction in practice, but it is certainly due for an update. |
| Muttley@dastardlyhq.com: Sep 16 01:18PM On Fri, 16 Sep 2022 11:05:50 -0000 (UTC) >international megacorporations (including companies like Intel, >Google, Huawei, Red Hat, Linaro, Samsung and IBM). Hobbyists are *not* >the majority of contributors, and haven't been for quite a while. You'll have some stats to back that up then. >decide not to contribute to the Linux kernel because its code style >guideline page uses neutral to-the-point professional language. I find >the opposite notion to be bizarre and silly. People don't contribute because they have to but because they want to. Even most of the ones employed to do it will have probably started out doing it as a hobby because you don't just hire someone to do kernel development when they've never done it before. >The contrary may well be true: Someone may find the infantile tone of >such documentation disgraceful and unprofessional, and dismiss the whole >thing as just a toy project. Its not infantile, its just tongue in cheek. Plenty of the Dummies Guide books have the same approach and they sell by the bucket load. >> You're confusing business products with an open source project. One you pay >> for, one you don't. >This has nothing to do with price. Linux *is* a business project, like The linux kernel which we're discussing is NOT a business project. If a corporation wants to add to it or package it up into a distro and sell that thats up to them, but the kernel is not and never has been a business project. >it or not. Just because it doesn't cost anything doesn't change that >fact. (Tons of corporations have business offering products for free, >such as Google, Microsoft and others.) It value adds what they already have or nudges people into their ecosystem. How does the linux kernel do that? >I don't even understand why you are defending that web page. It makes >no sense. Its clear you have zero sense of humour so there appears to be little point arguing the toss with you. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Sep 16 06:56AM -0700 > I like the language of this text. > Style itself - less so; agree or accept with 80%, but not with > another 20%. Do you mind saying which parts you don't agree with? |
| David Brown <david.brown@hesbynett.no>: Sep 16 04:00PM +0200 >> Google, Huawei, Red Hat, Linaro, Samsung and IBM). Hobbyists are *not* >> the majority of contributors, and haven't been for quite a while. > You'll have some stats to back that up then. There is a marvellous tool called "google" that can help you avoid making a fool of yourself in public. But to help you out : <https://en.wikipedia.org/wiki/Linux#Community> """ Although Linux distributions are generally available without charge, several large corporations sell, support, and contribute to the development of the components of the system and of free software. An analysis of the Linux kernel in 2017 showed that well over 85% of the code developed by programmers who are being paid for their work, leaving about 8.2% to unpaid developers and 4.1% unclassified.[97] Some of the major corporations that provide contributions include Intel, Samsung, Google, AMD, Oracle and Facebook.[98] A number of corporations, notably Red Hat, Canonical and SUSE, have built a significant business around Linux distributions. """ (I'm sure you are now tempted to make pathetic claims about Wikipedia being wrong - but I'd encourage you to follow the references in the Wikipedia article, and search yourself, before doing so.) <https://lwn.net/Articles/839772/> That puts the number of lines changed for Linux 5.10 at 4% for people contributing without it being via their employer, and 5.3% for "unknown". Thus 90.7% of the changes come from known corporate sources or other employers (such as universities). Other links: <https://www.linux.com/news/who-contributes-linux-kernel/> (I've snipped the rest of your post, since you are writing out of complete ignorance or denial about Linux. Ignorance is easily cured, if you are willing to accept the cure - read the links, and research yourself for more information that is wildly off-topic for this group.) >> no sense. > Its clear you have zero sense of humour so there appears to be little point > arguing the toss with you. I can't answer for Juha's sense of humour, but he is spot-on about how and by whom Linux is developed and how the development is paid for, and how it is a professional project. And I suspect he is well aware of the difference between "light-hearted with a bit of humour" and the language used in the kernel style guide. College student level jokes are fine between college students - they are inappropriate for a professional and serious project. |
| scott@slp53.sl.home (Scott Lurndal): Sep 16 02:29PM >> Style itself - less so; agree or accept with 80%, but not with >> another 20%. >Do you mind saying which parts you don't agree with? I think one should always use braces for if/while/do/for regardless of the number of statements in the construct. Perhaps this comes from my punched card days, when adding a statement to the if would have required repunching the if statement card if it hadn't used braces from the beginning, but it also does help avoid future problems during maintenance or enhancement activities. And I disagree with the 8 column hard tabs. As tabs were derived from mechanical typewriters, where the tabs were always variable, their rationale for 8 column tabs isn't compelling. I disagree with their opinion on typedefs (for C; for C++ since you don't need the struct/class keywords, the class/struct name doesn't need a typedef). I've been working on Linux kernel code off-and-on since 1997, including contributing an in-kernel debugger (kdb) in 1998/9 while at SGI. |
| David Brown <david.brown@hesbynett.no>: Sep 16 05:04PM +0200 On 16/09/2022 16:29, Scott Lurndal wrote: >> Do you mind saying which parts you don't agree with? > I think one should always use braces for if/while/do/for > regardless of the number of statements in the construct. I agree. > statement card if it hadn't used braces from the beginning, > but it also does help avoid future problems during maintenance > or enhancement activities. My reasoning is that braces reduces the risk for errors - both while writing code, and when reading it. As well as the well-known issue of multi-statement macros (which should have a "do {...} while (0)" wrapper anyway), it improves consistency. An open brace means the next line has an extra indent, unindents have a close brace - and vice versa. This makes it much easier to see the nesting and scope. In addition, the kernel coding style rule requires: if (condition) do_this(); else do_that(); and if (condition) { do_this(); do_more(); } else { do_that(); } This means adding the line "do_more()" changes another three lines that are not semantically affected, simply to suit the style. That's bad practice, especially for a project where revision control and changesets are so critical - you do not want cosmetic changes on unrelated code. I am okay with simple conditionals and a simple statement on the same line without braces, as long as things are very clear : if (!p_data) return; // No data, so nothing to do if (x > max_value) x = max_value; > And I disagree with the 8 column hard tabs. As tabs were > derived from mechanical typewriters, where the tabs were > always variable, their rationale for 8 column tabs isn't compelling. Agreed. I usually use 4 spaces for a tab, although it is really just a personal preference. I agree with the guide that many indentation levels is a sign that your function is probably due for a refactoring, but you don't have to have such big tabs to see that. > I disagree with their opinion on typedefs (for C; for C++ since > you don't need the struct/class keywords, the class/struct name > doesn't need a typedef). I don't agree with the guide on typedefs either, though that does not necessarily mean we disagree in the same way about the same details! Some of the factors in any coding style guide are going to be dependent on characteristics of the project - rules that suit a single-person project will not always match with one spanning hundreds or thousands of developers. Similarly portability, project size, target system, language standards, and all kinds of other factors come into play. Disagreeing about a particular style guide point does not necessarily mean I think it is /wrong/, merely that I typically follow different rules. > I've been working on Linux kernel code off-and-on since 1997, including > contributing an in-kernel debugger (kdb) in 1998/9 while at SGI. Quiet - don't spoil people's delusions by telling them corporations contribute to Linux! |
| Muttley@dastardlyhq.com: Sep 16 03:16PM On Fri, 16 Sep 2022 16:00:41 +0200 >> You'll have some stats to back that up then. >There is a marvellous tool called "google" that can help you avoid >making a fool of yourself in public. But to help you out : Thanks for that, never thought of it. >contributing without it being via their employer, and 5.3% for >"unknown". Thus 90.7% of the changes come from known corporate sources >or other employers (such as universities). Thats not the same as 90% in total over the decades. I suspect its rather smaller. >used in the kernel style guide. College student level jokes are fine >between college students - they are inappropriate for a professional and >serious project. Both you and Juha are humourless bores and in your case one who takes himself far too seriously. People who cling on to professionalism as some kind of badge are usually making up for a lack of actual skills. |
| Michael S <already5chosen@yahoo.com>: Sep 16 08:24AM -0700 On Friday, September 16, 2022 at 4:56:23 PM UTC+3, Tim Rentsch wrote: > > Style itself - less so; agree or accept with 80%, but not with > > another 20%. > Do you mind saying which parts you don't agree with? Yes, I do. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Sep 16 09:00AM -0700 >>> another 20%. >> Do you mind saying which parts you don't agree with? > Yes, I do. In that case do you mind saying which parts you agree with? Just kidding.. I respect your decision not to answer, and say thank you for responding. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Sep 15 11:29PM -0500 I cannot figure out how to run this Fortran to C++ FABLE conversion tool on Windows. They made a Windows port back in 2015 but I have not been able to find the files so far. I really hoping that I do not have to build a linux box. https://github.com/cctbx/cctbx_project/tree/master/fable The problem is that the FABLE tool is actually part of another software package and it is written in Python. It seems that some of the initialization files are missing. Does anyone here have experience with FABLE on Windows ? Thanks, Lynn |
| Lynn McGuire <lynnmcguire5@gmail.com>: Sep 15 11:34PM -0500 On 9/15/2022 11:29 PM, Lynn McGuire wrote: > FABLE on Windows ? > Thanks, > Lynn Sorry, I forgot to mention the original site for FABLE: https://cci.lbl.gov/fable/ and https://www.osti.gov/biblio/1256083 and https://scfbm.biomedcentral.com/articles/10.1186/1751-0473-7-5 Thanks, Lynn |
| Christian Gollwitzer <auriocus@gmx.de>: Sep 16 09:12AM +0200 Am 16.09.22 um 06:29 schrieb Lynn McGuire: > able to find the files so far. I really hoping that I do not have to > build a linux box. > https://github.com/cctbx/cctbx_project/tree/master/fable Hi Lynn, I have no experience with this software, but I know Python I had a look at it. I have rarely seen a more confusing build procedure, even for Unix standards. The repository is not organized very well, and I predict that even under Unix, you would have a lot of fun to actually build this. The main reason seems to be that fable is kept as a part of this CCTBX package and both the build system as well as the main Python code uses facilities from the bigger CCTBX package; therefore I doubt that it is easily possible to compile and run it on its own, without building CCTBX first. On the main page of CCTBX they say that there are builds available in conda (the Anaconda package manager). If the license is feasible for you, probably the easiest way will be to install Anaconda and than get it via conda as described on the CCTBX front page. Or try to rip it off conda-forge by starting to browse https://anaconda.org/conda-forge/cctbx-base Christian |
| DFS <nospam@dfs.com>: Sep 16 10:58AM -0400 On 9/16/2022 12:29 AM, Lynn McGuire wrote: > on Windows. They made a Windows port back in 2015 but I have not been > able to find the files so far. I really hoping that I do not have to > build a linux box. I found this in /fable/doc/index.txt in the cctbx source: -------------------------------------------------------------------------- - Windows systems (XP or higher):: Download http://cci.lbl.gov/fable_bundles/current/fable_win_xp.exe fable_win_xp.exe fable_build\setpaths.bat fable.cout --example The ``fable.cout --example`` command is known to work with gcc 3.2 or higher, Visual C++ 7.1 or higher, and with recent development versions of clang++. -------------------------------------------------------------------------- or, install the Windows Subsystem for Linux, and you can run any number of Linux distros virtually. https://docs.microsoft.com/en-us/windows/wsl/install |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment