- A non-halting decider is defined - 2 Updates
- Is there a way to list all supported locales either the C- or C++-runtime? - 8 Updates
- "C++ programming language: How it became the invisible foundation for everything, and what's next" - 9 Updates
- Halts() correctly decides the conventional counter-example of the HP proofs - 1 Update
- std::sort slow due to allocating and deallocing memory? - 4 Updates
- Hashing for unordered containers? - 1 Update
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 20 09:45AM -0800 > can not discover a halting-or-not that a specific very restricted TM, > which that halting problem is specifically designed for, fails to > discover. I think you misunderstood my comments. My claim is only that people (then expanded to any collection of people and computers in the physical universe) cannot solve the halting problem. It is always possible to answer the question of halting for a single Turing Machine input, or indeed any finite collection of inputs. > thing, as I noted, just to get this back on track, is that you cannot > (faithfully) model an intelligence with a single number that defines > it, and that severely limits the applicability of Turing's proof. I wasn't addressing any statement regarding intelligence. My comments were only about things that exist in the physical universe, whether they are intelligent or not. > Again, sorry, but you're presenting essentially humanistic and/or > religious arguments in a technical forum. My comments are neither humanistic nor religious. The conclusions rest solely on the property that the universe is finite, which I think essentially all scientists would agree with. > It doesn't matter that these humanistic and/or religious arguments are > /cast/ as technical arguments: form doesn't matter here, substance > does. I'm sorry that we seem to be having trouble understanding each other. |
| Tim Woodall <news001@woodall.me.uk>: Nov 20 09:10PM > in the physical universe) cannot solve the halting problem. It > is always possible to answer the question of halting for a single > Turing Machine input, or indeed any finite collection of inputs. A circa 8k [1] state (2 symbol, 1 tape) TM is known that halts if ZFC is inconsistent. A proof that it doesn't halt would be the same as proving ZFC is consistent. [1] I believe there are much smaller machines known (<1k states) |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 20 04:12PM +0100 I'm curious about the supported locales of my C- and C++-runtime. So is there a way to list the supported locales for either the C- or C++-runtime ? And if there isn't: are there platform-dependent ways that map 1:1 to the C- or C++-runtime locale-strings for either Linux or Win32 ? With Windows there's EnumSystemLocalesEx etc., but this doesn't include the encodings in the locale-strings (i.e. "xxx.UTF" etc.). |
| scott@slp53.sl.home (Scott Lurndal): Nov 20 04:08PM >I'm curious about the supported locales of my C- and C++-runtime. >So is there a way to list the supported locales for either the C- >or C++-runtime ? On linux: $ ls /usr/share/i18n/locales/ $ ls /usr/share/i18n/locales/ |wc -l 312 |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 20 11:45AM -0500 On 11/20/20 11:08 AM, Scott Lurndal wrote: > $ ls /usr/share/i18n/locales/ > $ ls /usr/share/i18n/locales/ |wc -l > 312 Or just type "locale -a" |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Nov 20 11:35AM -0800 >> $ ls /usr/share/i18n/locales/ |wc -l >> 312 > Or just type "locale -a" On my system, "locale -a" shows 29 locales, but there are 361 entries in /usr/share/i18n/locales/. I think some of the files in that directory don't correspond to locales, but not enough of them to explain the difference. -- 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 */ |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 20 08:42PM +0100 > $ ls /usr/share/i18n/locales/ > $ ls /usr/share/i18n/locales/ |wc -l > 312 I wan't to have a direct API-call. Of course I could enumerate the files with opendir() / readdir(), but this isn't really handy. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 20 07:56PM On Fri, 2020-11-20, Keith Thompson wrote: > /usr/share/i18n/locales/. I think some of the files in that directory > don't correspond to locales, but not enough of them to explain the > difference. Some systems (e.g. Debian) distinguishes between locales which are theoretically available, and those the sysadmin has choosen to "generate", i.e. make ready for use. Not generating all of them saves disk space. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 20 02:58PM -0500 On 11/20/20 2:35 PM, Keith Thompson wrote: > /usr/share/i18n/locales/. I think some of the files in that directory > don't correspond to locales, but not enough of them to explain the > difference. I see the same 361 entries, but locale -a gives 61 locales for me. Except for the C, C.UTF-8, and POSIX locales, every locale given by "locale -a" corresponds to one of the 5 languages that I can read, and for which I've installed fonts. There are, for instance, 22 different locales for Spanish, which is how the total comes to 61. |
| scott@slp53.sl.home (Scott Lurndal): Nov 20 07:58PM >> 312 >I wan't to have a direct API-call. Of course I could enumerate >the files with opendir() / readdir(), but this isn't really handy. Well, figure it out. The information is all there. $ man -k locale https://pubs.opengroup.org/onlinepubs/9699919799/ |
| Ian Collins <ian-news@hotmail.com>: Nov 20 12:23PM +1300 On 19/11/2020 21:06, Melzzzzz wrote: > C++ took of after 1998, I really doubt it was use for something > seriously (besides GUI) before that... It was. My first "professional" (paid!) C++ project, hardware simulation, was in the early 90s. -- Ian. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Nov 20 04:22AM >> seriously (besides GUI) before that... > It was. My first "professional" (paid!) C++ project, hardware > simulation, was in the early 90s. Dunno, I started to learn C++ in 1993, gcc 2.95.2 was buggy as hell, and that was after 1998. ;) In 1993, nah C++ compilers were... -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 19 11:44PM -0500 On 11/19/20 11:22 PM, Melzzzzz wrote: ... > Dunno, I started to learn C++ in 1993, gcc 2.95.2 was buggy as hell, > and that was after 1998. ;) > In 1993, nah C++ compilers were... 1993 was after 1998? I have no idea what your "..." is supposed to mean in this context. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 19 10:14PM -0800 On Friday, 20 November 2020 at 06:23:19 UTC+2, Melzzzzz wrote: > Dunno, I started to learn C++ in 1993, gcc 2.95.2 was buggy as hell, > and that was after 1998. ;) > In 1993, nah C++ compilers were... The gcc was not only buggy or strange C++ compiler. The one on Mac supported length prefixed strings like in Pascal IIRC. Things were chaotic. But in general the C++ compilers gave more diagnostics than C compilers and banned several questionable usages. Classes let to manage deeper data hierarchies and resources more conveniently. It also opened new ways to be inefficient but for that there were profilers. After templates were added then C felt sometimes too crippling ... too much copy-paste to use. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Nov 20 06:40AM >> In 1993, nah C++ compilers were... > 1993 was after 1998? > I have no idea what your "..." is supposed to mean in this context. Rellic from the past was throwing exceptions buy pointer and overloading global new operator... I work now witj these quircks from early nineties. Also throwing exception from so libray was no no. templates were horror. I really don't get how you do not understand what I say? After 1998 compilers were bad and in 1993+ horror... -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Melzzzzz <Melzzzzz@zzzzz.com>: Nov 20 06:45AM > inefficient but for that there were profilers. After templates were > added then C felt sometimes too crippling ... too much > copy-paste to use. I liked C++ as it was less coding, much less then C. And interfaces simpler. Hell, majority of work was to hide awfull C apis... -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| scott@slp53.sl.home (Scott Lurndal): Nov 20 04:10PM >Dunno, I started to learn C++ in 1993, gcc 2.95.2 was buggy as hell, >and that was after 1998. ;) >In 1993, nah C++ compilers were... cfront-based, for the most part. We used cfront + pcc (generating code for the motorola 88100 cpu). |
| Ian Collins <ian-news@hotmail.com>: Nov 21 07:48AM +1300 On 20/11/2020 17:22, Melzzzzz wrote: > Dunno, I started to learn C++ in 1993, gcc 2.95.2 was buggy as hell, > and that was after 1998. ;) > In 1993, nah C++ compilers were... No worse and often better then the embedded C compilers we had to use! We used Sun Workshop. -- Ian. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 20 07:52PM On Thu, 2020-11-19, Melzzzzz wrote: >> might or might not be relevant: C++ was a well-established and fairly >> popular language long before it first got standardized in 1998. > It was popular, but useless. Let's settle for "much less useful". I'm so thankful for the STL; it shaped the way I design my code today. I remember having a hard time understanding how it was supposed to work, though. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| olcott <NoOne@NoWhere.com>: Nov 20 12:11PM -0600 When-so-ever decider Halts() (adapted from a UTM) decides that: (a) its input (<P>,I) would never halt unless H stopped simulating it and it is the case that (b) its input (<P>,I) would never halt unless H stopped simulating it then Halts() has made a correct not-halting decision on this input. I just finished enough of the programming of my x86utm operating system so that it collects the actual execution trace of every line of user code that is executed. Of the 10,671 lines that are actually executed only 35 lines are relevant to the halt decider's halting decision. All of these lines are shown below. Anyone with a bachelors degree in computer science would understand that every Turing machine that has infinite recursion would never stop running. That I show exactly how to decide the previously undecidable input: (H_Hat shown below) proves that I have refuted all of the conventional halting problem proofs. My system is based on the x86 language that is known to be computationally equivalent to a universal Turing machine for every computation that does not require more memory than it has available: x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. void H_Hat(u32 P) { u32 Aborted = Halts(P, P); if (Aborted) HALT else HERE: goto HERE; } int main() { u32 P = (u32)H_Hat; Halts(P, P); HALT; } _H_Hat() [000004f7](01) 55 push ebp [000004f8](02) 8bec mov ebp,esp [000004fa](01) 51 push ecx [000004fb](03) 8b4508 mov eax,[ebp+08] [000004fe](01) 50 push eax [000004ff](03) 8b4d08 mov ecx,[ebp+08] [00000502](01) 51 push ecx [00000503](05) e86ffeffff call 00000377 [00000508](03) 83c408 add esp,+08 [0000050b](03) 8945fc mov [ebp-04],eax [0000050e](04) 837dfc00 cmp dword [ebp-04],+00 [00000512](02) 7403 jz 00000517 [00000514](01) f4 hlt [00000515](02) eb02 jmp 00000519 [00000517](02) ebfe jmp 00000517 [00000519](02) 8be5 mov esp,ebp [0000051b](01) 5d pop ebp [0000051c](01) c3 ret _main() [00000527](01) 55 push ebp [00000528](02) 8bec mov ebp,esp [0000052a](01) 51 push ecx [0000052b](07) c745fcf7040000 mov [ebp-04],000004f7 [00000532](03) 8b45fc mov eax,[ebp-04] [00000535](01) 50 push eax [00000536](03) 8b4dfc mov ecx,[ebp-04] [00000539](01) 51 push ecx [0000053a](05) e838feffff call 00000377 [0000053f](03) 83c408 add esp,+08 [00000542](01) f4 hlt [00000543](02) 8be5 mov esp,ebp [00000545](01) 5d pop ebp [00000546](01) c3 ret Execution trace seen by the global halt decider std_vector[00010abc]-->00000527 // main() std_vector[00010ac0]-->00000528 std_vector[00010ac4]-->0000052a std_vector[00010ac8]-->0000052b std_vector[00010acc]-->00000532 std_vector[00010ad0]-->00000535 std_vector[00010ad4]-->00000536 std_vector[00010ad8]-->00000539 std_vector[00010adc]-->0000053a // call to _Halts() std_vector[00010ae0]-->000004f7 // DebugStep(_H_Hat) std_vector[00010ae4]-->000004f8 std_vector[00010ae8]-->000004fa std_vector[00010aec]-->000004fb std_vector[00010af0]-->000004fe std_vector[00010af4]-->000004ff std_vector[00010af8]-->00000502 std_vector[00010afc]-->00000503 // call to _Halts() std_vector[00010b00]-->000004f7 // DebugStep(_H_Hat) std_vector[00010b04]-->000004f8 std_vector[00010b08]-->000004fa std_vector[00010b0c]-->000004fb std_vector[00010b10]-->000004fe std_vector[00010b14]-->000004ff std_vector[00010b18]-->00000502 std_vector[00010b1c]-->00000503 // call to _Halts() infinite recursion decided Number of Instructions Executed(10671) -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| "Öö Tiib" <ootiib@hot.ee>: Nov 19 03:43PM -0800 On Thursday, 19 November 2020 at 17:05:33 UTC+2, Richard Damon wrote: > A more complicated method is start at the first element, move it to a > temporay location, Moving that first element does not make any sense if first pointer points at it already? It is then correctly sorted. Also don't we somehow need to figure out what pointer actually points at it for that move to make sense even when first pointer does not point at it? > When you finally get to the location that first element wanted to go > into it, you put it in place, and look for the first eleent that needs > to move again. As it did start confusing I'm perhaps confused, you mark something, things want and need to go. There are just two arrays sorted pointers and possibly-unsorted elements for me. Somehow you do it once per cycle at time and somehow you separate that some element does not belong to cycle that has been already processed but you leave al these details out. Feels it all makes sense to you but if it is really 10 lines of C then I would prefer that C. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 19 07:24PM -0800 On Friday, 20 November 2020 at 01:43:24 UTC+2, Öö Tiib wrote: > Feels it all makes sense to you but if it is > really 10 lines of C then I would prefer that C. Was it meant something like that?: void sort_with_pointers(std::vector<Value>& data, std::vector<Value*>& pointers) { assert(data.size() == pointers.size()); Value tmp; for (size_t i = 0; i <pointers.size(); ++i) { if (pointers[i] != &data[i]) { tmp = std::move(data[i]); size_t current = i; size_t next = pointers[current] - &data[0]; while (next != i) { data[current] = std::move(data[next]); pointers[current] = &data[current]; current = next; next = pointers[next] - &data[0]; } data[current] = std::move(tmp); pointers[current] = &data[current]; } } } |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 20 09:59AM -0800 > *How* do you sort the array in-place, when you have another array of > pointers where each pointer is located in the position where the object > it's pointing to needs to go? Knowing that there is a short implementation in a well-understood and known language helps limit the search for a solution. > original array to its correct position first. How? (And even if you were > to find out where it should go, also in that position there will be an > element that needs to be moved to its correct position first, and so on.) Tiib posted some code that is basically the same as my own. > Care to share the algorithm instead of bragging about how many lines of > code of C you can implement it with? As a general rule I don't post code right away, to give other people a chance to work out problems for themselves, rather than just being told the answer. As it turns out, in this case that produced a nice benefit, in that Tiib's algorithm is a bit nicer than mine. Incidentally, I wasn't bragging, because I don't think of what I did as being anything special, either in finding a solution or in how long it was. I don't mind helping people in areas where they really need help, but I don't think of this problem as being one of those, at least not for non-novice programmers. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 20 10:11AM -0800 > On Friday, 20 November 2020 at 01:43:24 UTC+2, <<D6 F6 [05b6]>> Tiib wrote: >> Feels it all makes sense to you but if it is >> really 10 lines of C then I would prefer that C. It was 14 lines. > } > } > } Yes, this code is basically the same as what I wrote. For the inner loop I used a for() rather than a while(), which compacts the code a bit. Also there are some minor style differences, which together with the while()/for() shortening account for the small difference in function lengths. I must add though, that your algorithm is an improvement over mine, in that you set pointers[current] to &data[current], which means the test for already-in-place is just a single if(). As cycles were moved, I would mark each pointer in the cycle by setting it to NULL, which means the starting check needs to check two different conditions. So thank you for the idea, and kudos for discovering this nice improvement. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 20 09:24AM -0800 >> is acceptable. > Thanks. Yes, an extra line would be acceptable -- although I'm sure > people would find the macro odd, if they found it. Oops, I left out an important part of the code suggestion, namely, this comment: // Despite an extensive search, I am unable to find // a better way to do this in C++14. Also, with benefit of hindsight, I think I would also change the macro to take two arguments, the second being the name of the member function to use to compute the hash value. > understand why ... but I still don't understand why it's harder to use > a class with the unordered containers than with the ordered > equivalents. The rapid pace of change to the C++ language is a double-edged sword. It's nice to get new features early, but sometimes they aren't as complete or integrated as we would like them to be. My understanding is, in C++17 and later you can do what you want with one fixed overhead, not even needing an extra line per class, but just by defining the relevant member function (along with the aforementioned small fixed overhead, just once for all the classes that need it). If you know that support will get better if/when the project moves to a later version of C++, I don't know why you wouldn't take advantage of this alternate path. Admittely it is less than perfect, but that is pretty much the nature of software engineering for products that are expected to be delivered. |
| 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