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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-07-08 20:11 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlpfgh$uat$3@gioia.aioe.org> |
| In reply to | #34804 |
On 7/8/2016 5:06 PM, Gene Wirchenko wrote: > On Fri, 8 Jul 2016 16:29:22 -0400, Jerry Stuckle > <jstucklex@attglobal.net> wrote: >> Financial institutions in the U.S. typically deal with at least four >> decimal places past the cents sign (six decimal places total). That's >> why COBOL is still so popular - it supports packed decimal natively. >> And IBM mainframes have support for packed decimal. Even Intel >> processors support a form of packed decimal, although it's not quite >> natural as on mainframes. > > You can still use floating point for this. Restrict yourself to > integers with no more than the digits of precision supported by the > float, and scale as needed. And what would you gain from that compared to using an integer with the same umber of bits? (except lots of extra chances to create errors) Arne
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2016-07-15 11:37 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <f7biobljnl7i27cn4d7oe69vvl7ibp9m17@4ax.com> |
| In reply to | #34813 |
On Fri, 8 Jul 2016 20:11:59 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:
>On 7/8/2016 5:06 PM, Gene Wirchenko wrote:
[snip]
>> You can still use floating point for this. Restrict yourself to
>> integers with no more than the digits of precision supported by the
>> float, and scale as needed.
>
>And what would you gain from that compared to using an integer
>with the same umber of bits?
>
>(except lots of extra chances to create errors)
Certainly, I would prefer a wide-enough integer type, but
sometimes, there is not one.
In JavaScript, there is one number type. To a limited degree,
there are also 32-bit integers, but they are converted to and from.
Using the technique I mentioned, one can get 15 digits of
precision in JavaScript without too much -- though some -- bother.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-07-15 16:36 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nmbhgm$cnp$1@gioia.aioe.org> |
| In reply to | #34901 |
On 7/15/2016 2:37 PM, Gene Wirchenko wrote: > On Fri, 8 Jul 2016 20:11:59 -0400, Arne Vajhøj <arne@vajhoej.dk> > wrote: >> On 7/8/2016 5:06 PM, Gene Wirchenko wrote: >>> You can still use floating point for this. Restrict yourself to >>> integers with no more than the digits of precision supported by the >>> float, and scale as needed. >> >> And what would you gain from that compared to using an integer >> with the same umber of bits? >> >> (except lots of extra chances to create errors) > > Certainly, I would prefer a wide-enough integer type, but > sometimes, there is not one. In Java there is one. FORTRAN on some systems may have REAL*16 and INTEGER*8 as biggest. > In JavaScript, there is one number type. To a limited degree, > there are also 32-bit integers, but they are converted to and from. > > Using the technique I mentioned, one can get 15 digits of > precision in JavaScript without too much -- though some -- bother. JavaScript is a great language for many things, but I would not pick it for financial calculations. Arne
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2016-07-15 15:49 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <o1qiob9vdoph4m3q5r4fq35remf9vcomvk@4ax.com> |
| In reply to | #34906 |
On Fri, 15 Jul 2016 16:36:38 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:
[snip]
>JavaScript is a great language for many things, but I would not
>pick it for financial calculations.
"financial calculations" is rather vague. Adding up items on an
invoice is financial calculations.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-07-15 22:09 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nmc50v$12id$1@gioia.aioe.org> |
| In reply to | #34907 |
On 7/15/2016 6:49 PM, Gene Wirchenko wrote: > On Fri, 15 Jul 2016 16:36:38 -0400, Arne Vajhøj <arne@vajhoej.dk> > wrote: >> JavaScript is a great language for many things, but I would not >> pick it for financial calculations. > > "financial calculations" is rather vague. True. > Adding up items on an > invoice is financial calculations. Yes. And one of the cases where floating point should not be used. Arne
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-07-16 13:04 +0000 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nmdbcb$die$1@dont-email.me> |
| In reply to | #34910 |
On Fri, 15 Jul 2016 22:09:34 -0400, Arne Vajhøj wrote: > On 7/15/2016 6:49 PM, Gene Wirchenko wrote: >> On Fri, 15 Jul 2016 16:36:38 -0400, Arne Vajhøj <arne@vajhoej.dk> >> wrote: >>> JavaScript is a great language for many things, but I would not pick >>> it for financial calculations. >> >> "financial calculations" is rather vague. > > True. > >> Adding up items on an >> invoice is financial calculations. > > Yes. And one of the cases where floating point should not be used. > Exactly so - because addition is affected by the inexact numeric representation in the same way as multiplication or division. In fact those operations may be required during invoicing: if you're in a region where invoices must show taxation, i.e. sales tax or VAT, as well as the overall total, invoices may require more math than simple addition. This also affects invoices from multinationals who denominate them in the buyer's local currency. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2016-07-18 13:08 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <3pdqobtjvvggbu0h92ajhacqseto47sjns@4ax.com> |
| In reply to | #34910 |
On Fri, 15 Jul 2016 22:09:34 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:
>On 7/15/2016 6:49 PM, Gene Wirchenko wrote:
>> On Fri, 15 Jul 2016 16:36:38 -0400, Arne Vajhøj <arne@vajhoej.dk>
>> wrote:
>>> JavaScript is a great language for many things, but I would not
>>> pick it for financial calculations.
>>
>> "financial calculations" is rather vague.
>
>True.
>
>> Adding up items on an
>> invoice is financial calculations.
>
>Yes. And one of the cases where floating point should not be used.
But it can be used safely with certain limitations. And since
JavaScript only has one numeric type, one has to.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-07-18 19:56 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nmjqbv$1eq2$1@gioia.aioe.org> |
| In reply to | #34955 |
On 7/18/2016 4:08 PM, Gene Wirchenko wrote: > On Fri, 15 Jul 2016 22:09:34 -0400, Arne Vajhøj <arne@vajhoej.dk> > wrote: >> On 7/15/2016 6:49 PM, Gene Wirchenko wrote: >>> On Fri, 15 Jul 2016 16:36:38 -0400, Arne Vajhøj <arne@vajhoej.dk> >>> wrote: >>>> JavaScript is a great language for many things, but I would not >>>> pick it for financial calculations. >>> >>> "financial calculations" is rather vague. >> >> True. >> >>> Adding up items on an >>> invoice is financial calculations. >> >> Yes. And one of the cases where floating point should not be used. > > But it can be used safely with certain limitations. And since > JavaScript only has one numeric type, one has to. You could do that add server side a suitable type. Like BigDecimal in Java. Or similar in .NET. You could also use COBOL, but having COBOL return data directly to browser would be unusual. Or you could write something doing BCD math in JS. Alternatively you would need to invent a solid framework on how to detect reaching the mentioned limitations and handle that situation. That will likely be much more work. Deploying code that works in all simple cases now, but have a builtin problem that may cause it to break later is definitely not a good solution. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-08 20:59 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlpi9j$upm$1@jstuckle.eternal-september.org> |
| In reply to | #34804 |
On 7/8/2016 5:06 PM, Gene Wirchenko wrote: > On Fri, 8 Jul 2016 16:29:22 -0400, Jerry Stuckle > <jstucklex@attglobal.net> wrote: > >> 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: >>>> Monetary amounts almost always should be kept in integral variables >>>> (int or long) and scaled appropriately only upon I/O. (Exceptions >>>> might exist, though.) >>> >>> 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. >>> >> >> Financial institutions in the U.S. typically deal with at least four >> decimal places past the cents sign (six decimal places total). That's >> why COBOL is still so popular - it supports packed decimal natively. >> And IBM mainframes have support for packed decimal. Even Intel >> processors support a form of packed decimal, although it's not quite >> natural as on mainframes. > > You can still use floating point for this. Restrict yourself to > integers with no more than the digits of precision supported by the > float, and scale as needed. > > COBOL's way is much easier to deal with though. > > Sincerely, > > Gene Wirchenko > Not when you're talking figures in the hundreds of billions of dollars. Not even doubles will go to 999,999,999,999.999999. Packed decimal easily handles this and even larger. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-07-09 11:57 +0000 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlqorq$j9f$2@dont-email.me> |
| In reply to | #34816 |
On Fri, 08 Jul 2016 20:59:38 -0400, Jerry Stuckle wrote: > On 7/8/2016 5:06 PM, Gene Wirchenko wrote: >> On Fri, 8 Jul 2016 16:29:22 -0400, Jerry Stuckle >> <jstucklex@attglobal.net> wrote: >> >>> 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: >>>>> Monetary amounts almost always should be kept in integral variables >>>>> (int or long) and scaled appropriately only upon I/O. (Exceptions >>>>> might exist, though.) >>>> >>>> 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. >>>> >>>> >>> Financial institutions in the U.S. typically deal with at least four >>> decimal places past the cents sign (six decimal places total). That's >>> why COBOL is still so popular - it supports packed decimal natively. >>> And IBM mainframes have support for packed decimal. Even Intel >>> processors support a form of packed decimal, although it's not quite >>> natural as on mainframes. >> >> You can still use floating point for this. Restrict yourself to >> integers with no more than the digits of precision supported by the >> float, and scale as needed. >> >> COBOL's way is much easier to deal with though. >> >> Sincerely, >> >> Gene Wirchenko >> >> > Not when you're talking figures in the hundreds of billions of dollars. > Not even doubles will go to 999,999,999,999.999999. > > Packed decimal easily handles this and even larger. So does a 64 bit integer (long long int in C or long in Java) - by quite a margin as its safe up to 18 digits. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-09 09:39 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlquqv$jp0$1@jstuckle.eternal-september.org> |
| In reply to | #34820 |
On 7/9/2016 7:57 AM, Martin Gregorie wrote: > On Fri, 08 Jul 2016 20:59:38 -0400, Jerry Stuckle wrote: > >> On 7/8/2016 5:06 PM, Gene Wirchenko wrote: >>> On Fri, 8 Jul 2016 16:29:22 -0400, Jerry Stuckle >>> <jstucklex@attglobal.net> wrote: >>> >>>> 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: >>>>>> Monetary amounts almost always should be kept in integral variables >>>>>> (int or long) and scaled appropriately only upon I/O. (Exceptions >>>>>> might exist, though.) >>>>> >>>>> 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. >>>>> >>>>> >>>> Financial institutions in the U.S. typically deal with at least four >>>> decimal places past the cents sign (six decimal places total). That's >>>> why COBOL is still so popular - it supports packed decimal natively. >>>> And IBM mainframes have support for packed decimal. Even Intel >>>> processors support a form of packed decimal, although it's not quite >>>> natural as on mainframes. >>> >>> You can still use floating point for this. Restrict yourself to >>> integers with no more than the digits of precision supported by the >>> float, and scale as needed. >>> >>> COBOL's way is much easier to deal with though. >>> >>> Sincerely, >>> >>> Gene Wirchenko >>> >>> >> Not when you're talking figures in the hundreds of billions of dollars. >> Not even doubles will go to 999,999,999,999.999999. >> >> Packed decimal easily handles this and even larger. > > So does a 64 bit integer (long long int in C or long in Java) - by quite > a margin as its safe up to 18 digits. > > And how long has that been available? It wasn't there even with 32 bit processors in most compilers. Packed Decimal has been in use since the 60's. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-07-09 14:43 +0000 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlr2j5$t5b$3@dont-email.me> |
| In reply to | #34823 |
On Sat, 09 Jul 2016 09:39:52 -0400, Jerry Stuckle wrote: > On 7/9/2016 7:57 AM, Martin Gregorie wrote: > And how long has that been available? It wasn't there even with 32 bit > processors in most compilers. Packed Decimal has been in use since the > 60's. > And the machines of that era that used BCD had hardware support for BCD arithmetic. Nowadays that only ones that still have that are mostly IBM big iron. They only have it to run legacy code. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-09 11:15 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlr4eh$6ke$2@jstuckle.eternal-september.org> |
| In reply to | #34828 |
On 7/9/2016 10:43 AM, Martin Gregorie wrote: > On Sat, 09 Jul 2016 09:39:52 -0400, Jerry Stuckle wrote: > >> On 7/9/2016 7:57 AM, Martin Gregorie wrote: >> And how long has that been available? It wasn't there even with 32 bit >> processors in most compilers. Packed Decimal has been in use since the >> 60's. >> > And the machines of that era that used BCD had hardware support for BCD > arithmetic. Nowadays that only ones that still have that are mostly IBM > big iron. They only have it to run legacy code. > > Incorrect. Even Intel chips support a form of BCD. And no, it's not just for legacy code. It's because it is needed by financial institutions and governments. Even 64 bit integers won't work for the U.S. Government, for instance. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-09 09:46 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlqv6f$lde$2@jstuckle.eternal-september.org> |
| In reply to | #34820 |
On 7/9/2016 7:57 AM, Martin Gregorie wrote: > On Fri, 08 Jul 2016 20:59:38 -0400, Jerry Stuckle wrote: > >> On 7/8/2016 5:06 PM, Gene Wirchenko wrote: >>> On Fri, 8 Jul 2016 16:29:22 -0400, Jerry Stuckle >>> <jstucklex@attglobal.net> wrote: >>> >>>> 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: >>>>>> Monetary amounts almost always should be kept in integral variables >>>>>> (int or long) and scaled appropriately only upon I/O. (Exceptions >>>>>> might exist, though.) >>>>> >>>>> 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. >>>>> >>>>> >>>> Financial institutions in the U.S. typically deal with at least four >>>> decimal places past the cents sign (six decimal places total). That's >>>> why COBOL is still so popular - it supports packed decimal natively. >>>> And IBM mainframes have support for packed decimal. Even Intel >>>> processors support a form of packed decimal, although it's not quite >>>> natural as on mainframes. >>> >>> You can still use floating point for this. Restrict yourself to >>> integers with no more than the digits of precision supported by the >>> float, and scale as needed. >>> >>> COBOL's way is much easier to deal with though. >>> >>> Sincerely, >>> >>> Gene Wirchenko >>> >>> >> Not when you're talking figures in the hundreds of billions of dollars. >> Not even doubles will go to 999,999,999,999.999999. >> >> Packed decimal easily handles this and even larger. > > So does a 64 bit integer (long long int in C or long in Java) - by quite > a margin as its safe up to 18 digits. > > I should also add that even with 64 bit integers you are at the limit. You couldn't go even one more decimal place. You aren't even close with packed decimal. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-07-09 15:21 +0000 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlr4qn$t5b$4@dont-email.me> |
| In reply to | #34825 |
On Sat, 09 Jul 2016 09:46:00 -0400, Jerry Stuckle wrote: > I should also add that even with 64 bit integers you are at the limit. > You couldn't go even one more decimal place. You aren't even close with > packed decimal. > But does anybody care? If we assume dollars held as binary cents, that holds values of up to 10^16 dollars: $9,999,999,999,999,999 or ten million billion dollars. Derivatives are estimated at = 1.2 x 10^15 Currency,bank accounts and savings = 8 x 10^13 Stock markets = 7 x 10^13 Debt = 1.19 x 10^13 Real estate = 7.5 x 10^12 Bitcoin = 5 x 10^9 Total = 1.37 x 10^15 So, that fits into a 64 bit integer and still leaves room for 7.3 times that value to be added. And, as it happens, COBOL compilers restrict decimal number to no more than 18 digits. This is the stated limit in the CODASYL language specification. IOW this is the same as a dollar and cent value that will fit in a binary 64bit integer. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-09 11:27 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlr54b$977$1@jstuckle.eternal-september.org> |
| In reply to | #34831 |
On 7/9/2016 11:21 AM, Martin Gregorie wrote: > On Sat, 09 Jul 2016 09:46:00 -0400, Jerry Stuckle wrote: > >> I should also add that even with 64 bit integers you are at the limit. >> You couldn't go even one more decimal place. You aren't even close with >> packed decimal. >> > But does anybody care? If we assume dollars held as binary cents, that > holds values of up to 10^16 dollars: $9,999,999,999,999,999 or ten > million billion dollars. > > Derivatives are estimated at = 1.2 x 10^15 > Currency,bank accounts and savings = 8 x 10^13 > Stock markets = 7 x 10^13 > Debt = 1.19 x 10^13 > Real estate = 7.5 x 10^12 > Bitcoin = 5 x 10^9 > > Total = 1.37 x 10^15 > > So, that fits into a 64 bit integer and still leaves room for 7.3 times > that value to be added. > > And, as it happens, COBOL compilers restrict decimal number to no more > than 18 digits. This is the stated limit in the CODASYL language > specification. > > IOW this is the same as a dollar and cent value that will fit in a binary > 64bit integer. > > Not when you need to go to six decimal places (four past the cents), as is done in fincancial institutions. And no, PACKED DECIMAL can go to at least 31 digits on many systems. See https://publib.boulder.ibm.com/iseries/v5r1/ic2924/books/c0925083170.htm, for instance. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2016-07-15 11:39 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <6cbiob184r55h86pg11p45gkkmg4c877tu@4ax.com> |
| In reply to | #34816 |
On Fri, 8 Jul 2016 20:59:38 -0400, Jerry Stuckle
<jstucklex@attglobal.net> wrote:
[snip]
>Not when you're talking figures in the hundreds of billions of dollars.
>Not even doubles will go to 999,999,999,999.999999.
Any type has limitations. I can get 15 digits of precision in
JavaScript. That is enough for unit trillions with two decimal
digits.
>Packed decimal easily handles this and even larger.
When it is available.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-15 15:38 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nmbe3e$3er$1@jstuckle.eternal-september.org> |
| In reply to | #34902 |
On 7/15/2016 2:39 PM, Gene Wirchenko wrote: > On Fri, 8 Jul 2016 20:59:38 -0400, Jerry Stuckle > <jstucklex@attglobal.net> wrote: > > [snip] >> Not when you're talking figures in the hundreds of billions of dollars. >> Not even doubles will go to 999,999,999,999.999999. > > Any type has limitations. I can get 15 digits of precision in > JavaScript. That is enough for unit trillions with two decimal > digits. > How about with six decimal digits - as financial calculations require? It doesn't even make it to one billion. Also, who cares about javascript? >> Packed decimal easily handles this and even larger. > > When it is available. > Which is a big reason why COBOL is still the most commonly used language in finance (including banks, insurance companies and governments). > Sincerely, > > Gene Wirchenko > -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2016-07-15 15:52 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <e5qiob5msltgi6fethiagdvu7q810nvf79@4ax.com> |
| In reply to | #34905 |
On Fri, 15 Jul 2016 15:38:25 -0400, Jerry Stuckle
<jstucklex@attglobal.net> wrote:
>On 7/15/2016 2:39 PM, Gene Wirchenko wrote:
>> On Fri, 8 Jul 2016 20:59:38 -0400, Jerry Stuckle
>> <jstucklex@attglobal.net> wrote:
>>
>> [snip]
>>> Not when you're talking figures in the hundreds of billions of dollars.
>>> Not even doubles will go to 999,999,999,999.999999.
>>
>> Any type has limitations. I can get 15 digits of precision in
>> JavaScript. That is enough for unit trillions with two decimal
>> digits.
>How about with six decimal digits - as financial calculations require?
>It doesn't even make it to one billion.
Which financial calculations are those? Certainly not all of
them.
>Also, who cares about javascript?
People who snipe about it is one group.
>>> Packed decimal easily handles this and even larger.
>>
>> When it is available.
>Which is a big reason why COBOL is still the most commonly used language
>in finance (including banks, insurance companies and governments).
Of course.
But when one has lemons ...
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-15 19:19 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nmbr2m$iej$1@jstuckle.eternal-september.org> |
| In reply to | #34908 |
On 7/15/2016 6:52 PM, Gene Wirchenko wrote: > On Fri, 15 Jul 2016 15:38:25 -0400, Jerry Stuckle > <jstucklex@attglobal.net> wrote: > >> On 7/15/2016 2:39 PM, Gene Wirchenko wrote: >>> On Fri, 8 Jul 2016 20:59:38 -0400, Jerry Stuckle >>> <jstucklex@attglobal.net> wrote: >>> >>> [snip] >>>> Not when you're talking figures in the hundreds of billions of dollars. >>>> Not even doubles will go to 999,999,999,999.999999. >>> >>> Any type has limitations. I can get 15 digits of precision in >>> JavaScript. That is enough for unit trillions with two decimal >>> digits. > >> How about with six decimal digits - as financial calculations require? >> It doesn't even make it to one billion. > > Which financial calculations are those? Certainly not all of > them. > If you would have read the thread - banks, insurance companies, government... Lots of big businesses. >> Also, who cares about javascript? > > People who snipe about it is one group. > Not appropriate for a Java newsgroup. There IS a difference! >>>> Packed decimal easily handles this and even larger. >>> >>> When it is available. > >> Which is a big reason why COBOL is still the most commonly used language >> in finance (including banks, insurance companies and governments). > > Of course. > > But when one has lemons ... > > Sincerely, > > Gene Wirchenko > When one has a need, they pick the appropriate solution for that need. Lemons are no help when your need is a milk shake. It doesn't matter how many you have. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 3 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