Adding int to a float

[Arne Vajhøj]

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

 

[Arne Vajhøj]

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

 

[Martin Gregorie]

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 Gregorie]

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.

 

[Lew]

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.

Actually, since the leading '1' is not explicit in the mantissa, it holds 24
bits of information for non-denorm floats, not 23.

 

[Tom Anderson]

Bzzt... wrong.
"Ideal" would probably be a Rational ("a/b"), or BigDecimal.

Nlek-nerr! For marketing data, you want java.util.Random.

tom