Adding int to a float
in [Java Help]
|
From: Arne Vajhøj on 18 Sep 2009 20:19 Martin Gregorie wrote: > If you're doing financial calculations you should always use integer > arithmetic because this avoids nasty surprises due to the inability of > floating point to accurately represent all possible values. This also > applies to currency conversion. All FX dealing institutions and markets > specify precisely how to handle the conversion: using floating point > doesn't figure in their rules. > > All reputable financial software uses integers with monetary values held > in the smallest legal unit in the currency (cents in $US and Euros, pence > in the UK). I think integers needs to be interpreted broad here. If it covers binary integers and BCD with either application managed decimal or encapsulated in the data type decimal, then I agree. But money is definitely not always store in datatypes equivalent to Java int. Arne
From: Arne Vajhøj on 18 Sep 2009 20:24 Martin Gregorie wrote: > On Fri, 18 Sep 2009 15:21:04 -0700, Patricia Shanahan wrote: >> 2. In some cases, the required rounding rules exactly match one of the >> BigDecimal rounding schemes. In that case, I would consider BigDecimal >> for convenience with the scale factor equal to the correct number of >> digits after the decimal point. >> > I agree. BigDecimal is an equally valid alternative to integers. > > IBM would agree too, since their smaller S/360 mainframes (and maybe the > earlier 1400s as well) couldn't handle integer values. They worked > entirely in BCD, which is a more or less exact equivalent to BigDecimal. Functionally. BigDecimal uses BigInteger and BigInteger is using a binary representation. Arne
From: Martin Gregorie on 19 Sep 2009 05:31 On Fri, 18 Sep 2009 20:24:24 -0400, Arne Vajhøj wrote: > Martin Gregorie wrote: >> On Fri, 18 Sep 2009 15:21:04 -0700, Patricia Shanahan wrote: >>> 2. In some cases, the required rounding rules exactly match one of the >>> BigDecimal rounding schemes. In that case, I would consider BigDecimal >>> for convenience with the scale factor equal to the correct number of >>> digits after the decimal point. >>> >> I agree. BigDecimal is an equally valid alternative to integers. >> >> IBM would agree too, since their smaller S/360 mainframes (and maybe >> the earlier 1400s as well) couldn't handle integer values. They worked >> entirely in BCD, which is a more or less exact equivalent to >> BigDecimal. > > Functionally. > Fair point. > BigDecimal uses BigInteger and BigInteger is using a binary > representation. > Interesting. I've not looked at the code, but just assumed both would operate on a list of digits and a sign. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Martin Gregorie on 19 Sep 2009 06:05 On Fri, 18 Sep 2009 20:19:14 -0400, Arne Vajhøj wrote: > I think integers needs to be interpreted broad here. > > If it covers binary integers and BCD with either application managed > decimal or encapsulated in the data type decimal, then I agree. > Of course - integer but independent of representation. > But money is definitely not always store in datatypes equivalent to Java > int. > Sure, but the internal representation doesn't affect the rules of integer arithmetic. COBOL is a good example, since most dialects let you choose whether a value is held as an int, a BCD value or a fixed length character string. All these representations obey the same arithmetic rules. If the number is an exact monetary amount its been held, in all the financial systems I've worked on, as an integer value representing a multiple of the smallest item that can be legal tender (cents in the USA, pennies in the UK[*]). This has covered pure accounting systems in a single currency, multi-currency accounting, FX and secure financial networks running on everything from various mainframes through AS/400, UNIX and fault tolerant systems. Note that prices are usually more complex than this, since low value items may be priced in fractional cents/pennies. [*] when the UK changed to decimal currency it screwed things up so badly that the smallest unit was a half-penny - that is what you get by retaining the pound but dividing it into 100 new pennies in place of 240 old pennies. All sensible countries, Canada, Australia, New Zealand, dumped the pound in favour of a dollar (1 pound became 2 dollars) so the cent was similar in value to the penny it replaced. The UAE had a similar problem when they decimalised. Their older currency was subdivided into powers of 2, rather like the Indian Rupee which subdivided into 16 annas and 64 paise. The decimal currency unit is the relatively large dirham, which was initially 1000 fils. These days inflation has fixed both the pound and the dirham. The half new penny was dropped years back and the dirham is now 100 fils though in practice you're unlikely to see a coin worth less than 25 fils in the UAE. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Tim Slattery on 16 Sep 2009 09:25
Arne Vajh�j <arne(a)vajhoej.dk> wrote: >Roedy Green wrote: >> On Tue, 15 Sep 2009 17:17:40 +0100, "Frank Cisco" >> <tdyjkdftyujdtjyj(a)dtyjdtyjdtyjdty.com> wrote, quoted or indirectly >> quoted someone who said : >>> Surely it should be 5454697.7388774? If I use double it's fine, but I need >>> to use float >> >> see http://mindprod.com/jgloss/floatingpoint.html >> >> floats are only accurate to about 6 significant digits. > >24*log10(2) is a bit more than 6. Huh?? A single-precision float has a 23-bit mantissa. 2^23 is 8,388,608. That's seven digits, but only six that you can run all the way from 0 to 9. -- Tim Slattery Slattery_T(a)bls.gov http://members.cox.net/slatteryt |