- Floating point accuracy (was Re: [mildly off-topic] Valgrind and rounding errors) - 3 Updates
- Switching to C# - 4 Updates
- xor the elements of two vectors - 5 Updates
- does c++ initialize char arrays with '\0's - 1 Update
| Juha Nieminen <nospam@thanks.invalid>: Jun 12 09:05AM > Floating point calculations are very accurate, often more than integer > calculations. But floating point calculations are more difficult to > understand. I think there's a bit of ambiguity about what is meant by "accuracy" here. Pretty much all modern hardware implement the IEEE standard when dealing with floating point values, and AFAIK that standard defines very meticulously and unambiguously what the result of every operation must be with given input values, bit-by-bit. If you know these definitions, you know *exactly* what the result of an operation, with given values, will be, to the last bit of it. There's no fuzziness here. Also, "inaccuracy" may lead one to believe that the result might vary randomly even with the same input. Obviously that's not the case. The result will always be the same. But here the term is most probably used with the meaning "you can't represent the result of many operations completely exactly, and there will often be rounding errors." As an example 1.0 and 3.0 can both be represented with complete accuracy, but the result of 1.0/3.0 cannot, and will have a small rounding error (because 1/3 is not representable completely accurately with floating point). However, one could think of it as no different than operations applied to ints not being always representable. If, for example, you multiply two ints, and the result is too large, the end result will not be accurate, for the mere reason that the variable type doesn't have enough bits to represent it accurately. This is no different from floating point: It, too, doesn't have enough bits to represent every possible value accurately. It's just that when people say "floating point is inaccurate", it's often said with some kind of implication that integer variables do not suffer from this same problem. Even though they do. *All* mathematic operations done on computers is inaccurate in some cases in one way or another. Pointing to floating point in particular is a bit misleading. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 12 08:49AM -0400 On 6/12/19 5:05 AM, Juha Nieminen wrote: ... > with floating point values, and AFAIK that standard defines very > meticulously and unambiguously what the result of every operation must > be with given input values, bit-by-bit. No, it does not. In general, it allows for either the representable value closest to the mathematical value of an expression, or one of the two representable values immediately preceding and immediately following that value, and it does not require that the choice be consistent. > If you know these definitions, > you know *exactly* what the result of an operation, with given values, > will be, to the last bit of it. There's no fuzziness here. Yes there is. The fuzziness is only 1 ulp, but it is there. > Also, "inaccuracy" may lead one to believe that the result might vary > randomly even with the same input. Obviously that's not the case. The > result will always be the same. It's not required to be, not even by the IEEE standard. > for the mere reason that the variable type doesn't have enough bits to > represent it accurately. This is no different from floating point: It, too, > doesn't have enough bits to represent every possible value accurately. The key difference is that the only unrepresentable integer values are those outside the range of representable integer values. An infinite number of unrepresentable real numbers separate every single consecutive pair of numbers that can be represented in floating point. |
| Keith Thompson <kst-u@mib.org>: Jun 12 03:48PM -0700 > On 6/12/19 5:05 AM, Juha Nieminen wrote: [...] > those outside the range of representable integer values. An infinite > number of unrepresentable real numbers separate every single consecutive > pair of numbers that can be represented in floating point. Agreed. One might argue that, for example, the fact that 4/3 yields 1 means the result is inaccurate. The way I'd describe it is that 1 is the correct result for that operation (which is integer division, not real division). It does lose some information, but that's why we have the % operator and the div, ldiv, and lldiv library functions. -- 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 */ |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 12 11:01AM -0400 All, I'll never leave C/C++, but having had occasion recently to use C# recently I will be leaving these groups for daily monitoring, for major new development and related activity. I'll only be back here periodically. I've enjoyed and appreciated the help you've given me over the years. My skills have improved by your input and tutelage, and I owe specific knowledge to certain people (Ben for understanding the term "discriminating union," for example). There are several people here I will miss, and I wish all of you well. Take care. -- Rick C. Hodgin |
| Szyk Cech <szykcech@spoko.pl>: Jun 12 05:32PM +0200 Hi! > I'll never leave C/C++, but having had occasion recently to use C# > recently It is clear to me that God leaves you. C++ is the best portable, objec oriented and compileable language as of today. I can tell you in secret that: God encourage me to perform some misson on Earth and promises help me dialy as long as I will not criticise him. One of his influence was my "self" development (in days when I don't know much about programming and whole Computer Science). So: some how I decided at first to learn binary nuber system and then Asembler to know how computers work, next I decided to learn straight C++ (and C as part of it), then I learn Sql databases. Every of these I learn in so success full way so I be able to get work as programmer just after technical high school (in spite of that I was very proly educated electronic). Now few words abotu your "mind dissabled" "discovery" called: C#. How can you tell it is better than C++? It has virtual machine (VM) writen in C++. True wise programmers write in C++ because it is fast and this is freedom of life and expressions. So M$ programmers write in C++ and only they marketings believe that some other programmers are so stupid to adict to M$ specific language, and by desing slow down by VM. The same you can tell about Java. Another use full wisdom: 80% of language power lies in his libraries. So don't tell me that some thing is imposible for C++ or easiest in C# - this is matter of libraries only! Qt shows that C++ is able to be comfortable for programmer (however they betrayed C++ in flavor they own "mind dissabled" "discovery" called Qml == JavaScript variant). More thinking and less stupidity! best regards Szyk Cech |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 12 12:04PM -0400 On 6/12/2019 11:32 AM, Szyk Cech wrote: > ...C++ is the best portable, objec > oriented and compileable language as of today. C++ is desirable in many ways, but not all ways. Many programming tasks do not require maximum performance, but only adequate performance, and instead do require high productivity for developers. If you write business apps, writing them in Visual Basic is probably completely adequate for 98% of them, and that's a lot of applications and a lot of business in the U.S.A., for example. > these I learn in so success full way so I be able to get work as programmer > just after technical high school (in spite of that I was very proly educated > electronic). I started in assembly and XBASE, then went to C, later C++ and extended XBASE languages like Visual FoxPro (an object-oriented version of XBASE). I've branched out to various other languages over the years, but more or less my daily development has been C/C++ and VFP, along with some Java. > Now few words abotu ... C#. > How can you tell it is better than C++? I never said it was better. It's more productive. > marketings believe that some other programmers are so stupid to adict to M$ > specific language, and by desing slow down by VM. The same you can tell about > Java. I write in multiple languages. Even when I wrote Java, I wrote many functions in C++ using JNI. And I've discovered in C# that there are delegate functions and marshaling abilities which allow me to transfer C# types and receive them in C++ DLLs as other types. Visual Studio even allows me to do native debugging (switching between C# code into a C++ function, and be able to STEP-INTO that C++ function, or if there is a delegate callback from C++ into C#, to STEP-INTO that C# function). It's a very powerful language, mature, and it has strong familiarity due to its C/C++ derivation. > matter of libraries only! Qt shows that C++ is able to be comfortable for > programmer (however they betrayed C++ in flavor they own "mind dissabled" > "discovery" called Qml == JavaScript variant). For business apps, C# has WinForms and a forms designer IDE for rapid form development. It has a huge host of library support, and a wide range of examples online in how to code. In less than a week I took my Visual FreePro, Jr. database engine and created a class in C# that integrates every function in a way that exposes that data natively in a way that's easy to use. It's proven to be a most effective language, and one which interoperates in every needful way with existing C/C++ code. You can even use pointers in C# in unsafe code blocks, and native structure types. It allows non- forward declaration use of all types. It removes many hurdles seen in C/C++ code in my experience. And the fact that it runs in a VM means I can write it once and run it on any machine (save the machine-native DLL support, which would be fairly easily re-compiled anyway). > More thinking and less stupidity! I would like to suggest a couple things for you to think about: First, it's not a good idea to criticize people's faith in God, but only to bring to the individual's attention those things they do which do not align with the requirements of God, either in their faith (as being a hypocrite), or if they believe in something that you don't believe in, to challenge them to examine their religion and see if it truly pro- vides what they think it provides. Second, you seem to think that because I made the decision to leave CLC and CLC++ as my primary focus in USENET that I am somehow abandoning C/C++ development, or that I had not given it any thought in making the switch. I will never leave C/C++. I have hundreds of thousands of lines of code I've personally written in it. Well-debugged, well-in-use daily code that I have no intention of re-writing. However, I have a need to move on from Visual FoxPro. Moving into C# is a natural progression given my skillset, and it's one I'm happy to pursue. -- Rick C. Hodgin |
| gazelle@shell.xmission.com (Kenny McCormack): Jun 12 04:30PM In article <qdr3vq$c0e$1@dont-email.me>, >recently I will be leaving these groups for daily monitoring, for >major new development and related activity. I'll only be back here >periodically. Oh no!!!!! Where we will get our daily dose of religious bullshit from??? How will we ever survive? Who will step up to fill the void? -- 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/ModernXtian |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jun 11 11:32PM -0700 On 6/5/2019 5:02 PM, bitrex wrote: > I think this can be done with a lambda function? and a mapping function > on the vectors but don't immediately know the procedure I would use. > Thank you Take some vectors, any vectors... convert them to pixels with integers in the 2d pixel plane. On or off plane, Xor each component together... convert them back, PLOT. Can do! Or, is this way off topic? |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jun 12 12:36AM -0700 On 6/11/2019 11:32 PM, Chris M. Thomasson wrote: > Take some vectors, any vectors... convert them to pixels with integers > in the 2d pixel plane. On or off plane, Xor each component together... > convert them back, PLOT. Can do! Or, is this way off topic? Humm... I need to try this for fun. I just want to see the darn visual result! :^) |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jun 12 12:41AM -0700 On 6/12/2019 12:36 AM, Chris M. Thomasson wrote: >> convert them back, PLOT. Can do! Or, is this way off topic? > Humm... I need to try this for fun. I just want to see the darn visual > result! :^) Start with an even number of, say, complex numbers, in a shape... Project them all the way down to the integer pixel realm, so final 2d vectors in a sense... Xor their components together. Plot the origin pixel and the xored pixel, and perhaps move them back to the complex plane and perform some other fun stuff... |
| Juha Nieminen <nospam@thanks.invalid>: Jun 12 08:54AM > generally annoys me when people try to do exactly the same by hand (and > usually less well and obscurely). People often seem to do this through > ignorance. In the case of xorring the elements of two vectors into a third vector it's a matter of opinion which way is clearer and easier to read and understand. One could argue that most programmers are more accustomed to seeing and understanding explicit for-loops, especially those that are a two-liner (like in this case), than a more unusual call to a standard library function (that, at a very quick glance, doesn't even look like a loop at all, until you start reading the details). Of course this is more a matter of what the programmer is accustomed to. The original poster might have not had execution speed in mind when he asked the question (even though he used the word "efficient", but I get the feeling he used that word to mean something else than execution speed; maybe something like "efficient in terms of amount of source code", or perhaps "efficient in terms of readability", or something along those lines?) However, a "manual" implementation might allow for some low-level optimizations that are in no way guaranteed to be done by std::transform. Assume that this particular task needs to be done as efficiently as the hardware just can do it, squeezing every possible clock cycle away from it, achieving as much throughput as is available (while still keeping it fully standard C++). One method that even many experienced C++ programmers aren't aware of, and haven't studied, is SIMD vectorization. Modern compilers can be surprisingly good at generating vectorized SSE code (or whatever the equivalent is in the target architecture, like ARM64), but in many cases you need to "help" the compiler a bit. For example, if you are doing a simple operation like this to a very large amount of ints, for instance, it can become much faster if you do it to 8 ints in an inner loop at once. In other words, rather than just write the simple singular loop, you write an inner loop that simply does the operation to 8 elements. There's a very high chance that the compiler will optimize that inner loop into a single SSE instruction that does the operation to all 8 elements at once. If the compiler was not already doing this with the simple loop, the result may speed up by well over a factor of 2. |
| usenet@stegropa.de (Stefan Große Pawig): Jun 12 06:13PM +0200 > element-wise the objects contained in two std::vectors, and stuff the > resultant values into new vector of the same length as the original > two. If the use of std::vector is not set in stone, you could also check std::valarray. It provides this kind of functionality out of the box. --- 8< --- #include <valarray> #include <iostream> #include <iomanip> int main() { const std::valarray<int> x{ 0x00, 0x33, 0x55, 0xff }; const std::valarray<int> y{ 0x11, 0x11, 0x11, 0x11 }; const std::valarray<int> z = x ^ y; for (auto d : z) std::cout << std::hex << d << "\n"; } --- >8 --- -Stefan |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 11 10:32PM -0400 On 6/11/19 11:02 AM, Chris Vine wrote: > meaning 1). > I would further argue that the word "static" has acquired a fifth > meaning in C++, in the sense of "resolvable at compile time". The I was talking about the meanings of the "static" keyword. The word "static" itself does indeed have several additional meanings that don't involve it's use as a keyword, which only adds to the potential for confusion. |
| 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