- display output larger than 65536 - 14 Updates
- "In defense of printf" - 11 Updates
| "Öö Tiib" <ootiib@hot.ee>: Dec 16 03:47PM -0800 On Tuesday, 16 December 2014 23:34:23 UTC+2, mathewji wrote: > rice = rice * rice; > } > } Guaranteed available range for 'int' is -32767 to 32767 (beaten at 6th iteration of your loop) and for 'long long' it is -9223372036854775807 to 9223372036854775807 (beaten at 8th iteration) you will also run out of limits of 'double' at 12th iteration (despite C++ does not specify it). So there you are. C++ does not contain any arbitrary precision numeric types but you can search web for "arbitrary precision C++". You will find several open source implementations of various quality. Most can deal with multiplying values that have millions of numbers. |
| "Öö Tiib" <ootiib@hot.ee>: Dec 16 03:59PM -0800 On Wednesday, 17 December 2014 01:47:52 UTC+2, Öö Tiib wrote: > search web for "arbitrary precision C++". You will find several open > source implementations of various quality. Most can deal with > multiplying values that have millions of numbers. Meant "millions of digits". Digit is "number" in Estonian so I mix the words up now and then. |
| David Harmon <source@netcom.com>: Dec 16 04:59PM -0800 On Tue, 16 Dec 2014 13:57:56 -0800 (PST) in comp.lang.c++, mathewji <itoneymathew@gmail.com> wrote, >Made the change. I can't get rice to display larger than 4,294,967,296. See: >vector <signed long long int> squares; And what is the lesson you have learned from all this? How many bits long would a integer variable have to be to hold your final answer? |
| Nobody <nobody@nowhere.invalid>: Dec 17 05:38AM On Tue, 16 Dec 2014 17:06:59 -0500, Victor Bazarov wrote: > Use Google to search for "arbitrary precision integer" and use some > library, there are probably open source ones out there. Boost.Multiprecision: http://www.boost.org/doc/libs/1_57_0/libs/multiprecision/doc/html/index.html |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 17 06:59AM On Tue, 2014-12-16, 嘱 Tiib wrote: >> multiplying values that have millions of numbers. > Meant "millions of digits". Digit is "number" in Estonian so I mix > the words up now and then. We have distinct words for them in Sweden ("tal", "siffra"), but I still mix them up ... /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Paul N <gw7rib@aol.com>: Dec 17 07:15AM -0800 On Tuesday, 16 December 2014 21:34:23 UTC, mathewji wrote: > rice = rice * rice; > } > } I believe the answer you are actually searching for is "several times the world's entire annual rice harvest, so not a bad reward for inventing chess". |
| Victor Bazarov <v.bazarov@comcast.invalid>: Dec 17 10:49AM -0500 On 12/17/2014 10:15 AM, Paul N wrote: > I believe the answer you are actually searching for is "several times > the world's entire annual rice harvest, so not a bad reward for > inventing chess". Just to make sure I understand the reference... In that tale the number of [rice] kernels was doubled every iteration, not squared, yes? V -- I do not respond to top-posted replies, please don't ask |
| red floyd <no.spam@its.invalid>: Dec 17 09:46AM -0800 > rice = rice * rice; > } > } I believe your problem lies in your loop index. You only go up to 2**15. Why would you expect to see anything else? |
| Victor Bazarov <v.bazarov@comcast.invalid>: Dec 17 01:27PM -0500 On 12/17/2014 12:46 PM, red floyd wrote: >> } > I believe your problem lies in your loop index. > You only go up to 2**15. Why would you expect to see anything else? Check again. Hint: he's not multiplying by 2... :-) V -- I do not respond to top-posted replies, please don't ask |
| scott@slp53.sl.home (Scott Lurndal): Dec 17 07:17PM >> I believe your problem lies in your loop index. >> You only go up to 2**15. Why would you expect to see anything else? >Check again. Hint: he's not multiplying by 2... :-) Problem #1: Storing a "signed long long int" in a vector of "int" will lose precision. Problem #2: 2^16 squared is 2^32, which won't fit in a signed "int", so problem #1 bites such that squares[6] gets zero instead of 2^32. Problem #3: 2^32 squared is larger than a 'signed long long int' and thus overflow occurs on the 8th loop iteration. Problem #4: The problem statement likely requested the squares of the first 16 positive integers, in which case "push_back((i+1)*(i+1)" was probably the intended code and the rice variable is unnecessary. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 17 08:59PM On Wed, 2014-12-17, Victor Bazarov wrote: >> inventing chess". > Just to make sure I understand the reference... In that tale the number > of [rice] kernels was doubled every iteration, not squared, yes? Yes. http://en.wikipedia.org/wiki/Wheat_and_chessboard_problem /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Vincenzo Mercuri <nomail@yahoo.it>: Dec 17 10:44PM +0100 > rice = rice * rice; > } > } Boost.Multiprecision provides the header-only type 'cpp_int' for multiprecision integers: #include <iostream> #include <vector> #include <boost/multiprecision/cpp_int.hpp> using namespace boost::multiprecision; std::vector<cpp_int> squares; int main() { cpp_int rice = 1; for(int i = 0; i < 15; ++i) { squares.push_back(rice); std::cout << squares[i] << std::endl; if(rice == 1) rice = 2; else rice *= rice; } } (sorry, I didn't wrap the output lines on purpose) $./main 1 2 4 16 256 65536 4294967296 18446744073709551616 340282366920938463463374607431768211456 115792089237316195423570985008687907853269984665640564039457584007913129639936 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084096 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 32317006071311007300714876688669951960444102669715484032130345427524655138867890893197201411522913463688717960921898019494119559150490921095088152386448283120630877367300996091750197750389652106796057638384067568276792218642619756161838094338476170470581645852036305042887575891541065808607552399123930385521914333389668342420684974786564569494856176035326322058077805659331026192708460314150258592864177116725943603718461857357598351152301645904403697613233287231227125684710820209725157101726931323469678542580656697935045997268352998638215525166389437335543602135433229604645318478604952148193555853611059596230656 1044388881413152506691752710716624382579964249047383780384233483283953907971557456848826811934997558340890106714439262837987573438185793607263236087851365277945956976543709998340361590134383718314428070011855946226376318839397712745672334684344586617496807908705803704071284048740118609114467977783598029006686938976881787785946905630190260940599579453432823469303026696443059025015972399867714215541693835559885291486318237914434496734087811872639496475100189041349008417061675093668333850551032972088269550769983616369411933015213796825837188091833656751221318492846368125550225998300412344784862595674492194617023806505913245610825731835380087608622102834270197698202313169017678006675195485079921636419370285375124784014907159135459982790513399611551794271106831134090584272884279791554849782954323534517065223269061394905987693002122963395687782878948440616007412945674919823050571642377154816321380631045902916136926708342856440730447899971901781465763473223850267253059899795996090799469201 774624817718449867455659250178329070473119433165550807568221846571746373296884912819520317457002440926616910874148385078411929804522981857338977648103126085903001302413467189726673216491511131602920781738033436090243804708340403154190336 1090748135619415929462984244733782862448264161996232692431832786189721331849119295216264234525201987223957291796157025273109870820177184063610979765077554799078906298842192989538609825228048205159696851613591638196771886542609324560121290553901886301017900252535799917200010079600026535836800905297805880952350501630195475653911005312364560014847426035293551245843928918752768696279344088055617515694349945406677825140814900616105920256438504578013326493565836047242407382442812245131517757519164899226365743722432277368075027627883045206501792761700945699168497257879683851737049996900961120515655050115561271491492515342105748966629547032786321505730828430221664970324396138635251626409516168005427623435996308921691446181187406395310665404885739434832877428167407495370993511868756359970390117021823616749458620969857006263612082706715408157066575137281027022310927564910276759160520878304632411049364568754920967322982459184763427383790272448438018526977764941072715611580434690827459339991961 41424274141059911742606055648376375631452761136265862838336862115799363802087853767554533678991569423443395566631507008721353547025567031200413072549583450835743965382893607708097855057891296790735278005493562156109079584517295411597292747987752773856000820411855893000477774872776185381351049384058186159865221160596030835640594182118971403786872621948149872760365361629885617482241303348543878532402475141941718301228107820972930353737280457437209522870362277636394529086980625842235514850757103961938744962986680818876966281577815307939317909314364834076173858181956300299442279075495506128881830843007964869323217915876591803556521615711540299212027615560787310793747746684152836298770869945015203123186259420308569383894465706134623670423402682110295895495119708707654618662279629453645162075650935101890602377382153953277620867697858973196633030889330466516943618507835064156833694453005143749131129883436726523859540490427345592872394952522718461740436785475461047437701976802557660588103807< br /> 7270707717942221977090385438585844095492116099852538903974655703943973086090930596963360767529964938414598185705963754561497355827813623833288906309004288017321424808663962671333528009232758350873059614118723781422101460198615747386855096896089189180441339558524822867541113212638793675567650340362970031930023397828465318547238244232028015189689660418822976000815437610652254270163595650875433851147123214227266605403581781469090806576468950587661997186505665475715792896 -- Vincenzo Mercuri |
| red floyd <no.spam@its.invalid>: Dec 17 02:13PM -0800 On 12/17/2014 10:27 AM, Victor Bazarov wrote: >> I believe your problem lies in your loop index. >> You only go up to 2**15. Why would you expect to see anything else? > Check again. Hint: he's not multiplying by 2... :-) Oops. You're right, he's doing 2**(2n) |
| red floyd <no.spam@its.invalid>: Dec 17 02:15PM -0800 On 12/17/2014 2:13 PM, red floyd wrote: >> On 12/17/2014 12:46 PM, red floyd wrote: >> Check again. Hint: he's not multiplying by 2... :-) > Oops. You're right, he's doing 2**(2n) Oops. 2**(2**n) |
| "Öö Tiib" <ootiib@hot.ee>: Dec 16 06:04PM -0800 On Tuesday, 16 December 2014 23:42:08 UTC+2, Ian Collins wrote: > For built in types, yes but once you start to use user defined types all > of that is lost. Even printing something as mundane as std::complex > becomes a mess. Nah neither the 'printf' nor 'cout' can format any numbers. It is pointless to discuss it in Usenet however because the Usenet clients are written mostly by fans of 'printf' and some by fans of 'cout'. So these can barely show ASCII with errors, no point to talk of any numerical data like "6.78×10⁻¹⁶" (typed 6.78 times 10 to -16 there but it will likely not show up). |
| Ian Collins <ian-news@hotmail.com>: Dec 17 03:14PM +1300 Öö Tiib wrote: > barely show ASCII with errors, no point to talk of any numerical data > like "6.78×10⁻¹⁶" (typed 6.78 times 10 to -16 there but it will likely > not show up). Looks fine in Thunderbird :) -- Ian Collins |
| Melzzzzz <mel@zzzzz.com>: Dec 17 03:28AM +0100 On Tue, 16 Dec 2014 18:04:51 -0800 (PST) > these can barely show ASCII with errors, no point to talk of any > numerical data like "6.78×10⁻¹⁶" (typed 6.78 times 10 to -16 there > but it will likely not show up). It shows in my client :p |
| legalize+jeeves@mail.xmission.com (Richard): Dec 17 02:53AM [Please do not mail me a copy of your followup] Christopher Pisz <nospam@notanaddress.com> spake the secret code >In my case, it has shown 80% of all bugs over my career have been traced >back to C style programming from programmers with the same mentality you >so blindly cling on to. I'll second this general observation. Every time I meet a programmer who loves Java or C# and they talk about how C++ is error-prone I ask them to show me the C++ code they are having trouble with. Every single time it is C code masquerading as C++ code. It is full of char* strings, <string.h> calls and <stdio.h> calls. When I show them modern C++11 code, they act as if they have never seen it before (probably because they haven't). However, this is not a new phenomenon. In the early 1990s Stroustrup was cautioning us against C-style code and asking us to write C++ instead. People weren't listening and were writing C-style code and having trouble. When I joined a team using VC6 in the late 1990s, I asked them why they were still using fixed size char buffers for strings, printf, malloc, etc. It turned out that noone had ever taught them the C++ Standard Library. A coworker and myself embarked on an internal training program to teach the majority of the C++ Standard Library to our team: strings, iterators, containers and algorithms being the core focus. We used Nicolai Josuttis's book "The C++ Standard Library" as our study guide. My coworker and I alternated presenting every week and we worked our way through the majority of the standard library in a couple of months. After that, entire categories of bugs relating to these error-prone C-style habit disappeared. We could stop worrying about strange bugs caused by poor programming habits and focus on the problem domain. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| "Öö Tiib" <ootiib@hot.ee>: Dec 17 01:06AM -0800 On Wednesday, 17 December 2014 04:28:50 UTC+2, Melzzzzz wrote: > > numerical data like "6.78×10⁻¹⁶" (typed 6.78 times 10 to -16 there > > but it will likely not show up). > It shows in my client :p Great. So that is the natural scientific notation instead of "6.78e-16". "6.78e-16" was indeed good idea at times of ALGOL 68, but how to call it "modern"? |
| scott@slp53.sl.home (Scott Lurndal): Dec 17 02:58PM >Maybe you are actually working in a C shop and no one told you. You only >noticed something peculiar when you hired someone whom was born after >1960, but most likely canned them for not following your ancient traditions. DAGS "High Horse" |
| scott@slp53.sl.home (Scott Lurndal): Dec 17 03:01PM >argument types have to be resolved at runtime with explicit casts in >va_arg. An efficient version of printf for C++ would be based on >variadic templates where types are known at compile time. Having written the guts to handle variadic printf compatible formatting (for a bare-metal hypervisor, as it happens), I don't agree. In most cases the arguments are simply cast to the appropriate type based on the format character, and the cast operation is usually optimized out since the underlying data format is 64-bit scalar (32-bit on 32-bit processors). |
| Mike Austin <nospam@null.net>: Dec 17 12:28PM -0800 On 12/17/14, 7:01 AM, Scott Lurndal wrote: > variadic templates Sorry to be such a lurker, but I stumbled upon the wikipedia variadic template page, which gives a good example of a type-safe printf: http://en.wikipedia.org/wiki/Variadic_template |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 17 08:54PM On Wed, 2014-12-17, Scott Lurndal wrote: > Christopher Pisz <nospam@notanaddress.com> writes: ... >>noticed something peculiar when you hired someone whom was born after >>1960, but most likely canned them for not following your ancient traditions. > DAGS "High Horse" That horse is not very high ... from my perspective, you have a history of complaining about C++ features which the rest of us accepted decades ago[1]. That Christopher assumes that you're programming in an extremely limited and C-like subset of C++, should come as no surprise. /Jorgen [1] E.g. upthread, it looked like you still see operator<< () as a bit-shift operator. -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Dec 17 09:55PM +0100 On 16.12.14 17.30, Christopher Pisz wrote: > I don't mind if C programmers unite, but don't do it pretending to be > C++ programmers and don't outright lie. > Far more readable? Far more usable? Are you kidding me? There are good reasons why almost /every/ language has some concept of format strings with placeholders and format info. Think of Java, .NET, php, Perl ... C++ does not have such a concept in the standard, except for the printf derived from C, of course. Intercepting typically smaller string constants with (longer) C++ expressions is for sure not well readable. Marcel |
| Ian Collins <ian-news@hotmail.com>: Dec 18 09:57AM +1300 Mike Austin wrote: > Sorry to be such a lurker, but I stumbled upon the wikipedia variadic > template page, which gives a good example of a type-safe printf: > http://en.wikipedia.org/wiki/Variadic_template The problem I see with these simple examples is there isn't any connection between the format string and the arguments. The fundamental task of parsing the string (to extract width and other formatting information) tends to be conveniently ignored. Try printf( "%d %2f\n", "hello", "there" ); with the example on that page.... -- Ian Collins |
| 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