- Provably unprovable eliminates incompleteness - 7 Updates
- ""Rust is the future of systems programming, C is the new Assembly": Intel principal engineer, Josh Triplett" - 3 Updates
- Static_assert in 2017 C++ - 7 Updates
- Anyone working with Graphiz and DOT (directed graphs) - 1 Update
- All function declarations/defintions and variable declaration/defintions one one line - 4 Updates
- Performance of exceptions - 1 Update
| Stuart Redmann <DerTopper@web.de>: Sep 09 11:30AM +0200 > Since this is unreadable by peons, I can only speculate, > but provably unprovable sounds like a useless tautology. > Dhu It isn't. It rather shows that - like the speed of light in physics - there are some rather unexpected limitations to what is possible in mathematics. For many years mathematicians believed that, given a set of axioms, every possible theorem in the given field can be proven to be either true or false based on logical deduction from these axioms. Goedel showed that this is not always the case (see the continuum hypothesis). This implies that there are things in mathematics that cannot be proven. This culminated in Goedels incompleteness theorem, which is considered by many mathematicians as a severe throwback in maths. Regards, Stuart |
| peteolcott <Here@Home>: Sep 09 09:57AM -0500 On 9/8/2019 1:06 AM, Dhu on Gate wrote: > Since this is unreadable by peons, I can only speculate, > but provably unprovable sounds like a useless tautology. > Dhu The entire body of conceptual knowledge is specified as relations between finite strings: {axioms, rules-of-inference, axiom schemata}. Formal proofs to theorem consequences specify provable and true concurrently. -- Copyright 2019 Pete Olcott All rights reserved "Great spirits have always encountered violent opposition from mediocre minds." Albert Einstein |
| peteolcott <Here@Home>: Sep 09 10:01AM -0500 On 9/9/2019 4:30 AM, Stuart Redmann wrote: > considered by many mathematicians as a severe throwback in maths. > Regards, > Stuart https://en.wikipedia.org/wiki/Continuum_hypothesis It turns out that the basis concept of cardinality is ill-formed. All infinities are the same size. The number of real numbers is the number of adjacent geometric points on a number line, countable using integers. -- Copyright 2019 Pete Olcott All rights reserved "Great spirits have always encountered violent opposition from mediocre minds." Albert Einstein |
| Keith Thompson <kst-u@mib.org>: Sep 09 01:30PM -0700 > "This sentence is unprovable" can be proven to be unprovable > on the basis that its satisfaction derives a contradiction. [...] This has nothing to do with Prolog, Lisp, or C++, and probably nothing to do with comp.ai.philosophy. Please modify the "Newsgroups:" header when posting followups -- or just don't post. See comp.theory for the background of this discussion (it's probably more than 90% of the content of that newsgroup). -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| Mr Flibble <flibble@i42.removethisbit.co.uk>: Sep 09 09:38PM +0100 On 09/09/2019 16:01, peteolcott wrote: > All infinities are the same size. Nonsense. Infinity doesn't have a size by definition. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Louis Valence <lvalence@example.com>: Sep 09 05:43PM -0300 > Dhu on Gate <campbell@neotext.ca> wrote: [...] > hypothesis). This implies that there are things in mathematics that cannot > be proven. This culminated in Goedels incompleteness theorem, which is > considered by many mathematicians as a severe throwback in maths. Despite my very limited understanding of logic, mathematics and everything else, I can't agree with you. There are some limitations to what is possible in formal logic; the same cannot today be said about mathematics. There are things in some formal logic systems that cannot be proven, but AFAIK there is no known result to the effect of what mathematics can or cannot prove. Peter Smith in ``An Introduction to Godel's Theorems (ISBN: 978-0-511-35096-2)'', on section 1.2, page, writes: --8<---------------cut here---------------start------------->8--- Suppose we try to specify a suitable axiomatic theory T that seems to capture the structure of the natural number sequence and pin down addition and multiplication (and maybe a lot more besides). Then Godel gives us a recipe for coming up with a corresponding sentence G(T), couched in the language of basic arithmetic, such that (i) we can show (on very modest assumptions, e.g. that T is consistent) that neither G(T) nor ~G(T) can be derived in T, and yet (ii) we can also recognize that, at least if T is consistent, G(T) will be true. --8<---------------cut here---------------end--------------->8--- So, Godel's recipe itself shows T is incomplete, meaning T cannot prove (as true or false) everything that can be stated in T. One could think that, therefore, we don't know whether the statement G(T) is true or false. Peter Smith adds that we can also recognize that, assuming T is consistent, then G(T) will be true. This /recognition/ is not backed up by T because T only asserts what it can --- and T cannot assert G(T). We may say we have a precise definition of a system of logic is, but we cannot say we have a precise definition of what mathematics is. What we can say is that if mathematics can be perfectly equated to logic, then we don't have any idea of what this system of logic would be to be equated to what we think mathematics is. |
| peteolcott <Here@Home>: Sep 09 06:05PM -0500 On 9/9/2019 3:38 PM, Mr Flibble wrote: >> All infinities are the same size. > Nonsense. Infinity doesn't have a size by definition. > /Flibble Congratulations your answer is more precisely accurate than mine. I did not provide the more precise answer because it would have been to much for the target audience to handle. So Cantor was not just wrong about differing cardinality he was dead wrong. One can count all of the (otherwise uncountable) real numbers by merely counting all of the adjacent geometric points on a number line. -- Copyright 2019 Pete Olcott All rights reserved "Great spirits have always encountered violent opposition from mediocre minds." Albert Einstein |
| David Brown <david.brown@hesbynett.no>: Sep 09 08:59AM +0200 On 08/09/2019 02:40, Ian Collins wrote: >> the exception is ever thrown in any particular codepath. > Surely the unwinding has to happen on function return whether you are > using exceptions or not? Without exceptions, code will need to call destructors as objects die. But the compiler knows when this will happen, and can re-order them, simplify them, combine them, or otherwise optimise them in the normal code path. When you have (table-driven) exceptions, you need tables to handle unwinding from any possible exception point, from any function along the way, including handling of partially created or partially destructed objects. That causes a big overhead in code tables, which is relevant for some systems. And it might also limit the compiler's ability to optimise normal flow constructors and destructors, and perhaps other code. |
| "Chris M. Thomasson " <chris.m.thomasson.1@gmail.com>: Sep 09 01:09AM -0700 On 9/3/2019 9:48 PM, Melzzzzz wrote: > Regarding error handling I disagree with previous post. Each function > can return discriminate union and Rust has sytnactic sugar for handling > errors. those that can overload the server should be catgut/caught by the shi% hits the fan receiver handler. In some really old code, some classes of errors would shift things into a state where everything would think about purging stale or old connections in the current state of the server. Dump the least used connections, to free up some state. |
| scott@slp53.sl.home (Scott Lurndal): Sep 09 04:35PM >> the exception is ever thrown in any particular codepath. >Surely the unwinding has to happen on function return whether you are >using exceptions or not? Not necessarily. Look at the difference in generated code between normally compiled C++ and C++ compiled with -fno-exceptions. >> longjmp back to the main loop. >Doing so will bypass any object destructors, so you would have been >restricted to the C with classes subset. Which is perfectly acceptable for high-performance code. Avoid dynamic allocation at run-time. >> code are rare; mainly when the stack limit is reached and more stack needs >> to be allocated by the OS to the application). >How long ago was this by the way? The original code was started using Cfront 2.1 circa 1990. The current version was developed further between 2008 and 2010 from the original codebase. >embedded project in the early 2000s due to performance issues that >aren't there in modern compilers. Exception performance has improved >significantly in recent years. The simluator codebase doesn't use dynamic allocation in threads which simulate the target processor core(s), so longjmp() works well and is highly reliable (the simulator, which boots the target operating system, runs with better performance than the final generation hardware (last gen was developed around 1990 using 10k ECL chips and sold for 2.8 Million)). It's run the target MCP (operating system) with a COBOL based workload in simulation for years with no failures (and no memory allocation issues, since all dynamic memory is allocated at application startup). The current ARMv8 SOC simulator I work on also avoids dynamic allocation in the threads which simulate the 64-bit ARM cores[*]. This doesn't, of course, run as fast as the target hardware, but it still boots SMP linux to the busybox prompt in less than 55 seconds. [*] Being a more modern codebase, albeit partially derived from the original, it does use C++ exceptions to handle detected exceptions when simulating instructions (e.g. AArch64 Data Aborts, Instruction Aborts, IRQs, FIQs, et alia). |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 02 10:53PM -0400 On 9/2/19 5:40 PM, Richard Damon wrote: > On 9/1/19 9:58 PM, woodbrian77@gmail.com wrote: >> On Sunday, September 1, 2019 at 2:39:57 PM UTC-5, Richard Damon wrote: ... >>> linkage between IEC559 and IEEE754 isn't inherently obvious. ... >>> even extend the error message to something more verbose, like >>> IEEE754/IEC559 Floating point assumed and needed >> I don't like having iec559 in there. If they want ... > The one purpose of IEC559 in the message is that that is what the > language calls it, so including it in the message might be useful. The language calls it that as an abbreviation for IEC/ISO/IEEE 60559, which is what IEC, ISO, and IEEE all call it. I'd normally provide a message using the unabbreviated name: "IEC/ISO/IEEE 60559 (== IEEE 754) floating point assumed and needed." |
| David Brown <david.brown@hesbynett.no>: Sep 03 08:25AM +0200 > a. remove the comment > b. reduce the comment to just "IEEE754", or > c. leave it as it is. The static_assert message is what users see when the assertion fails. That is your guide. If the check itself is information enough, you don't need a message. If it is not clear (perhaps users don't know what "is_iec559" means - but /would/ know what "IEEE format floating point" means), use a message. You can also use it to give more detail of /why/ the assertion is there - "IEEE floating point required to ensure binary compatibility", or "Only tested with IEEE floating point format". Then the user can get an idea of the reasoning for the assertion, and the consequences of removing it (will it break something, or is it merely untested?). |
| Keith Thompson <kst-u@mib.org>: Sep 03 12:35AM -0700 David Brown <david.brown@hesbynett.no> writes: [...] > The static_assert message is what users see when the assertion fails. > That is your guide. For certain values of "users". The message is seen when the code is compiled. For most software, most end users use precompiled executables. [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| David Brown <david.brown@hesbynett.no>: Sep 03 10:31AM +0200 On 03/09/2019 09:35, Keith Thompson wrote: > For certain values of "users". The message is seen when the code is > compiled. For most software, most end users use precompiled > executables. Yes. By "users", I mean "users of the source code" rather than "users of the resulting binaries". |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 02 03:55PM +0200 >> You're right. I will go to the psychotherapist because of that !!!!!!!!! > No, you won't. You will just be ignored. That's your hope because you want this to be sanctioned. But this won't fulfill. |
| David Brown <david.brown@hesbynett.no>: Sep 02 01:13PM +0200 On 02/09/2019 07:16, Bonita Montero wrote: >>> Maybe, but your style of response isn't mature. >> Neither is deliberately snipping attributions... > You're right. I will go to the psychotherapist because of that !!!!!!!!! No, you won't. You will just be ignored. |
| David Brown <david.brown@hesbynett.no>: Sep 02 10:02PM +0200 On 02/09/2019 15:55, Bonita Montero wrote: >> No, you won't. You will just be ignored. > That's your hope because you want this to be sanctioned. > But this won't fulfill. My hope is that you will understand the point of following the conventions of whatever type of discussion group, forum, etc., you are in - and start using proper Usenet quotations and attributions. It would be better for you, better for the group, and better for the threads you engage in. It won't make me agree with much of what you write, but it would make the threads more pleasant. |
| David Brown <david.brown@hesbynett.no>: Sep 02 09:58PM +0200 Please quote properly, without snipping attributions. On 02/09/2019 12:27, Frederick Gotham wrote: >> You shlouldn't catch this it is fatal error. > Are you saying that a 'map' object is unusable after a failed attempt to use 'at' ? I suspect he means that a failed "at" generally means you have a bug in your code as you are trying to access something that doesn't exist. So rather than catching the exception and trying to recover, you should use the exception information as an aid to finding and fixing the bug. |
| Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Sep 02 10:04PM -0600 On Mon, 2 Sep 2019 03:30:31 -0700 (PDT), Frederick Gotham > (double x); >I've tried a few different code beautifiers and none of them can turn this into a one-liner. >Anyone got a tool for this? Pipe the source files one at a time through: === #!/bin/bash perl -0777 -pe 's/(\w)\s*\n\s*(\()/$1$2/g' === It turns this: === int MyFunc1 (double x); int MyFunc1a (double x); int MyFunc2 (double x); void s1(void) { int a = 7 + (8); } void s2(void) { int a = MyFunc1 (8); } === into this: === int MyFunc1(double x); int MyFunc1a(double x); int MyFunc2 (double x); void s1(void) { int a = 7 + (8); } void s2(void) { int a = MyFunc1 (8); } === Try it. It might make things better. Or it might make them much, much worse. Louis |
| Juha Nieminen <nospam@thanks.invalid>: Sep 03 02:16PM > MyFunc > (double x); > I've tried a few different code beautifiers and none of them can turn this into a one-liner. What should happen if the names of the function and its parameters, and the types, are together so long that they would make the line overly long (like several hundreds characters long)? |
| Barry Schwarz <schwarzb@dqel.com>: Sep 02 11:25AM -0700 On Mon, 2 Sep 2019 03:30:31 -0700 (PDT), Frederick Gotham > (double x); >I've tried a few different code beautifiers and none of them can turn this into a one-liner. >Anyone got a tool for this? If you tell us which tools you have already tried, you might receive more useful responses. -- Remove del for email |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 02 08:32PM +0200 > int > MyFunc > (double x); I would acceppt any common style, but this is idiotic. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 03 07:15AM +0200 I just put everything together in one file. And as the benchmark is called with a function-pointer twice inteprocedural optimiza- tions aren't really needed anymore to prevent the compiler from optimizing away the throw. I compiled this with an older gcc and found, that gcc is about 42% faster when trowing an exception; and theres a big differnece to VC++ because it takes almost the same time cathing a derived exception than catching the base-exception. #include <iostream> #include <chrono> #include <exception> using namespace std; using namespace std::chrono; struct ExcBase : public exception { }; struct ExcDerivedA : public ExcBase { }; struct ExcDerivedB : public ExcDerivedA { }; typedef long long LL; void BaseThrower(); void DerivedBThrower(); LL Benchmark( void (*thrower)(), unsigned const rep ); int main() { unsigned const REP = 1'000'000; LL ns; ns = Benchmark( BaseThrower, REP ); cout << "BaseThrower: " << (double)ns / REP << "ns" << endl; ns = Benchmark( DerivedBThrower, REP ); cout << "DerivedBThrower: " << (double)ns / REP << "ns" << endl; } LL Benchmark( void (*thrower)(), unsigned const rep ) { time_point<high_resolution_clock> start = high_resolution_clock::now(); for( unsigned i = rep; i; --i ) try { thrower(); } catch( ExcBase & ) { } return (LL)duration_cast<nanoseconds>( high_resolution_clock::now() - start ).count(); } void BaseThrower() { throw ExcBase(); } void DerivedBThrower() { throw ExcDerivedB(); } |
| 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