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 21:52:28 -0400 Organization: Aioe.org NNTP Server Lines: 43 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:34840 On 7/9/2016 9:11 PM, Martin Gregorie wrote: > On Sat, 09 Jul 2016 20:09:23 -0400, Arne Vajhøj wrote: >> It is one of these things I would just leave to the compiler/VM/RT. >> > You can't, because that rules out program portability. If data type X has its behavior defined by the specs, then the compiler/VM/RT should be able to change the implementation all it want as long as it maintains documented behavior. > This may cause some apparent oddities, particularly in COBOL. The one > that baffles everybody is that COBOL's implied decimal point only affects > i/o unless the underlying storage mode is floating point (COMP-1 and > COMP-2). All the other numeric data types are integers. > > For these the implied decimal causes it to be aligned during input and > output: If three fields, A,B,C and D are described as PIC 999v999 COMP > and "1.0" is entered through a display field described as PIC ZZ9.v9, and > stored in A the internal representation will be 001000 and similarly a > value of 0.4 stored in B would be stored as 000400. On output the reverse > would happen and you'd get " 1.0" and " 0.4". > > However, if you execute the statement > > DIVIDE A BY B GIVING C REMAINDER D. > > then C will contain 002000 and D will contain 000500. Using the same PIC > "output you'll see that the result is " 2.0" with a remainder of " 0.5" > which is correct by the rules since integer representations obey the rule > that you first align the implied decimal points and then apply strict > integer arithmetic which leaves you with that an integer division result > rather than an answer of 002500 and no remainder. This trips a lot of > people the first time they see it: the message is that if they wanted the > implied decimal point to behave like an actual decimal point they should > have used COMP-1 or COMP-2 (floating point) data items rather than COMP > (binary) or COMP-3 (BCD). That is something completely different. If a program is changing data type from X to Y then it may obvious change behavior. Arne