Adding int to a float
in [Java Help]
|
From: John B. Matthews on 18 Sep 2009 18:25 In article <h90ual$vog$1(a)localhost.localdomain>, Martin Gregorie <martin(a)address-in-sig.invalid> wrote: [...] > AFAIK use of floating point only started when people tried to handle > monetary amounts on the early 8-bit micros - the early BASICs would > only handle 16 bit signed integers, so people who should have known > better used floating point to handle values larger than 327.68 and > managed to blind themselves to the rounding errors and limitation to > 8 significant figures. Unfortunately, this habit has carried over > into spreadsheets but there's no need to propagate it into Java as > well. I recall this. In that 8-bit era, students of Forth luxuriated in 32-bit integers [1] and understood the virtue of fixed-point arithmetic [2]. Java offers a rich variety of numeric types [3] and excellent libraries of derived types [4], but the need for understanding remains. [1]<http://home.roadrunner.com/~jbmatthews/a2/proforth.html> [2]<http://www.forth.com/starting-forth/sf5/sf5.html> [3]<http://java.sun.com/javase/6/docs/api/java/lang/Number.html> [4]<http://jscience.org/api/org/jscience/mathematics/number/Number.html> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Lew on 18 Sep 2009 20:09 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. Patricia Shanahan wrote: > I would agree with this with two exceptions: > > 1. There are some financial calculations for which extreme exactness > does not matter, and having transcendental function approximations does. > For example, calculations of the form "How long will it take me to pay > off my home loan if I do X?". Are there then integral methods for computing amortization schedules and the like? My instinct for such, e.g., to calculate a monthly payment, is to calculate the payment using double, convert to long, sum the payments over the term, then add the rounding error to the final payment. I did a contract for a major credit-card company a decade or so ago. They used natural log formulas to calculate amortization. The formula they wanted me to use included ln(x)^2 in the numerator and ln(x) in the denominator of a fraction - same x. I simplified to just ln(x) in the numerator. My team lead was seriously worried that I had screwed up the calculation, on which point I assured her that I had. I forbore to mention they differed in the singularity. They didn't use integer math to compute amortization quantities. I would bet that they did accumulate round-off error into the last payment. I have received payment schedules from consumer credit wherein the payments varied in the penny. I guess some companies do use the hybrid approach - use double to get the payment, convert to long to actually work with it. > 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. -- Lew
From: Lew on 18 Sep 2009 20:11 Lew wrote: > My team lead was seriously worried that I had screwed up the > calculation, on which point I assured her that I had. "Had not." That's "had not". No Freudian slip here. Nope. Not at all. -- Lew
From: Arne Vajhøj on 18 Sep 2009 20:15 Lew wrote: > Patricia Shanahan wrote: >> I would agree with this with two exceptions: >> >> 1. There are some financial calculations for which extreme exactness >> does not matter, and having transcendental function approximations does. >> For example, calculations of the form "How long will it take me to pay >> off my home loan if I do X?". > > Are there then integral methods for computing amortization schedules and > the like? > > My instinct for such, e.g., to calculate a monthly payment, is to > calculate the payment using double, convert to long, sum the payments > over the term, then add the rounding error to the final payment. That may be necessary just due to the fact interest * something may not always give integral cents. Arne
From: Martin Gregorie on 18 Sep 2009 20:17
On Fri, 18 Sep 2009 15:21:04 -0700, Patricia Shanahan wrote: > 1. There are some financial calculations for which extreme exactness > does not matter, and having transcendental function approximations does. > For example, calculations of the form "How long will it take me to pay > off my home loan if I do X?". > I'm not sure that this counts as a monetary calculation, though it is financial, because the answer is time (and will be rounded up to months). The same classification probably applies to NPV and similar calculations since they're estimates of value rather than an actual monetary value. > 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. If your BCD arithmetic unit has an overflow capability it is cheap to make, since its registers only need 4 bits plus Carry and yet can deal with arbitrary length numeric values. BCD values always had odd numbers of digits because the leading nibble was reserved for the sign. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | |