On 7 May 2010 12:28, Kirk Talman <rkueb...@tsys.com> wrote: >> Consistency of result has a lot to be said for it as does meeting >> customer expectation. I don't want my checking account handled in >> either binary or floating point. >> >> Java is supporting both DFP and BFP. Java is strategic. Living with >> it is strategic. The COBOL organization is ignoring the message. > > I agree w/Shmuel. This is a display issue. > > It is also a precision issue. If you are storing money in an FP field, > any format is acceptable as long as the precision includes "cents" (i.e. > the lowest expectable unit in the currency) plus in some cases a digit for > smoothing/rounding. But to the "consumer" you have to smooth over the > internal roughness. You can't let the abstraction leak out.
It's hardly unusual to have fractional cents in calculations, which are rounded to the nearest cent only for the final, billable number. Doubtless the most common thing - but a very common thing indeed - priced in small fractions of cents is telephone minutes. Lots of carriers will have a price of e.g. 1.63 cents (i.e. $0.0163) per minute to call a particular country. There's big trouble if the numbers are smoothed over too early. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
