Hmmm...according to my math... Max 64-bit unsigned integer is 18446744073709551615
Drop the last digit as it can't hold 0-9 1844674407370955161 Make two decimal positions 18446744073709551.61 Now some commas so we can see better 18,446,744,073,709,551.61 That' $18 quadrillion dollars by my math. If you want 1/1000's it's $180 trillion Get rid of the pennies and you can get $1.8 quintillion Is there a use for tracking 1/1000th's of a dollar at these amounts? Newer gcc's have 128-bit ints for 64-bit platforms (but not 128-bit constants). Michael D. Black Senior Scientist NG Information Systems Advanced Analytics Directorate ________________________________________ From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Nico Williams [n...@cryptonector.com] Sent: Wednesday, March 23, 2011 1:44 PM To: General Discussion of SQLite Database Subject: EXT :Re: [sqlite] storing big numbers into NUMERIC, DECIMAL columns On Wed, Mar 23, 2011 at 1:30 PM, Igor Tandetnik <itandet...@mvps.org> wrote: > On 3/23/2011 1:46 PM, TR Shaw wrote: >> Current US national debt is 16 digits. > > A 64-bit unsigned integer can represent about $18 trillion, in > millionths of a dollar. This should have both range and accuracy to > spare, for most applications, but you can always trade one for the other > (e.g. use units of 1/1000 of a dollar instead, for a 100 times greater > range). I made the same point, but that doesn't leave much of a comfort zone. First of all, totaling up all assets and liabilities in the U.S. economy, including pension funds, Social Security, Medicare, etcetera, quickly gets you numbers larger than $100 trillion. Second, a few more decades like the last few and 2^63 will not suffice to total up all of those numbers using 1/1,000th of a dollar as the unitm yet without significant inflation a cent will still be the absolute smallest unit we'll get by with. Third, any bout of hyperinflation (which some worry about) will mean that for a fairly long period of time people will need a very large range to represent monetary amounts with 1/1,000th of a dollar as the unit -- even if it doesn't happen (and let us hope it doesn't), the range is getting uncomfortably small. So, yeah, 64-bit integers are a bit too small for representing monetary amounts. By the time this becomes critical I'm sure SQLite will no longer be quite so light, and will have grown bignum support :) But now is a good time to start asking whether 64-bit integers will do, and for how long. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
