Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: [OT] Re: missing import java.lang.Comparable Date: Sun, 10 Jul 2016 01:11:56 -0000 (UTC) Organization: A noiseless patient Spider Lines: 70 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sun, 10 Jul 2016 01:11:56 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="20830"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+GDCJJ3+/ihn48Fyla5mos5+jpy+rHfZE=" User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 3663720 git://git.gnome.org/pan2) Cancel-Lock: sha1:CZaBybidLHYAdBfisi1FrxBp38M= Xref: csiph.com comp.lang.java.programmer:34839 On Sat, 09 Jul 2016 20:09:23 -0400, Arne Vajhøj wrote: > 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. > It doesn't matter what the implementation of a data type is provided that the language specifies the required behaviour and all compilers implement it correctly. > 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. > Ideally the language spec should include definitive sets of tests with expected results, but I've never heard of a language doing that, so it probably has never happened. > It can be different between different platforms. > It can be different between different versions of the compiler. > If the types and behaviours are specified these should never happen. > Ditto > 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. > You can't, because that rules out program portability. 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). -- martin@ | Martin Gregorie gregorie. | Essex, UK org |