Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.misc Subject: data types for money (was Who uses BASIC these days) Message-ID: <17661@mimsy.UUCP> Date: 22 May 89 00:38:47 GMT References: <11581@well.UUCP> <960018@hpclskh.HP.COM> <832@cbnewsc.ATT.COM> <10499@ihlpb.ATT.COM> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 34 In article <10499@ihlpb.ATT.COM> res@ihlpb.ATT.COM (Rich Strebendt) writes: >Use of integers (even considering only the case of US money amounts) to >scale money to cents (eg: $100 = 10000 cents) limits you to values >less than about $43 million. No: if you use unsigned or, more likely, signed, 16 bit arithmetic, the limits are 655.35 and 327.67 respectively; if you use 32 bit arithmetic, the limits are 42 949 672.95 and 21 474 836.47; but if you see reason and use 128 (or---if you really need them---256) bit integers, the limits are (signed only) 170141183460469231731687303715884105727 and 57896044618658097711785492504343953926634992332820282019728792003956564819967 cents respectively. >... (the value of stock shares to five decimal places, for example) ... can be up to 10^33 with only 16 bytes. (You only get 10^27 with BCD.) For dollars, a mere 64 bit integer can easily hold the U. S. national debt (in pennies). You need 15 digits to count (in pennies) to $2 trillion, which also takes eight bytes. >Floating point, of course, avoids the above problem, but suffers from loss of >precision as the poster above points out. Loss of precision can be disastrous >when dealing with other people's money!!! Indeed. >The way commercial data processing machines and languages solved this problem >was through the use of (to use IBM terminology) packed decimal representations >and arithmetic units. ... which is slower than large-field binary arithemetic. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris