- Users needed - 1 Update
- A non-halting decider is defined - 2 Updates
- C++20 Designated initializers + struct member initializer - 1 Update
- "C++ programming language: How it became the invisible foundation for everything, and what's next" - 1 Update
- Why should a "c" programmer learn c++ ? (V2) - 2 Updates
- std::sort slow due to allocating and deallocing memory? - 1 Update
| Brian Wood <woodbrian77@gmail.com>: Nov 18 06:57AM -0800 On Wednesday, May 13, 2020 at 12:17:31 PM UTC-5, Brian Wood wrote: > project if we use my software as part of the project. > More info here: http://webEbenezer.net/about.html > . I would like to recommend "Large-Scale C++ Volume 1" by John Lakos. It's been the source of a number of ideas over the last few weeks on how to improve my software: https://github.com/Ebenezer-group/onwards/commit/528049e92c6c93b542dbabb5c03f7f57667bcaa9 https://github.com/Ebenezer-group/onwards/commit/fab7dec2de5904fd66f17fd9e44c2b3a62a9beea The book isn't cheap, but I'm happy with it so far. I've done a lot over the years to improve my software, but it's still not perfect. If you have an idea on how to improve it, please let me know. Tia. Brian Ebenezer Enterprises - Enjoying programming again. https://webEbenezer.net |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 17 07:56PM -0800 >> would take more than a thousand years just to read it > I'm sorry but envisioning humans doing a thing like that without > employing computers, is just daft. Like, stupid. Adding computers doesn't help. Even turning the entire physical universe into computers, the result is still finite. Man and machine together can deal with, at most, an infinitesimally small fraction of the set of Turing Machines. > You can't predict a future random event, so you can't predict the > random-influenced machine, so you can't construct an unsolvable case > for it. It isn't necessary to predict any future event. NDTMs can in effect go down all possible branches simultaneously, covering all possible values of any random input. They don't have to know which one will happen. > So, your assertion that randomness is irrelevant, is, uhm, just an > assertion. It's a proposition that is easily seen to be correct and convincing to those who understand how NDTMs work. > I'm not saying your conclusion is necessarily wrong but there's no > connection from premise to conclusion; that leap of yours is beyond > logic (unless you're postulating a time machine?). Which part of my statement do you think represents a leap? Is it (a) Any state change based on a random number can be simulated by a non-deterministic Turing Machine, or (b) deterministic Turing Machines can compute anything a NDTM can? |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 18 01:48PM +0100 On 18.11.2020 04:56, Tim Rentsch wrote: > universe into computers, the result is still finite. Man and > machine together can deal with, at most, an infinitesimally small > fraction of the set of Turing Machines. I'm sorry but that's disconnected from reality. Your argument, quoted above, was that a Turing Machine could be so big that reading it would exceed the lifetime of a really long-lived person, and that this observation somehow supported the argument that humans 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 chose to address the apparent observation in itself, noting that one assumption in it is just daft, the idea of a person having to read the TM specification. That I chose to constrain myself and be succinct doesn't mean that the other aspects of the idea are intelligent in any way. Nor does it mean that the alleged support of the hypothesis that intelligences are simple Turing Machines, is intelligent. By the way, just throwing in one more thing while I'm at it: intelligences can /communicate/, e.g. results about halting problems. That's one aspect entirely missing from Turing Machines, but the main 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. Again, sorry, but you're presenting essentially humanistic and/or religious arguments in a technical forum. It doesn't matter that these humanistic and/or religious arguments are /cast/ as technical arguments: form doesn't matter here, substance does. [snipalot] Cheers, - Alf |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 18 07:16AM On Wed, 2020-11-11, Brian Wood wrote: >> I see you're not interested in a serious discussion. > I don't understand why you say that. I've often found > your posts to be thoughtful and interesting. I should explain that my "you" meant Juha, not everyone. And I didn't mean Juha is /never/ interested in a serious discussion, just this time. (That this subthread was driven by C. Hanné surely didn't help.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Öö Tiib" <ootiib@hot.ee>: Nov 17 08:53PM -0800 On Tuesday, 17 November 2020 at 23:13:17 UTC+2, Lynn McGuire wrote: > was started in 1982. There was not a commercial release of C++ until 1985. > https://en.wikipedia.org/wiki/C%2B%2B > Lynn Microsoft wrote most things in C and its QuickC was quite weak C++ toolset. It was still QuickC in start of nineties IIRC. The tools and compilers of Watcom and Borland were preferred by many for DOS and Windows back then. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 17 07:32PM -0800 >> inline functions, when compiled under C rules. > I don't think the compiler is allowed to do that with non-static inline > functions, else you would get a linker error for duplicate symbols. I think you're assuming that the local copies would get marked as global symbols, which they are not. >> effort to help educate someone who can't be bothered to try >> to discover some answers for himself? > Nice and amicable attitude. It's just a question. If you aren't willing to treat my questions with courtesy and respect I don't see why I should feel obliged to do so for yours. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Nov 17 08:30PM -0800 > Juha Nieminen <nospam@thanks.invalid> writes: >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: [...] > It's just a question. If you aren't willing to treat my > questions with courtesy and respect I don't see why I > should feel obliged to do so for yours. It wasn't "just a question", Tim. It was rude and insulting. -- 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 */ |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 17 07:35PM -0800 > moving the pointed-to elements in the original array to the same > positions as the pointers sounds like a rather non-trivial task. > At least if you want to do it in-place. [...] Writing in C, it took me 14 lines of code. Of course it might end up being longer in C++. |
| 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