Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Fixed-point arithmetic library Date: Thu, 23 Feb 2012 01:05:58 +0000 (UTC) Organization: UK Free Software Network Lines: 72 Message-ID: References: <9ql7jpF3mnU1@mid.individual.net> NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1329959158 19640 84.45.235.129 (23 Feb 2012 01:05:58 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Thu, 23 Feb 2012 01:05:58 +0000 (UTC) User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:12260 On Wed, 22 Feb 2012 14:59:12 -0800, Gene Wirchenko wrote: > On Wed, 22 Feb 2012 23:13:06 +0100, Robert Klemme > wrote: > >>On 22.02.2012 22:39, Tom Anderson wrote: >>> Evening all, >>> >>> I would quite like to represent some numbers in fixed point, and do >>> arithmetic with them. >> >>Fixed point math is susceptible to precision issues which can be more >>severe than those of float and double: 0.01 * 0.2 -> 0.00 > > Only if the target precision does not have enough decimal places. > > I have been working with fixed-point arithmetic in JavaScript so > that I can add dollar amounts exactly. Maybe OP has something similar > in mind, though with the number of digits of precision that he wants > before the decimal point, I hope it is not currency-related. > Not necessarily. BigDecimal has few surprises, but then its not fixed decimal. The only fixed decimal arithmetic I've done in anger was in Cobol, which will merrily do the following (Identification and Environment divisions omitted for brevity). DATA DIVISION. WORKING-STORAGE. 01 FIXED-DECIMAL-FIELDS. 05 FD-VALUE PIC S9(6)v9(6) COMP SYNC. 05 FD-DIVISOR PIC S9(6)v9(6) COMP SYNC. 05 FD-RESULT PIC S9(6)v9(6) COMP SYNC. 05 FD-REMAINDER PIC S9(6)V9(6) COMP SYNC. 01 DISPLAY-LINE. 05 DL-VALUE PIC -(6)V.9(6). 05 FILLER PIC X() VALUE " / ". 05 DL-DIVISOR PIC -(6)V.9(6). 05 FILLER PIC X() VALUE " = ". 05 DL-RESULT PIC -(6)V.9(6). 05 FILLER PIC X() VALUE " REMAINDER ". 05 DL-REMAINDER PIC -(6)V.9(6). PROCEDURE DIVISION. MAIN SECTION. M-1. MOVE 0.8 TO FD-VALUE DL-VALUE. MOVE 2.0 TO FD-DIVISOR DL-DIVISOR. DIVIDE FD-VALUE BY FD-DIVISOR GIVING FD-RESULT REMAINDER FD-REMAINDER. MOVE FD-RESULT TO DL-RESULT. MOVE FD-REMAINDER TO DL-REMAINDER. DISPLAY DISPLAY-LINE. STOP RUN. This would display " 0.800000 / 2.000000 = 0.000000 REMAINDER 0.800000" because, of course, it is exactly equivalent to dividing 800000 by 2000000 and then adding decimal points in their correct fixed positions. Is that what you want or is BigDecimal doing the right thing for your problem space? Apologies for not showing a Cobol SSCE, but I don't have a COBOL compiler available to check it. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |