Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #34710 > unrolled thread
| Started by | Roedy Green <inquiry@mindprod.com> |
|---|---|
| First post | 2016-06-28 21:34 -0700 |
| Last post | 2016-07-03 20:57 +0000 |
| Articles | 20 on this page of 160 — 12 participants |
Back to article view | Back to comp.lang.java.programmer
missing import java.lang.Comparable Roedy Green <inquiry@mindprod.com> - 2016-06-28 21:34 -0700
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-06-29 05:56 +0000
Re: missing import java.lang.Comparable Roedy Green <inquiry@mindprod.com> - 2016-06-28 23:59 -0700
Re: missing import java.lang.Comparable Matthias Wiehl <mw@kwarg.de> - 2016-06-29 09:52 +0200
Re: missing import java.lang.Comparable Roedy Green <inquiry@mindprod.com> - 2016-06-29 01:16 -0700
Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-06-29 06:38 -0700
Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-30 13:24 +0000
Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-06-30 06:37 -0700
Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-30 10:19 -0400
Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-06-30 07:47 -0700
Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-30 11:17 -0400
Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-30 18:23 +0000
Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-30 15:24 -0400
Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-06-30 12:47 -0700
Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-30 16:38 -0400
Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-30 21:09 +0000
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-01 06:45 +0000
Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-01 05:03 -0700
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-03 20:46 +0000
Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-01 15:21 -0700
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-03 21:10 +0000
Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-04 16:08 -0700
Program proof Mike Amling <mamling@chaff.us> - 2016-07-05 11:23 -0500
Re: Program proof Andreas Leitgeb <avl@logic.at> - 2016-07-05 18:08 +0000
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-05 17:23 +0000
Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-05 14:28 -0700
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-07 15:22 +0000
Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-07 11:44 -0400
Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-07 12:57 -0400
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-07 18:29 +0000
[OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-07 15:48 -0400
Re: [OT] Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-08 08:01 +0000
Re: [OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-08 08:25 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-08 06:55 -0700
Re: [OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-08 10:16 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-08 07:35 -0700
Re: [OT] Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-08 18:07 +0000
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-08 12:54 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-08 16:29 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-08 14:06 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-08 20:11 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-15 11:37 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-15 16:36 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-15 15:49 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-15 22:09 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-16 13:04 +0000
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-18 13:08 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-18 19:56 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-08 20:59 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-09 11:57 +0000
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 09:39 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-09 14:43 +0000
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 11:15 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 09:46 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-09 15:21 +0000
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 11:27 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-15 11:39 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-15 15:38 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-15 15:52 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-15 19:19 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-18 13:10 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 16:26 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-18 13:58 -0700
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-18 16:30 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 20:24 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-19 05:14 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-19 20:22 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-19 10:31 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-19 16:37 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-19 14:44 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-19 21:16 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-19 21:54 +0000
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-19 20:17 -0400
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-20 12:01 -0700
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-20 21:28 +0000
Re: [OT] Re: missing import java.lang.Comparable Gene Wirchenko <genew@telus.net> - 2016-07-20 16:14 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-19 20:18 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-19 21:33 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-19 21:56 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-19 23:47 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-22 23:31 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-23 10:24 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-23 21:26 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-23 19:23 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-23 23:08 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 10:44 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 10:44 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-20 16:04 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-20 14:51 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-20 22:57 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-21 11:38 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-21 15:57 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-21 13:45 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-21 21:00 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-22 15:28 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-22 19:34 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-22 23:36 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-23 10:25 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-23 10:58 +0000
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-23 09:32 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-22 23:34 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-23 10:25 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-23 17:04 -0700
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 10:46 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-23 21:23 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 10:47 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-22 23:40 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-18 20:02 -0400
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 20:26 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-18 20:35 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-18 19:59 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-08 23:36 +0000
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-08 20:09 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-09 12:51 +0000
Re: [OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-09 09:15 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-09 14:30 +0000
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 09:44 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-09 14:37 +0000
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 11:14 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-09 20:09 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-10 01:11 +0000
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-09 21:52 -0400
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-10 10:34 +0000
Re: [OT] Re: missing import java.lang.Comparable Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-08 21:03 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-08 20:32 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-11 05:30 -0700
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-11 16:26 +0000
Re: [OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-11 13:56 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-11 10:59 -0700
Re: [OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-11 15:09 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-11 13:44 -0700
Re: [OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-11 17:21 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-11 10:56 -0700
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-11 11:49 -0700
Re: [OT] Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-11 21:00 +0000
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-11 22:30 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-11 22:36 -0400
Re: [OT] Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-07-12 11:37 -0700
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-12 13:01 -0700
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-12 20:31 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-11 22:13 -0400
Re: [OT] Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-08 20:18 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-08 15:14 -0700
Re: [OT] Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-08 17:59 +0000
Re: [OT] Re: missing import java.lang.Comparable Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-08 14:34 -0400
Re: [OT] Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-08 15:18 -0700
Re: [OT] Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-08 23:50 +0000
Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-07 13:18 -0700
Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-07 16:59 -0400
Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-07-08 15:05 -0700
Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-08 19:51 -0400
Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-07 17:07 -0400
Re: missing import java.lang.Comparable Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-30 20:44 +0000
Re: missing import java.lang.Comparable Arne Vajhøj <arne@vajhoej.dk> - 2016-07-07 16:56 -0400
Re: missing import java.lang.Comparable a.laforgia@gmail.com - 2016-06-30 08:32 -0700
Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-06-30 08:59 -0700
Re: missing import java.lang.Comparable a.laforgia@gmail.com - 2016-06-30 09:06 -0700
Re: missing import java.lang.Comparable Eric Douglas <e.d.programmer@gmail.com> - 2016-06-30 09:35 -0700
Re: missing import java.lang.Comparable Lew <lewbloch@gmail.com> - 2016-06-30 11:18 -0700
Re: missing import java.lang.Comparable Andreas Leitgeb <avl@logic.at> - 2016-07-03 20:57 +0000
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-07-10 01:11 +0000 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nls7cs$kau$1@dont-email.me> |
| In reply to | #34838 |
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 |
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-07-09 21:52 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nls9ou$kor$1@gioia.aioe.org> |
| In reply to | #34839 |
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
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-07-10 10:34 +0000 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlt8bl$a6h$1@dont-email.me> |
| In reply to | #34840 |
On Sat, 09 Jul 2016 21:52:28 -0400, Arne Vajhøj wrote: > 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. > Yes, and as Eric pointed out recently, there's a good example of this in Java: the current (1.8) BigDecimal implementation stores values in a long and the implied decimal point as an int scale factor. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-08 21:03 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlpigu$vne$1@jstuckle.eternal-september.org> |
| In reply to | #34808 |
On 7/8/2016 7:36 PM, Martin Gregorie wrote: > On Fri, 08 Jul 2016 12:54:01 -0700, Eric Douglas wrote: > >> Monetary amounts normally deal in decimals. At least they always >> support exactly 2 decimals unlike the inventory system I described, so >> one could always divide and multiply by 100 to display as decimals and >> store as integers. Pity the fool who has to deal with the fraction of a >> penny, but a similar system would have to be devised to represent the >> fraction as a whole number or a string. >> > 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. > U.S. Banks and insurance companies both go to at least 4 decimal places past cents. And they do not use signed integers. That's why COBOL is used in these businesses. > Visible representations will use whatever is appropriate to the users for > inputting and displaying values by using more or less complex editing > routines. Commercial banking applications will abbreviate large amounts, > e.g I've worked with one multi-currency accounting system that would > accept "1.5M USD" and understand that was $US 1,500,000.00 -it would > also understand that a value of 5 with a UK pound currency code sould be > displayed as "0.05 GBP", or 5 pence in UK money. BTW, contrary to popular > Western superstition, not all currencies have a unit divisible by 100: > while the Hungarian Forint is theoretically split into 100 filler I've > never seen anything smaller than the Forint in daily use or as an > advertised price. Same goes for the Italian Lira. At the other end of the > scale Dirhams or Dinars (used in several Middle Eastern countries) have > three decimal parts in some countries. > That is fine for visual representation. But calculations are another story. > Lower values are super easy to handle in COBOL, since when you specify an > edited numeric value there us a distinction made between '.', which is > just another interpolated character and 'V' which will be aligned with > the decimal point is if the value has one, e.g. for US money the internal > storage might be described as "PIC S9(9)" (a signed 9 digit integer) and > its external representation might be "PIC $$,$$$,$$9.99 CR" so that a > value of 102400 would be output as " $1,024.00 " and a value of -5 > would be output as " $0.05 CR", but dealing with very large > amounts in a system that allows abbreviations and handles multiple > currencies isn't simple in any language. > > Again, displayed values are not the same as calculated values. Banks don't show dollars and cents past cents - but you can be assured it is calculated that way. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-07-08 20:32 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlpgm2$vqc$1@gioia.aioe.org> |
| In reply to | #34802 |
On 7/8/2016 3:54 PM, Eric Douglas wrote:
> On Friday, July 8, 2016 at 2:07:28 PM UTC-4, Andreas Leitgeb wrote:
>>> Program:
>>> double a = .0002;
>>> double b = .0001;
>>> System.out.println(a + b);
>>> Result:
>>> 3.0000000000000003E-4
>>
>> That's why formatted printing (e.g. printf) is preferable to
>> the default stringification of floating point values in such
>> cases.
>
> Program:
> DecimalFormat myFormatter = new DecimalFormat("0.####################");
> String output;
> double a = .0002;
> double b = .0001;
> output = myFormatter.format(a + b);
> System.out.println(output);
> BigDecimal bda = new BigDecimal(String.valueOf(a));
> BigDecimal bdb = new BigDecimal(String.valueOf(b));
> bda = bda.add(bdb);
> output = myFormatter.format(bda.doubleValue());
> System.out.println(output);
> Output:
> 0.00030000000000000003
> 0.0003
I don't think this example shows what you think it shows.
It really shows that String.valueOf has an impact on the result.
Arne
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-07-11 05:30 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <6f69c451-849d-4672-9025-7880a62bd72d@googlegroups.com> |
| In reply to | #34815 |
On Friday, July 8, 2016 at 8:32:14 PM UTC-4, Arne Vajhøj wrote:
> I don't think this example shows what you think it shows.
>
> It really shows that String.valueOf has an impact on the result.
>
> Arne
Converting to a String is what makes it work. Whether it's the financial application dealing with fractions of pennies or an inventory management application which may have fractions depending on the unit of measure, I expect .0001 + .0002 to get exactly .0003.
Code:
DecimalFormat myFormatter = new DecimalFormat("0.####################");
String output;
double a = .0002;
double b = .0001;
output = myFormatter.format(a + b);
System.out.println(output);
BigDecimal bda = new BigDecimal(String.valueOf(a));
BigDecimal bdb = new BigDecimal(String.valueOf(b));
bda = bda.add(bdb);
output = myFormatter.format(bda.doubleValue());
System.out.println(output);
Output:
0.00030000000000000003
0.0003
Code:
DecimalFormat myFormatter = new DecimalFormat("0.####################");
String output;
double a = .0002;
double b = .0001;
output = myFormatter.format(a + b);
System.out.println(output);
BigDecimal bda = new BigDecimal(a);
BigDecimal bdb = new BigDecimal(b);
bda = bda.add(bdb);
output = myFormatter.format(bda.doubleValue());
System.out.println(output);
Output:
0.00030000000000000003
0.00030000000000000003
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-07-11 16:26 +0000 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nm0hbh$s5q$1@dont-email.me> |
| In reply to | #34848 |
On Mon, 11 Jul 2016 05:30:50 -0700, Eric Douglas wrote:
> On Friday, July 8, 2016 at 8:32:14 PM UTC-4, Arne Vajhøj wrote:
>> I don't think this example shows what you think it shows.
>>
>> It really shows that String.valueOf has an impact on the result.
>>
>> Arne
>
> Converting to a String is what makes it work.
>
Disagree: all you've shown is that integer arithmetic is exact regardless
of how the value is stored, while floating point representations are
inexact. This is why you (should have been|were) taught that you should
never compare floating point numbers for equality, instead you check that
the two values differ by less than the least significant digit, i.e.
float a = 0.002;
float b = 0.005 - 0.003;
if (Math.abs(a - b) < 0.0005)
System.out.println("a and b differ by less than 0.0005");
As others have said, use floats or doubles for science and engineering
and int, long, BigInteger or BigDecimal for financials.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-07-11 13:56 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nm0mk7$k35$1@dont-email.me> |
| In reply to | #34849 |
On 7/11/2016 12:26 PM, Martin Gregorie wrote:
> On Mon, 11 Jul 2016 05:30:50 -0700, Eric Douglas wrote:
>
>> On Friday, July 8, 2016 at 8:32:14 PM UTC-4, Arne Vajhøj wrote:
>>> I don't think this example shows what you think it shows.
>>>
>>> It really shows that String.valueOf has an impact on the result.
>>>
>>> Arne
>>
>> Converting to a String is what makes it work.
>>
> Disagree: all you've shown is that integer arithmetic is exact regardless
> of how the value is stored, while floating point representations are
> inexact. This is why you (should have been|were) taught that you should
> never compare floating point numbers for equality, instead you check that
> the two values differ by less than the least significant digit, i.e.
>
> float a = 0.002;
> float b = 0.005 - 0.003;
> if (Math.abs(a - b) < 0.0005)
> System.out.println("a and b differ by less than 0.0005");
>
> As others have said, use floats or doubles for science and engineering
> and int, long, BigInteger or BigDecimal for financials.
I suspect his misunderstanding comes not so much from being unaware
of computational approximations (rounding, etc.) as from matters of
representation. He's disturbed that 0.0001 + 0.0002 is not exactly
0.0003, but this is less from inaccuracy of computation than from
inaccuracy of representation. Neither the addend nor the augend is
exactly representable as a `double', so Java substitutes the best
approximations it can ("close enough for jazz"). The `+' thus adds
two values that are not quite what he thinks they are, and gets a sum
that is not quite what he thinks it should be (another value, as it
happens, that a `double' cannot represent).
I sometimes try to help people understand this by asking them to
use ordinary decimal arithmetic to compute the fraction of a week that
is a weekend. That is, I ask them to compute two-sevenths as a decimal
fraction -- and I invite them to carry the computation out to as many
places as they please, until they're satisfied that the answer is exact.
Then I tell them that binary arithmetic has the same problem with any
denominator that is not a power of two, and they usually get the point.
Maybe Eric Douglas will, too (although since he proffered the specious
claim that 1 + 1 yields 1.99999999999998, this is far from certain).
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-07-11 10:59 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <f9529a19-baea-4267-9eed-2dcdfc375477@googlegroups.com> |
| In reply to | #34851 |
On Monday, July 11, 2016 at 1:56:35 PM UTC-4, Eric Sosman wrote: > Maybe Eric Douglas will, too (although since he proffered the specious > claim that 1 + 1 yields 1.99999999999998, this is far from certain). I was certain it did that once with a whole number (using the double primitive) but I don't have the test program offhand, so maybe it is only with the fractional amounts.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-07-11 15:09 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nm0qta$5ai$1@dont-email.me> |
| In reply to | #34853 |
On 7/11/2016 1:59 PM, Eric Douglas wrote:
> On Monday, July 11, 2016 at 1:56:35 PM UTC-4, Eric Sosman wrote:
>> Maybe Eric Douglas will, too (although since he proffered the specious
>> claim that 1 + 1 yields 1.99999999999998, this is far from certain).
>
> I was certain it did that once with a whole number (using the double primitive) but I don't have the test program offhand, so maybe it is only with the fractional amounts.
That's why I suspect you haven't grasped the representational
issue. A `double' can represent, exactly, all integers in the
range -9007199254740991 through 9007199254740991 (-2**53+1 through
2**53-1). In particular, it can represent both 1's and their sum 2
exactly.
Outside that range, `double' starts to skip some integers: For
a while it can represent only the even numbers, then only the numbers
divisible by four, then by eight, and so on. If you're summing
numbers with magnitudes in excess of nine quadrillion or so, expect
inaccuracies to creep in.
In the other direction, `double' can represent numbers with
fractional parts, but only some of the infinitely many that exist.
Specifically, the exact values for `double' are fractions P/Q
where P is an integer between plus or minus nine quadrillion *and*
Q is an integer power of two (within a broad but limited range that
includes both positive and negative powers). So,
1.0 is exact
0.5 is exact
0.25 and 0.75 are exact
0.125, 0.375, 0.625, 0.875 are exact
... and so on (to a point)
BUT
0.1 is inexact
0.02 is inexact
0.003 is inexact
0.0004 is inexact
... and so on
This inexactitude is exactly the same difficulty that afflicts
decimal arithmetic in computing 1/3 or 2/7 or 3/11 or any other
fraction whose denominator (in lowest terms) has a prime factor
that is not a factor of ten.
Lest anyone imagine that computing in decimal would somehow
solve all problems, let me offer a thought experiment drawn from
real life. Interest rates on savings are, at the moment, rather
low. In an effort to lure, sorry, "interest" depositors, a bank
wants to trumpet the comparatively high rate of 1.1%, but they'd
like to pay out as little as possible. "Aha!" says some bright
lad, "We'll offer an interest rate that, when compounded monthly,
produces a 1.1% *annual* yield! Because compounding makes the number
look bigger, we can advertise 1.1% while actually paying out at a
rate that's slightly lower." The bank's executives bless the plan,
and send the BL off to calculate the monthly rate.
Question: What should that monthly rate be? To put it another
way, what is the rate R such that (1+R/100)**12 = 1.011 = 1 + 1.1%?
Calculate in any integer base you prefer, but answer exactly.
(This sort of problem also makes a good rejoinder to people who
maintain that *all* financial calculations should use integer math.)
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-07-11 13:44 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <b21e52e2-6678-4b92-a75d-c03118fbf000@googlegroups.com> |
| In reply to | #34856 |
On Monday, July 11, 2016 at 3:09:42 PM UTC-4, Eric Sosman wrote: > Question: What should that monthly rate be? To put it another > way, what is the rate R such that (1+R/100)**12 = 1.011 = 1 + 1.1%? > Calculate in any integer base you prefer, but answer exactly. > > (This sort of problem also makes a good rejoinder to people who > maintain that *all* financial calculations should use integer math.) I will read that article Lew linked and see if it helps. This is tricky to understand because it's basic math, we're adding 2 numbers not dividing. I have a college degree in computer business, not computer science. I've taken algebra, geometry, statistics. I have not taken trigonometry or calculus or learned anything I can recall about imaginary numbers. 1 + 2 = 3, and .0001 + .0002 = .0003. Most people would agree. Financial math involves division where imprecise numbers are involved and typically that means rounding. Someone making $50,000 per year paid weekly, calculated on a 52 week year makes a gross $961.5384615384615 per week, so it's rounded to $961.53 and some weeks $961.54 to make up the difference. I don't know how banks work with interest but I would think they have to be the same. If you want exactly 1.1% annual interest but you calculate it monthly you have a number you have to round and you alternate rounding it up and down until the result comes out even. 1.1 / 12 = 0.091666666... $50,000 + 1.1% = $50,550 $50,000 * 0.000916666 = $45.8333 ($45.83 * 8) + ($45.84 * 4) = $550 Computers aren't made to compute fractions but that's the part I struggle with is what do fractions have to do with basic addition.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-07-11 17:21 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nm12lh$2do$1@dont-email.me> |
| In reply to | #34861 |
On 7/11/2016 4:44 PM, Eric Douglas wrote:
> On Monday, July 11, 2016 at 3:09:42 PM UTC-4, Eric Sosman wrote:
>> Question: What should that monthly rate be? To put it another
>> way, what is the rate R such that (1+R/100)**12 = 1.011 = 1 + 1.1%?
>> Calculate in any integer base you prefer, but answer exactly.
>>
>> (This sort of problem also makes a good rejoinder to people who
>> maintain that *all* financial calculations should use integer math.)
>
> I will read that article Lew linked and see if it helps. This is tricky to understand because it's basic math, we're adding 2 numbers not dividing. I have a college degree in computer business, not computer science. I've taken algebra, geometry, statistics. I have not taken trigonometry or calculus or learned anything I can recall about imaginary numbers. 1 + 2 = 3, and .0001 + .0002 = .0003. Most people would agree.
>
> Financial math involves division where imprecise numbers are involved and typically that means rounding. Someone making $50,000 per year paid weekly, calculated on a 52 week year makes a gross $961.5384615384615 per week, so it's rounded to $961.53 and some weeks $961.54 to make up the difference. I don't know how banks work with interest but I would think they have to be the same. If you want exactly 1.1% annual interest but you calculate it monthly you have a number you have to round and you alternate rounding it up and down until the result comes out even.
> 1.1 / 12 = 0.091666666...
> $50,000 + 1.1% = $50,550
> $50,000 * 0.000916666 = $45.8333
> ($45.83 * 8) + ($45.84 * 4) = $550
It may be little more than a distraction, but that's *simple*
interest. Compound interest (where each period pays interest on the
entire balance, including the previous periods' interest) is a
different beast altogether. (And the reason neither decimal nor
binary nor any other integer base will work is that the twelfth
root of 1.011 ~= 1.000912+ is an "irrational number," a value that
cannot be represented as a fraction M/N for *any* integers M,N.)
If you're going to write computer programs, I strongly suggest
you get a little better understanding of how computers represent and
calculate with numbers. It is a mistake to believe that every digit
of every floating-point result is "significant," but it is also a
mistake to think that they're all meaningless. A full-scale course
in Numerical Analysis may not be necessary (depending on where your
interests lie), but a study of the first one or two chapters of a NA
introductory text might be a good idea. It'll make you better informed
as to what you can and cannot expect from a calculation.
> Computers aren't made to compute fractions but that's the part I struggle with is what do fractions have to do with basic addition.
Well, your difficulty concerned adding fractions. You complained
that 0.0001 + 0.0002 should equal 0.0003 but the computer gives a
different sum. What you *ought* to understand is that none of these
three fractions is represented without error; you're really adding
(0.0001 + x) + (0.0002 + y) = (0.0003 + z)
... for very small but non-zero x,y,z.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-07-11 10:56 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <f09c0523-6c68-4fbc-98b6-8bf242b59abb@googlegroups.com> |
| In reply to | #34849 |
On Monday, July 11, 2016 at 12:27:04 PM UTC-4, Martin Gregorie wrote: > As others have said, use floats or doubles for science and engineering > and int, long, BigInteger or BigDecimal for financials. That seems misleading and tedious. When I first started learning Java I learned about primitives, which I would think you'd want to use if you can because they're less overhead, but only the float and double support decimals which seems odd since they both carry the warning "This data type should never be used for precise values, such as currency." or apparently any values which use normal math. In grade school math we're taught .0002 + .0001 = .0003, so I'm not sure how it adds up to .00030000000000000003. Oracle even has their own Java based financials software, so I assume all numeric references in their programs use BigDecimal? I'm not sure how you add decimal values using primitives which only support whole numbers. When I'm writing a program that calls a method of my API and needs to give it a numeric value with a decimal it seems like a lot of extra overhead to always convert to a String first and pass into a new BigDecimal to get the parameter into the method.
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2016-07-11 11:49 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <0c4e6b25-2b96-401c-9ba8-0c68f71220bd@googlegroups.com> |
| In reply to | #34852 |
On Monday, July 11, 2016 at 10:57:06 AM UTC-7, Eric Douglas wrote: > On Monday, July 11, 2016 at 12:27:04 PM UTC-4, Martin Gregorie wrote: > > As others have said, use floats or doubles for science and engineering > > and int, long, BigInteger or BigDecimal for financials. > > That seems misleading and tedious. When I first started learning Java I learned about primitives, which I would think you'd want to use if you can because they're less overhead, but only the float and double support decimals which seems odd since they both carry the warning "This data type should never be used for precise values, such as currency." or apparently any values which use normal math. In grade school math we're taught .0002 + .0001 = .0003, so I'm not sure how it adds up to .00030000000000000003. Many people have explained this already, but really it's Comp Sci 101 stuff. Computer representations are finite; real numbers are not. Ergo, and this is very basic, there are real numbers that lack computer representations. It happens that the numbers you cited are in that set. You should read https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html. It would truly help you if you understood what we are discussing, and that document should help you understand what we are discussing. > Oracle even has their own Java based financials software, so I assume all numeric You know what you get when you assume ... > references in their programs use BigDecimal? > I'm not sure how you add decimal values using primitives which only support whole numbers. Umm, you are aware that 'BigDecimal', as the name implies and the documentation confirms, supports arbitrary-precision decimal numbers, yes? But tha answer was given above, so it should be no mystery, how 'long' can be used to represent money. You simply use 1L to represent the minimum currency amount. As explained above. So it should be no mystery any more. > When I'm writing a program that calls a method of my API and needs to give it a numeric value with a decimal it seems like a lot of extra overhead to always convert to a String first and pass into a new BigDecimal to get the parameter into the method. What constitutes "extra" overhead, eh? If it is necessary to guarantee correctness, how is it "extra"? You should use logic instead of emotion. Also, just say "I think" instead of "it seems"; it is more accurate and more honest. It doesn't "seem" that way to others, just you. One you say "I think" instead of "it seems", you take responsibility for the current limits of your knowledge, which in turn empowers you to learn more. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-07-11 21:00 +0000 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nm11ct$877$1@dont-email.me> |
| In reply to | #34852 |
On Mon, 11 Jul 2016 10:56:55 -0700, Eric Douglas wrote: > On Monday, July 11, 2016 at 12:27:04 PM UTC-4, Martin Gregorie wrote: >> As others have said, use floats or doubles for science and engineering >> and int, long, BigInteger or BigDecimal for financials. > > That seems misleading and tedious. When I first started learning Java I > learned about primitives, which I would think you'd want to use if you > can because they're less overhead, but only the float and double support > decimals which seems odd since they both carry the warning "This data > type should never be used for precise values, such as currency." or > apparently any values which use normal math. In grade school math we're > taught .0002 + .0001 = .0003, so I'm not sure how it adds up to > .00030000000000000003. > I seriously suggest that you look at real numbers both as a mathematician thinks of them and then as they are represented in a computer. The problem is that there is no limit to the number of digits in a real number (how many thousand digits has Pi been calculated to now?) while most computers can only deal with the most significant 18 digits or less. This requires that the last digit in this representation *must* be rounded to give the closest approximation in however many digits the representation uses. As a result, as you perform calculations on these representations, is that the rounding errors accumulate. And it can get worse than that: a Java float can hold values in the range -10^127 to +10^127 but it only uses 24 bits for the significand, equivalent to 6 digits, so, although you can store a value of 6 billion dollars, written as $6,000,000,000.00 the last six digits will always be zero. Use a double and the range goes up -10^1023 to _10^1023 with 53 bits for the significand, or 14 digits, so any value bigger than $999,999,999,999.99 will also have zeros for the last digits. Since a long can hold fully decimal values of up to 18 digits, it can store considerably larger accurate monetary values than you can store in a double because the long can use all 63 bits for representing digits while a double can only use 53 bits because the exponent uses 11 bits of the 64 available. This is why its a really bad idea to use hold financial amounts in real number variables. This used to be graphically illustrated by some of the accounting packages that were written in BASIC and run on early 8086-based microprocessors. As many of these BASICs were clones of Altair BASIC (the ancestor of MS BASIC) which had 16 bit integers and 32-bit floating point, the financial packages written in it naturally used floating point for monetary values because a 16 bit integer can only deal with 5 digits, or $999.99. However as this 32-bit floating point only used 24 bits to hold the signed significand, it, like a Java float, could only hold 6 significant digits, and so became inaccurate when used for any value bigger than $9,999.99. This was noticed! > Oracle even has their own Java based financials software, so I assume > all numeric references in their programs use BigDecimal? I'm not sure > how you add decimal values using primitives which only support whole > numbers. > You store values as cents or pence. On input you ignore the decimal point between the 2nd and 3rd digit from the right (apart from complaining if it isn't there) and add it in when outputting the value to a screen or hard copy. Provided all external representations do this, then the user neither knows nor cares that the program stores values as cents/pence because their values he inputs and reads look like dollars/pounds to him. > When I'm writing a program that calls a method of my API and needs to > give it a numeric value with a decimal it seems like a lot of extra > overhead to always convert to a String first and pass into a new > BigDecimal to get the parameter into the method. > Why would you do that? Just use DecimalFormat to parse numbers being input or to format numbers output. Parsing can return any subtype of Number just as formatting can create an edited string from any subtype of Number. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-07-11 22:30 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nm1knl$1udn$1@gioia.aioe.org> |
| In reply to | #34852 |
On 7/11/2016 1:56 PM, Eric Douglas wrote:
> On Monday, July 11, 2016 at 12:27:04 PM UTC-4, Martin Gregorie
> wrote:
>> As others have said, use floats or doubles for science and
>> engineering and int, long, BigInteger or BigDecimal for
>> financials.
>
> That seems misleading and tedious. When I first started learning
> Java I learned about primitives, which I would think you'd want to
> use if you can because they're less overhead,
Financial calculation that need book keeping accuracy are typical
not very computing intensive after todays standard.
Just use BigDecimal and forget about the overhead compared to
simple types.
> but only the float and
> double support decimals which seems odd since they both carry the
> warning "This data type should never be used for precise values, such
> as currency."
Some computer hardware and some programming languages allow
a data type that we can call fixed point in a hardware close
format.
Not Java.
> or apparently any values which use normal math. In
> grade school math we're taught .0002 + .0001 = .0003, so I'm not sure
> how it adds up to .00030000000000000003.
Floating point and math does not follow the same rules. Because
something works in math then it does not necessarily work in
floating point.
There are plenty of examples.
An attempt (hopefully a good one):
public class FPFun {
public static void main(String[] args) {
float a = 12345;
float b = 123;
float c = (a - b) * (a - b);
System.out.printf("%10.1f\n", c);
float d = a * a - 2 * a * b + b * b;
System.out.printf("%10.1f\n",d);
}
}
149377280.0
149377296.0
> Oracle even has their own Java based financials software, so I assume
> all numeric references in their programs use BigDecimal?
Likely.
> I'm not
> sure how you add decimal values using primitives which only support
> whole numbers.
You can do some tricks by having an implied number of decimals.
> When I'm writing a program that calls a method of my API and needs to
> give it a numeric value with a decimal it seems like a lot of extra
> overhead to always convert to a String first and pass into a new
> BigDecimal to get the parameter into the method.
If you do double->String->BigDecimal there is no point - you are already
in trouble.
Your program should already have it as either String or BigDecimal. No
double.
Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-07-11 22:36 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nm1l40$1urc$1@gioia.aioe.org> |
| In reply to | #34866 |
On 7/11/2016 10:30 PM, Arne Vajhøj wrote: > On 7/11/2016 1:56 PM, Eric Douglas wrote: >> or apparently any values which use normal math. In >> grade school math we're taught .0002 + .0001 = .0003, so I'm not sure >> how it adds up to .00030000000000000003. > > Floating point and math does not follow the same rules. Because > something works in math then it does not necessarily work in > floating point. The discipline that covers this topic is "Numerical Analysis". Which should be relevant for a wide area of fields like Economics, Medicine, various natural sciences and Computer Science. Unfortunately is is rarely taught. Arne
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-07-12 11:37 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <0e340240-f2ae-470f-8562-3e7f3d630074@googlegroups.com> |
| In reply to | #34866 |
On Monday, July 11, 2016 at 10:30:25 PM UTC-4, Arne Vajhøj wrote: > Just use BigDecimal and forget about the overhead compared to > simple types. Well, I ran a text search on my API and found "double" 632 times so it probably doesn't make sense to get rid of all, now I just need to figure out where it matters. If we're putting a value into an object that's supposed to represent something, say inventory on hand, possibly doing a calculation then getting the result out of the object it should matter. If I'm using a number of characters divided by a font size to calculate a location to print something on a page I'm sure it doesn't matter if the result is off by .00000000000000000003. The Oracle doc on floating point arithmetic looks rather lengthy, so I'm trying to understand that, but of course it starts with "nothing more complicated than elementary calculus" and I've never had a calculus course.
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2016-07-12 13:01 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <8b0b6e51-0f31-40a7-b477-7ad3248d7012@googlegroups.com> |
| In reply to | #34870 |
On Tuesday, July 12, 2016 at 11:38:11 AM UTC-7, Eric Douglas wrote: > On Monday, July 11, 2016 at 10:30:25 PM UTC-4, Arne Vajhøj wrote: > > Just use BigDecimal and forget about the overhead compared to > > simple types. > > Well, I ran a text search on my API and found "double" 632 times so it probably doesn't make sense to get rid of all, now I just need to figure out where it matters. If we're putting a Whenever one invests substantial effort into a system then discovers that they have a fundamental flaw in the basic design thereof, there is an emotional reluctance to dump "all that work" in favor of correctness. One should not let such emotions cloud one's judgment. > value into an object that's supposed to represent something, say inventory on hand, possibly doing a calculation then getting the result out of the object it should matter. If I'm using a number of characters divided by a font size to calculate a location to print something on a page I'm sure it doesn't matter if the result is off by .00000000000000000003. No one said that 'double' is useless. > The Oracle doc on floating point arithmetic looks rather lengthy, so I'm trying to Gee, whiz. > understand that, but of course it starts with "nothing more complicated than elementary calculus" and I've never had a calculus course. I don't recall any calculus in that document. If there is any, you can skim over that part. There is plenty of material about floating-point computation and numerical analysis floating around on the Web. Perhaps you should consider doing some research. Knowledge is power, and ignorance really is not bliss. It's not like you really can be effective as a programmer without understanding the essentials of floating-point computation. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-07-12 20:31 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nm4248$1ldp$1@gioia.aioe.org> |
| In reply to | #34870 |
On 7/12/2016 2:37 PM, Eric Douglas wrote: > On Monday, July 11, 2016 at 10:30:25 PM UTC-4, Arne Vajhøj wrote: >> Just use BigDecimal and forget about the overhead compared to >> simple types. > > Well, I ran a text search on my API and found "double" 632 times so > it probably doesn't make sense to get rid of all, now I just need to > figure out where it matters. If we're putting a value into an object > that's supposed to represent something, say inventory on hand, > possibly doing a calculation then getting the result out of the > object it should matter. If I'm using a number of characters divided > by a font size to calculate a location to print something on a page > I'm sure it doesn't matter if the result is off by > .00000000000000000003. There are lots of cases where FP is perfectly valid. Just ask the question: is +/- a little bit perfectly valid for this data? A lot of data is really measured with some uncertainty. Arne
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web