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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Andreas Leitgeb <avl@logic.at> |
|---|---|
| Date | 2016-07-03 21:10 +0000 |
| Message-ID | <slrnnnivqf.456.avl@login.logic.tuwien.ac.at> |
| In reply to | #34749 |
Lew <lewbloch@gmail.com> wrote: > Or you could just use the FQN for one of the conflicting types. > Whatever is the big effing deal about that? The "effing deal" is avoiding redundant verbosity - essentially the same kind of thing of which existing "import" addresses maybe 99%(*) of cases. (*): 98.57532% of such figures are based solely on subjective experience.
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2016-07-04 16:08 -0700 |
| Message-ID | <128e7e20-d311-413d-abbc-e885b34ae402@googlegroups.com> |
| In reply to | #34752 |
Andreas Leitgeb wrote: > Lew wrote: > > Or you could just use the FQN for one of the conflicting types. > > Whatever is the big effing deal about that? > > The "effing deal" is avoiding redundant verbosity - essentially the same > kind of thing of which existing "import" addresses maybe 99%(*) of cases. > > (*): 98.57532% of such figures are based solely on subjective experience. It's not exactly redundant if it distinguishes the distinct. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Mike Amling <mamling@chaff.us> |
|---|---|
| Date | 2016-07-05 11:23 -0500 |
| Subject | Program proof |
| Message-ID | <nlgmte$3o3$1@dont-email.me> |
| In reply to | #34754 |
Forgive my ignorance but can anyone suggest a newgroup or stackoverflow
category or other URL that deals with proving programs correct?
If it helps, my goal is to prove that the following heuristically
derived method nextGreater works on all trees, not just the ones I've
tested it on.
/**
* A Node is an element of a tree graph (acyclic). Each
* Node xx can have up to two descendents, returned by
* xx.getLeft and xx.getRight.
* For any Node xx, if xx.getLeft is not null,
* xx.getLeft().getParent()==xx.
* For any Node xx, if xx.getRight is not null,
* xx.getRight().getParent()==xx.
* There is exactly one Node root for which
* root.getParent is null.
* For any Node xx, all keys of Nodes in the subtree
* rooted at xx.getLeft are less than xx's key.
* For any Node xx, all keys of Nodes in the subtree
* rooted at xx.getRight are greater than xx's key.
*/
public abstract class Node {
public abstract Node getLeft();
public abstract Node getRight();
public abstract Node getParent();
/**
* Return the tree node with the smallest key greater than
* this node's key, if any. Do not rearrange any nodes.
* @return the tree node with the smallest key greater than
* this node's key, or <code>null</code> if no node in the
* tree has a key greater than this node's key
*/
public Node nextGreater() {
Node oneRightAllLeft=this.getRight();
if (oneRightAllLeft!=null) {
while (oneRightAllLeft.getLeft()!=null) {
oneRightAllLeft=oneRightAllLeft.getLeft();
}
return oneRightAllLeft;
}
for (Node scan=this; ; ) {
final Node elder=scan.getParent();
if (elder==null || elder.getLeft()==scan) {
return elder;
}
scan=elder;
}
}
} // End class Node
--Mike Amling
[toc] | [prev] | [next] | [standalone]
| From | Andreas Leitgeb <avl@logic.at> |
|---|---|
| Date | 2016-07-05 18:08 +0000 |
| Subject | Re: Program proof |
| Message-ID | <slrnnnntsf.456.avl@login.logic.tuwien.ac.at> |
| In reply to | #34758 |
Mike Amling <mamling@chaff.us> wrote:
> If it helps, my goal is to prove that the following heuristically
> derived method nextGreater works on all trees, not just the ones I've
> tested it on.
proving algorithms involves
- formalizing the entry-conditions - in this case that's the
list of the tree conditions
- any "if" will add a condition to the set of known true conditions
for the current spot within program flow,
and any "else" will of course see the negated condition added.
- for loops you need to find a "loop-invariant": a condition
that will remain true for all iterations, that is deducible
from the entry conditions, and strong enough to be able to
later imply correctness of state upon exit.
- what immediately follows a loop will have the loop-invariant
and any exit-conditions of the loop.
In the end, the expected result ought to be deducible from the
conditions of each flow leading to an exit.
Finding an appropriate and useful loop-invariant is the hardest part.
This is, what cannot be automatically deduced, but for some algorithms
it is still quite feasible to just find one.
Beyond proving correctness on exit, you might also need to prove that
this exit is actually always reached, otherwise adding a simple endless
loop at the start would make any algorithm "correct" ;-)
> public Node nextGreater() {
> Node oneRightAllLeft=this.getRight();
> if (oneRightAllLeft!=null) {
For example, here you get the extra condition, that there exists
at least one greater value below the current node. (assuming root
node is at top)
[toc] | [prev] | [next] | [standalone]
| From | Andreas Leitgeb <avl@logic.at> |
|---|---|
| Date | 2016-07-05 17:23 +0000 |
| Message-ID | <slrnnnnr8l.456.avl@login.logic.tuwien.ac.at> |
| In reply to | #34754 |
Lew <lewbloch@gmail.com> wrote: > Andreas Leitgeb wrote: >> Lew wrote: >> > Or you could just use the FQN for one of the conflicting types. >> > Whatever is the big effing deal about that? >> The "effing deal" is avoiding redundant verbosity - essentially the same >> kind of thing of which existing "import" addresses maybe 99%(*) of cases. >> (*): 98.57532% of such figures are based solely on subjective experience. > It's not exactly redundant if it distinguishes the distinct. When a compression algorithm reduces redundancy of data, it doesn't completely eliminate the data, either.
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2016-07-05 14:28 -0700 |
| Message-ID | <87dc5bee-f689-4f2e-90a8-a43a2de9fe49@googlegroups.com> |
| In reply to | #34759 |
Andreas Leitgeb wrote: > Lew wrote: > > Andreas Leitgeb wrote: > >> Lew wrote: > >> > Or you could just use the FQN for one of the conflicting types. > >> > Whatever is the big effing deal about that? > >> The "effing deal" is avoiding redundant verbosity - essentially the same > >> kind of thing of which existing "import" addresses maybe 99%(*) of cases. > >> (*): 98.57532% of such figures are based solely on subjective experience. > > It's not exactly redundant if it distinguishes the distinct. > > When a compression algorithm reduces redundancy of data, it doesn't > completely eliminate the data, either. I'm just saying that the FQN is not redundant. It is the full name. The simple name is an abbreviation. I'm not sure how much "verbosity" is involved, but it is really, really tiny. The "verbosity" of which you complain is the length of namespace needed to distinguish distinct sources. In practice we use the simple name almost all the time; the number of times you have a name conflict in practical code is negligible. So all this "verbosity" you fear (why? Are you afraid you'll sprain a finger typing?) is almost never there; you typically use the abbreviation for the type name rather than the whole thing. This is a tempest in a teapot. A non-problem that has occupied our minds about as usefully as asking how many angels can dance on the head of a pin. For that one-tenth of one-thousandth of a percent of all code where this is an issue, just let your IDE autocomplete the type for you and chill the frak out. The existing mechanism is just fine, and free of the perils with which others' suggestions here are fraught. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Andreas Leitgeb <avl@logic.at> |
|---|---|
| Date | 2016-07-07 15:22 +0000 |
| Message-ID | <slrnnnsssr.456.avl@login.logic.tuwien.ac.at> |
| In reply to | #34761 |
Lew <lewbloch@gmail.com> wrote: > Andreas Leitgeb wrote: >> Lew wrote: >> > Andreas Leitgeb wrote: >> >> Lew wrote: >> >> > Or you could just use the FQN for one of the conflicting types. >> >> > Whatever is the big effing deal about that? >> >> The "effing deal" is avoiding redundant verbosity - essentially the same >> >> kind of thing of which existing "import" addresses maybe 99%(*) of cases. >> >> (*): 98.57532% of such figures are based solely on subjective experience. >> > It's not exactly redundant if it distinguishes the distinct. >> When a compression algorithm reduces redundancy of data, it doesn't >> completely eliminate the data, either. > I'm just saying that the FQN is not redundant. *In the context of a compilation unit* the whole package path is highly redundant (in the sense that it could be shortened, though not always eliminated). > It is the full name. The simple name is an abbreviation. I don't dispute that at all. I just find it a pity, that in Java (as of now) the simple name is the *only* possible abbreviation for a full name. I'd prefer to be able to choose an abbreviation on my own, based on how the foreign class name fits better into my local context. By "coincidence" (or "as a dead give away") that would then also allow to abbreviate more than one among namesake classes from different packages. I'd even go one step further: I'd also like to set up names as alias for a parameterized generic class like List<String>. Especially with nested Maps that could make code much more readable. And then again, I know that posting it here is about as effective as praying to some deity ;-) (So just consider it as some kind of smalltalk and chill.)
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-07-07 11:44 -0400 |
| Message-ID | <nlltdh$1u0$1@dont-email.me> |
| In reply to | #34770 |
On 7/7/2016 11:22 AM, Andreas Leitgeb wrote:
> [...]
> I'd even go one step further: I'd also like to set up names
> as alias for a parameterized generic class like List<String>.
> Especially with nested Maps that could make code much more
> readable.
class MyClass {
private static interface MyList extends List<String> {
// Inherit everything ...
}
...
private Map<String,MyList> map = new HashMap<>();
...
}
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-07-07 12:57 -0400 |
| Message-ID | <nlm1lh$iat$1@dont-email.me> |
| In reply to | #34771 |
On 7/7/2016 11:44 AM, Eric Sosman wrote:
> On 7/7/2016 11:22 AM, Andreas Leitgeb wrote:
>> [...]
>> I'd even go one step further: I'd also like to set up names
>> as alias for a parameterized generic class like List<String>.
>> Especially with nested Maps that could make code much more
>> readable.
>
> class MyClass {
>
> private static interface MyList extends List<String> {
> // Inherit everything ...
> }
> ...
> private Map<String,MyList> map = new HashMap<>();
> ...
> }
It occurs to me that this isn't quite enough all by itself: You
also need some concrete classes that implement MyList. But you can
get them with the same hack:
private static class MyArrayList extends ArrayList<String>
implements MyList {
// Inherit everything ...
}
private static class MyLinkedList extends LinkedList<String>
implements MyList {
// Inherit everything ...
}
Even this isn't suitable for all uses: You can't, for example,
take a user-supplied ArrayList<String> and just drop it into the map.
Still, if you want it "for internal use" and want it badly enough ...
Speaking for myself, I don't think it's worth the trouble. Even
though I gnash my teeth when forced to write
for (Iterator<Map.Entry<URI,Callable<Collection<Image>>>>
it = map.entrySet(); it.hasNext(); {
(which always seems to be the most irritating situation), I go ahead and
write it out. And gnash my teeth, and tilt at other windmills instead.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Andreas Leitgeb <avl@logic.at> |
|---|---|
| Date | 2016-07-07 18:29 +0000 |
| Message-ID | <slrnnnt7ri.456.avl@login.logic.tuwien.ac.at> |
| In reply to | #34772 |
Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
> On 7/7/2016 11:44 AM, Eric Sosman wrote:
>> On 7/7/2016 11:22 AM, Andreas Leitgeb wrote:
>>> [...]
>>> I'd even go one step further: I'd also like to set up names
>>> as alias for a parameterized generic class like List<String>.
>>> Especially with nested Maps that could make code much more
>>> readable.
>> [... some bungle of bridge-classes that just don't solve it ...]
> Even this isn't suitable for all uses: You can't, for example,
> take a user-supplied ArrayList<String> and just drop it into the map.
> Speaking for myself, I don't think it's worth the trouble.
> Even though I gnash my teeth when forced to write
> for (Iterator<Map.Entry<URI,Callable<Collection<Image>>>>
> it = map.entrySet(); it.hasNext(); {
> (which always seems to be the most irritating situation), I go ahead and
> write it out. And gnash my teeth, and tilt at other windmills instead.
Its not like we had much of a choice besides "write it out & gnash teeth"...
"other windmills" ... also Java-related?
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-07-07 15:48 -0400 |
| Subject | [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlmbm6$ndk$1@dont-email.me> |
| In reply to | #34773 |
On 7/7/2016 2:29 PM, Andreas Leitgeb wrote: > Eric Sosman <esosman@comcast-dot-net.invalid> wrote: >> [...] >> (which always seems to be the most irritating situation), I go ahead and >> write it out. And gnash my teeth, and tilt at other windmills instead. > > Its not like we had much of a choice besides "write it out & gnash teeth"... > > "other windmills" ... also Java-related? https://en.wikipedia.org/wiki/Tilting_at_windmills -- esosman@comcast-dot-net.invalid "Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Andreas Leitgeb <avl@logic.at> |
|---|---|
| Date | 2016-07-08 08:01 +0000 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <slrnnnunec.456.avl@login.logic.tuwien.ac.at> |
| In reply to | #34774 |
Eric Sosman <esosman@comcast-dot-net.invalid> wrote: > On 7/7/2016 2:29 PM, Andreas Leitgeb wrote: >> Eric Sosman <esosman@comcast-dot-net.invalid> wrote: >>> [...] >>> (which always seems to be the most irritating situation), I go ahead and >>> write it out. And gnash my teeth, and tilt at other windmills instead. >> Its not like we had much of a choice besides "write it out & gnash teeth"... >> "other windmills" ... also Java-related? > https://en.wikipedia.org/wiki/Tilting_at_windmills Looked at it, just to find the obvious meaning (as a reference to Don Quixote) confirmed. I was asking, if those other windmills were also related to features perceived as lacking in Java, or some entirely other domain?
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-07-08 08:25 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlo63s$293$1@dont-email.me> |
| In reply to | #34782 |
On 7/8/2016 4:01 AM, Andreas Leitgeb wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>> On 7/7/2016 2:29 PM, Andreas Leitgeb wrote:
>>> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>>>> [...]
>>>> (which always seems to be the most irritating situation), I go ahead and
>>>> write it out. And gnash my teeth, and tilt at other windmills instead.
>>> Its not like we had much of a choice besides "write it out & gnash teeth"...
>>> "other windmills" ... also Java-related?
>> https://en.wikipedia.org/wiki/Tilting_at_windmills
>
> Looked at it, just to find the obvious meaning (as a reference to Don Quixote)
> confirmed.
>
> I was asking, if those other windmills were also related to features perceived
> as lacking in Java, or some entirely other domain?
Sorry; I thought perhaps I had erred by confronting an Austrian
with an English idiom. This sense of the verb "tilt" is almost never
used nowadays except in reference to Quixote's windmill adventure, and
I feared I might have misled you. Glad I didn't.
(Sometimes the literal translation of an idiom is of no help at all,
and one must simply learn the meaning by rote. That's why "Take him
for a ride" means "Nimm ihn um die Ecke," or so I'm told, even though
neither translates to the other.)
Anyhow: Java presents lots of annoyances, some petty and some more
troublesome, but those aren't the windmills I tilt at. I'd like it if
Java had unsigned arithmetic and if signed integer overflow threw an
exception instead of wrapping around silently and sneakily -- but that's
not going to happen. I'd like it if primitive types were more like
objects, so I could have things like a `List<float>'. I'd like to add
and multiply BigIntegers with `+' and `*'. Occasionally I'd like to use
something like a `typedef' to address some of the issues covered in this
thread. But I have a more realistic estimate of my powers than did the
Don, so I leave those windmills to other giant-slayers.
Instead, alas, I struggle against the problems I myself put in my
own path. Most of my troubles are self-inflicted, most of my windmills
are self-erected, and I tilt at them endlessly, or so it seems. My own
faults are more troublesome than Java's ...
--
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-08 06:55 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <c28c0b50-9105-4a51-930f-8721c3ed5bfd@googlegroups.com> |
| In reply to | #34785 |
On Friday, July 8, 2016 at 8:25:46 AM UTC-4, Eric Sosman wrote: > Anyhow: Java presents lots of annoyances, some petty and some more > troublesome, but those aren't the windmills I tilt at. I'd like it if > Java had unsigned arithmetic and if signed integer overflow threw an > exception instead of wrapping around silently and sneakily -- but that's > not going to happen. I'd like it if primitive types were more like > objects, so I could have things like a `List<float>'. I'd like to add > and multiply BigIntegers with `+' and `*'. Occasionally I'd like to use > something like a `typedef' to address some of the issues covered in this > thread. But I have a more realistic estimate of my powers than did the > Don, so I leave those windmills to other giant-slayers. I'd prefer if Java did normal math by default with a custom class to do floating point math instead of the other way around. Why, if you add 1 + 1 using double type values would you want the result to be 1.99999999999998? It is tedious to do normal application math by converting the double to a String and passing it into a BigDecimal. Primitives are sort of Objects now. Perhaps you can't make a List<float> but float and Float are interchangeable and you can make a List<Float>.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-07-08 10:16 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlocjc$pmu$1@dont-email.me> |
| In reply to | #34786 |
On 7/8/2016 9:55 AM, Eric Douglas wrote:
> On Friday, July 8, 2016 at 8:25:46 AM UTC-4, Eric Sosman wrote:
>> Anyhow: Java presents lots of annoyances, some petty and some more
>> troublesome, but those aren't the windmills I tilt at. I'd like it if
>> Java had unsigned arithmetic and if signed integer overflow threw an
>> exception instead of wrapping around silently and sneakily -- but that's
>> not going to happen. I'd like it if primitive types were more like
>> objects, so I could have things like a `List<float>'. I'd like to add
>> and multiply BigIntegers with `+' and `*'. Occasionally I'd like to use
>> something like a `typedef' to address some of the issues covered in this
>> thread. But I have a more realistic estimate of my powers than did the
>> Don, so I leave those windmills to other giant-slayers.
>
> I'd prefer if Java did normal math by default with a custom class to do floating point math instead of the other way around. Why, if you add 1 + 1 using double type values would you want the result to be 1.99999999999998?
No one would want that. Also, no one experiences that (not in Java,
at any rate). I get your point, though, that floating-point arithmetic
can be surprising.
> It is tedious to do normal application math by converting the double to a String and passing it into a BigDecimal.
YMMV, but the only occasions when I've resorted to BigDecimal were
those few when I dealt not with "numbers" but with "money." Financial
calculations sometimes require very tight control of rounding and of
precision, control that is overwhelmingly difficult to exercise over
floating-point arithmetic.
> Primitives are sort of Objects now. Perhaps you can't make a List<float> but float and Float are interchangeable and you can make a List<Float>.
On my system, `Float' uses sixteen bytes to `float's four. It's
worse, though: to use a `Float' you also need a reference that points
to it, which (on my system) is another four bytes. Put it all together,
and `Float' takes at least five times the memory of `float' and puts
about five times as much strain on caches.
`float' and `Float' are "interchangeable" in the same sense that
memory is "free."
--
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-08 07:35 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <638a1d64-f125-4456-a20b-4dbf45f49da2@googlegroups.com> |
| In reply to | #34788 |
On Friday, July 8, 2016 at 10:16:23 AM UTC-4, Eric Sosman wrote:
> No one would want that. Also, no one experiences that (not in Java,
> at any rate). I get your point, though, that floating-point arithmetic
> can be surprising.
I don't know if or how it happens with whole numbers offhand but it's definitely an issue with decimals, and that is more than financials. When you're trying to write an application that manages inventory quantities and calculates the decimals as in to represent the percentage of a can of paint, then this is a problem.
Program:
double a = .0002;
double b = .0001;
System.out.println(a + b);
Result:
3.0000000000000003E-4
> `float' and `Float' are "interchangeable" in the same sense that
> memory is "free."
If it's one variable, 16 bytes is irrelevant anymore. If it could create thousands of the variable, 16 bytes could add up. It could still be cheaper than the current alternative. How else would you store your floats? You could create a float[] but that could get much more expensive if you need to dynamically add a variable number of floats.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Leitgeb <avl@logic.at> |
|---|---|
| Date | 2016-07-08 18:07 +0000 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <slrnnnvqum.456.avl@login.logic.tuwien.ac.at> |
| In reply to | #34789 |
Eric Douglas <e.d.programmer@gmail.com> wrote: > I don't know if or how it happens with whole numbers offhand but it's > definitely an issue with decimals, and that is more than financials. Financials and floating point (float & double) just don't mix well. Monetary amounts almost always should be kept in integral variables (int or long) and scaled appropriately only upon I/O. (Exceptions might exist, though.) > 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.
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-07-08 12:54 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <60a5ccde-2657-48d6-b3dd-04ec1a0973ab@googlegroups.com> |
| In reply to | #34800 |
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.
> > 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
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-08 16:29 -0400 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <nlp2er$dgg$1@jstuckle.eternal-september.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: >> 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. -- ================== 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-08 14:06 -0700 |
| Subject | Re: [OT] Re: missing import java.lang.Comparable |
| Message-ID | <ra50obpr4u0h974pt9gkmhr8vp70dc01bh@4ax.com> |
| In reply to | #34803 |
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
[toc] | [prev] | [next] | [standalone]
Page 2 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