Path: csiph.com!aioe.org!.POSTED!not-for-mail From: =?UTF-8?Q?Arne_Vajh=c3=b8j?= Newsgroups: comp.lang.java.programmer Subject: Re: [OT] Re: missing import java.lang.Comparable Date: Sat, 9 Jul 2016 20:09:23 -0400 Organization: Aioe.org NNTP Server Lines: 71 Message-ID: References: <128e7e20-d311-413d-abbc-e885b34ae402@googlegroups.com> <87dc5bee-f689-4f2e-90a8-a43a2de9fe49@googlegroups.com> <638a1d64-f125-4456-a20b-4dbf45f49da2@googlegroups.com> <60a5ccde-2657-48d6-b3dd-04ec1a0973ab@googlegroups.com> NNTP-Posting-Host: 7SK6yTFfqwlIPNBLl3l7Qg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.java.programmer:34838 On 7/9/2016 8:51 AM, Martin Gregorie wrote: > On Fri, 08 Jul 2016 20:09:12 -0400, Arne Vajhøj wrote: >>> But this is never done: every financial system I've worked on has >>> always stored and manipulated monetary values as signed integers of the >>> appropriate length for the job, so GBP amounts are held as pence and >>> USD as cents: storing values and ints will be appropriate for most SME >>> and individual accounts, but you'd need to use a long int for banks and >>> large businesses. >> >> Really? >> >> I would expect that to be the case only in languages without BCD/decimal >> support like C. >> >> Cobol, Java, C# etc. would not need to do that. >> > I think the answer is the "it depends". > > In Java BigInteger explicitly doesn't use BCD and I suspect that > BigDecimal uses unpacked BCD rather than the more traditional packed BCD > format. > > COBOL's internal representation of integers often depends on the > underlying hardware. For instance, the ICL 1900 used 24 bit words and had > no native BCD handling, so all integer COBOL values were mapped onto > single or double length integers. > > MicroFocus COBOL is likely to use unpacked BCD despite it being > relatively slow for large numbers simply because an unpacked BCD > implementation should be portable across any byte-oriented hardware and > would have been useful back in the 8 and 16 bit days. > > OTOH, many IBM COBOLs can use BCD because all IBM mainframe and AS/400 > (plus successors) have hardware support for packed BCD arithmetic, though > the Power chip series doesn't seem to support BCD arithmetic, so would > necessarily use unpacked BCD implemented in software or microcode. > > In all cases, attempting to use packed BCD without direct hardware > support isn't a good ides because it would run like molasses. Yes. But there are two different aspects here. Does the programming language allow a programmer to use type with desired behavior. How does the programming language implement that in a specific version on a specific platform. Cobol, Java, C# and more languages have such types. C and more languages does not. In most cases the language that has such types do not specify how it is implemented. It can be different between different platforms. It can be different between different versions of the compiler. If my memory remember correct then VAX Cobol changed from using BCD instructions to using binary integer with implied decimal in some version when VAX changed from having BCD instructions in real hardware to being emulated. It is one of these things I would just leave to the compiler/VM/RT. Arne