Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #5905 > unrolled thread
| Started by | rop rop <rop049@gmail.com> |
|---|---|
| First post | 2011-07-06 08:35 -0700 |
| Last post | 2011-07-09 12:16 -0700 |
| Articles | 20 on this page of 277 — 46 participants |
Back to article view | Back to comp.lang.java.programmer
Arithmetic overflow checking rop rop <rop049@gmail.com> - 2011-07-06 08:35 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-06 09:42 -0700
Re: Arithmetic overflow checking stefan@nyniva.se - 2011-07-06 11:30 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-06 11:36 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-18 23:06 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-06 10:16 -0700
Re: Arithmetic overflow checking "John B. Matthews" <nospam@nospam.invalid> - 2011-07-07 02:26 -0400
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-18 23:07 -0400
Re: Arithmetic overflow checking Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-07 07:11 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-07 10:02 -0700
Re: Arithmetic overflow checking Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-07 17:51 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-07 20:04 -0700
Re: Arithmetic overflow checking Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-07 20:29 -0700
Re: Arithmetic overflow checking rop rop <rop049@gmail.com> - 2011-07-08 15:52 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-18 23:12 -0400
Re: Arithmetic overflow checking Tom Anderson <twic@urchin.earth.li> - 2011-07-09 10:31 +0100
Re: Arithmetic overflow checking rop rop <rop049@gmail.com> - 2011-07-09 02:58 -0700
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-09 08:53 -0400
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-09 07:46 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-18 23:17 -0400
Re: Arithmetic overflow checking Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-18 23:22 -0700
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-10 01:47 -0700
Re: Arithmetic overflow checking China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-10 02:47 -0700
Re: Arithmetic overflow checking pete <pfiland@mindspring.com> - 2011-07-10 06:04 -0400
Re: Arithmetic overflow checking China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-10 03:29 -0700
Re: Arithmetic overflow checking Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-10 20:52 +0300
Re: Arithmetic overflow checking pete <pfiland@mindspring.com> - 2011-07-10 23:29 -0400
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-10 04:44 -0700
Re: Arithmetic overflow checking "BartC" <bc@freeuk.com> - 2011-07-12 11:33 +0100
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 04:17 -0700
Re: Arithmetic overflow checking "BartC" <bc@freeuk.com> - 2011-07-12 12:33 +0100
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 05:24 -0700
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-12 21:45 -0400
Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-12 05:25 -0700
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 10:21 -0700
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 23:54 -0700
Re: Arithmetic overflow checking "BartC" <bc@freeuk.com> - 2011-07-12 19:14 +0100
Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-13 00:20 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-12 09:26 -0700
Re: Arithmetic overflow checking Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-12 10:52 -0600
Re: Arithmetic overflow checking Keith Thompson <kst-u@mib.org> - 2011-07-12 10:48 -0700
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-12 16:54 +0000
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-12 11:35 -0700
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 10:13 -0700
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-12 21:53 -0400
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-14 23:41 -0500
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-15 10:56 -0700
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-15 21:27 -0500
Re: Arithmetic overflow checking bugbear <bugbear@trim_papermule.co.uk_trim> - 2011-07-20 09:22 +0100
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-20 10:51 -0700
Re: Arithmetic overflow checking gordonb.3urm7@burditt.org (Gordon Burditt) - 2011-07-20 15:39 -0500
Re: Arithmetic overflow checking "BartC" <bc@freeuk.com> - 2011-07-21 12:12 +0100
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-10 09:28 -0400
Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-10 06:52 -0700
Re: Arithmetic overflow checking Keith Thompson <kst-u@mib.org> - 2011-07-10 14:47 -0700
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-14 23:07 -0500
Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-10 12:25 -0400
Re: Arithmetic overflow checking Robert Wessel <robertwessel2@yahoo.com> - 2011-07-10 10:47 -0500
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 07:58 -0700
Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-11 10:48 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 14:40 -0700
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-11 14:54 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 15:55 -0700
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-11 21:51 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 21:31 -0700
Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-11 23:16 -0700
Re: Arithmetic overflow checking James Kuyper <jameskuyper@verizon.net> - 2011-07-12 06:28 -0400
Re: Arithmetic overflow checking David Thompson <dave.thompson2@verizon.net> - 2011-07-24 22:13 -0400
Re: Arithmetic overflow checking Lew Pitcher <lpitcher@teksavvy.com> - 2011-07-25 10:24 -0400
Re: Arithmetic overflow checking "io_x" <a@b.c.invalid> - 2011-07-12 09:05 +0200
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 02:22 -0700
Re: Arithmetic overflow checking "io_x" <a@b.c.invalid> - 2011-07-12 11:34 +0200
Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-12 03:04 -0700
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 03:33 -0700
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-12 08:29 -0400
Re: Arithmetic overflow checking "io_x" <a@b.c.invalid> - 2011-07-12 13:18 +0200
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-12 11:39 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-12 12:38 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-12 13:20 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-12 13:23 -0700
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-12 21:08 +0000
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-12 14:48 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-12 15:24 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-12 16:09 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-13 10:38 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-13 11:00 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-13 12:16 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-13 13:10 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-13 13:21 -0700
Re: Arithmetic overflow checking Keith Thompson <kst-u@mib.org> - 2011-07-13 13:41 -0700
Re: Arithmetic overflow checking Robert Wessel <robertwessel2@yahoo.com> - 2011-07-14 21:10 -0500
Re: Arithmetic overflow checking "io_x" <a@b.c.invalid> - 2011-07-15 11:57 +0200
Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-15 04:36 -0700
Re: Arithmetic overflow checking Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-08-13 21:54 +0300
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-13 00:52 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-13 07:45 -0700
Re: Arithmetic overflow checking Wolfgang Draxinger <wdraxinger@darkstargames.de> - 2011-09-08 21:02 +0200
Re: Arithmetic overflow checking Wolfgang Draxinger <wdraxinger@darkstargames.de> - 2011-09-08 21:12 +0200
Re: Arithmetic overflow checking Willem <willem@toad.stack.nl> - 2011-09-08 19:15 +0000
Re: Arithmetic overflow checking Wolfgang Draxinger <wdraxinger@darkstargames.de> - 2011-09-08 22:24 +0200
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-08 00:30 -0400
Re: Arithmetic overflow checking Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-08 01:29 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-08 07:38 -0700
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-08 20:40 -0400
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-08 18:17 -0700
Re: Arithmetic overflow checking Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-08 19:49 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-08 22:26 -0700
Re: Arithmetic overflow checking Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-08 17:42 -0700
Re: Arithmetic overflow checking Tom Anderson <twic@urchin.earth.li> - 2011-07-09 10:21 +0100
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-10 10:53 -0400
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-10 18:07 +0000
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-10 11:29 -0700
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-10 19:22 +0000
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:40 -0400
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-21 23:06 +0000
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 19:38 -0400
Re: Arithmetic overflow checking Henderson <h1@g1.f1> - 2011-07-22 00:27 -0400
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-22 13:00 +0000
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-10 17:17 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-08 10:23 -0700
Re: Arithmetic overflow checking "John B. Matthews" <nospam@nospam.invalid> - 2011-07-08 19:30 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 08:04 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:43 -0400
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-15 00:28 -0500
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-18 23:09 -0400
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-15 00:14 -0500
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-15 07:00 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-15 08:09 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-20 22:07 -0400
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-15 23:29 -0500
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-15 22:26 -0700
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-16 00:32 -0500
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-16 11:00 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-16 11:15 -0700
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-16 15:41 -0500
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-16 23:18 +0000
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-17 00:30 -0500
Re: Arithmetic overflow checking "John B. Matthews" <nospam@nospam.invalid> - 2011-07-16 08:39 -0400
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-16 10:33 -0700
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-16 15:51 -0500
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-17 08:46 -0700
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-18 07:03 -0500
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-18 06:21 -0700
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-16 15:43 -0500
Re: Arithmetic overflow checking "John B. Matthews" <nospam@nospam.invalid> - 2011-07-17 09:50 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-17 08:15 -0700
Re: Arithmetic overflow checking "John B. Matthews" <nospam@nospam.invalid> - 2011-07-18 01:12 -0400
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:50 -0400
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-18 06:56 -0500
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-18 19:26 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-18 15:03 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-20 22:16 -0400
Re: Arithmetic overflow checking Henderson <h1@g1.f1> - 2011-07-20 22:25 -0400
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-21 08:50 -0400
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-21 07:37 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:52 -0400
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-21 12:19 +0000
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:54 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-21 14:46 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 18:10 -0400
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-21 23:22 +0000
Re: Arithmetic overflow checking "John B. Matthews" <nospam@nospam.invalid> - 2011-07-21 21:47 -0400
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-23 10:15 -0400
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-16 10:46 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-16 11:13 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-20 22:09 -0400
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-20 21:01 -0700
Re: Arithmetic overflow checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-21 07:05 -0300
Re: Arithmetic overflow checking supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-21 06:28 -0400
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-21 12:32 +0000
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:58 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-21 15:58 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 19:14 -0400
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-22 13:07 +0000
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-22 17:33 +0000
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-22 13:36 -0700
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-22 23:16 +0000
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-22 16:50 -0700
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-23 20:09 +0000
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-24 08:56 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-23 09:37 -0700
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-23 11:23 -0400
Re: Arithmetic overflow checking supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-23 12:04 -0400
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-23 14:45 -0400
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-23 11:51 -0700
Re: Arithmetic overflow checking supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-23 22:39 -0400
Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-25 10:20 -0700
Re: Arithmetic overflow checking supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-25 13:29 -0400
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-25 13:35 -0400
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-23 09:39 -0700
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-23 21:09 +0000
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-23 21:24 +0000
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:57 -0400
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-20 22:12 -0400
Re: Arithmetic overflow checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-21 06:41 -0300
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:38 -0400
Re: Arithmetic overflow checking Wanja Gayk <brixomatic@yahoo.com> - 2011-07-06 22:28 +0200
Re: Arithmetic overflow checking Wanja Gayk <brixomatic@yahoo.com> - 2011-07-06 22:30 +0200
Re: Arithmetic overflow checking Tom Anderson <twic@urchin.earth.li> - 2011-07-06 22:32 +0100
Re: Arithmetic overflow checking rop rop <rop049@gmail.com> - 2011-07-07 00:30 -0700
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-07 07:54 -0400
Re: Arithmetic overflow checking rop rop <rop049@gmail.com> - 2011-07-07 05:36 -0700
Re: Arithmetic overflow checking Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-07-07 19:11 +0200
Re: Arithmetic overflow checking Tom Anderson <twic@urchin.earth.li> - 2011-07-07 14:21 +0100
Re: Arithmetic overflow checking Stanimir Stamenkov <s7an10@netscape.net> - 2011-07-09 16:34 +0300
Re: Arithmetic overflow checking Roedy Green <see_website@mindprod.com.invalid> - 2011-07-06 22:41 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-07 14:34 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-07 14:53 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-07 17:12 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-07 17:29 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-08 10:27 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-08 13:15 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-19 20:54 -0400
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-19 18:07 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-19 21:31 -0400
Re: Arithmetic overflow checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-20 07:36 -0300
Re: Arithmetic overflow checking RedGrittyBrick <RedGrittyBrick@spamweary.invalid> - 2011-07-20 11:58 +0100
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-20 09:51 -0700
Re: Arithmetic overflow checking RedGrittyBrick <RedGrittyBrick@spamweary.invalid> - 2011-07-21 12:11 +0100
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-21 12:43 +0000
Re: Arithmetic overflow checking Tom McGlynn <taqmcglynn@googlemail.com> - 2011-07-21 07:15 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-21 07:35 -0700
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-21 15:38 +0000
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-21 09:03 -0700
Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-21 12:00 -0700
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-22 17:16 +0000
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-23 11:28 -0400
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-23 21:03 +0000
Re: Arithmetic overflow checking Henderson <h1@g1.f1> - 2011-07-23 22:55 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-24 09:16 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-24 10:40 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-24 10:54 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-24 11:09 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-24 12:53 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-24 15:15 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-24 15:41 -0700
Re: Arithmetic overflow checking Henderson <h1@g1.f1> - 2011-07-25 03:21 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-25 00:56 -0700
Re: Arithmetic overflow checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-25 07:03 -0300
Re: Arithmetic overflow checking Thomas Richter <thor@math.tu-berlin.de> - 2011-07-26 09:43 +0200
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-25 11:06 +0000
Re: Arithmetic overflow checking Henderson <h1@g1.f1> - 2011-07-25 11:12 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-25 09:09 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-25 09:30 -0700
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-25 13:33 -0400
Re: Arithmetic overflow checking "John B. Matthews" <nospam@nospam.invalid> - 2011-07-26 03:04 -0400
Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-26 03:28 -0400
Re: Arithmetic overflow checking Henderson <h1@g1.f1> - 2011-07-26 04:53 -0400
Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-26 11:35 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-26 10:48 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:00 -0400
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-20 19:50 -0400
Re: Arithmetic overflow checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-20 23:21 -0300
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-21 12:52 +0000
Re: Arithmetic overflow checking Henderson <h1@g1.f1> - 2011-07-21 15:58 -0400
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:06 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-20 14:35 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-20 18:22 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-21 14:54 -0700
Re: Arithmetic overflow checking rop rop <rop049@gmail.com> - 2011-07-08 15:34 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 08:09 -0700
Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-11 10:30 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 14:43 -0700
Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-11 14:49 -0700
Re: Arithmetic overflow checking Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-07-17 17:14 +0200
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-18 19:28 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-18 16:36 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-19 21:33 -0400
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-19 20:56 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-20 14:36 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-20 18:24 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-21 14:55 -0700
Re: Arithmetic overflow checking Roedy Green <see_website@mindprod.com.invalid> - 2011-07-06 22:43 -0700
Re: Arithmetic overflow checking Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2011-07-07 14:56 +0300
Re: Arithmetic overflow checking "Nasser M. Abbasi" <nma@12000.org> - 2011-07-08 21:27 -0700
Re: Arithmetic overflow checking "Nasser M. Abbasi" <nma@12000.org> - 2011-07-08 21:57 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-09 12:16 -0700
Page 12 of 14 — ← Prev page 1 … 10 11 [12] 13 14 Next page →
| From | Tom McGlynn <taqmcglynn@googlemail.com> |
|---|---|
| Date | 2011-07-21 07:15 -0700 |
| Message-ID | <208c3e0b-4e3e-4180-97ae-53db9b8ec2e9@15g2000vbw.googlegroups.com> |
| In reply to | #6337 |
On Jul 21, 8:43 am, Martin Gregorie <mar...@address-in-sig.invalid>
wrote:
...
> Agreed, but there's another way to handle this in Java that would
> probably cater for most overflow and out of range requirements without
> affecting existing programs or the language at all:
>
> Just add range checking constructors to Integer and friends, e.g:
>
> Integer boundedValue = new Integer(0,1,10);
>
> to declare an Integer, initialised to zero and with the range 1:10. The
> overheads would be minimal if the checks were only enabled if limits were
> added. It could either throw an unchecked exception or provide a range
> checking method:
>
How would this help given that Integers can't change anyway? It can
only check that the initialization value is in range. You'd have to
somehow make these Integers 'sticky' in some way so that any
expression using one of them is also subject to bounds checking.
E.g.,
Integer firstValue = new Integer(Integer.MAX_VALUE, 0,
Integer.MAX_VALUE);
Integer nextValue = new Integer(firstValue+Integer.MAX_VALUE+3,
0, 10);
clearly overflows, but it would work fine unless something significant
were added to the language.
Regards,
Tom McGlynn
[toc] | [prev] | [next] | [standalone]
| From | lewbloch <lewbloch@gmail.com> |
|---|---|
| Date | 2011-07-21 07:35 -0700 |
| Message-ID | <f9939820-502d-4973-b008-0b62536ab967@m3g2000pre.googlegroups.com> |
| In reply to | #6333 |
RedGrittyBrick wrote: > lewbloch wrote: >> RedGrittyBrick wrote: >>> Arved Sandstrom wrote: >>>> Holding back from certain language changes just so someone can >>>> compile a codebase written against Java 5 on a Java 9 compiler, and have >>>> it work, is holding back the entire language. > >>> Why is this a problem? > >>> Firstly, you can use `javac -source 1.3` to compile old code, can't you? > >> No. Not if you want some of the new features. [...] > >> You also have to make sure that all your third-party libraries for >> that build conform to the older spec. > >> Targeting an old version is an all-or-nothing proposition. > > All good points but I feel your "No." is more like a "Yes, but". > It's a fair cop. > If everyone at Oracle went mad and Java 1.9 changed the language spec so > that integer arithmetic could throw an IntegerOverflowException, > presumably they could arrange things in the compiler (and JVM) so that > the `-source 1.5` option would compile the code such that integer > operations would never throw an IntegerOverflowException thus satisfying > Arved's objection - couldn't they? > Sure. I present the obstacles not as stoppers but as things for which the designer(s) of such a change must be responsible. >>> Secondly, a future version of Java could introduce some mechanism such >>> as in-line compiler directives that turn new >>> compiler-behaviours/language-features on for specified classes or for >>> specified sections of code (I'm thinking of Perl's `use feature` pragma >>> but I'm sure this sort of idea exists in other languages). > Yes, and they would have to. The issue is with the statement that "Java should have feature /X/" without any concept of the challenges that must be addressed. If the challenges are too expensive to overcome, or lack sufficient widespread utility, or are too foreign to the ethos of the language, then it might be best to reject the feature even if there does exist a good use case for it somewhere. Patricia and Arved, among others, have made the point that focusing on changes to Java when there are suitable alternative languages (that even run on the JVM!) is not always optimal. Why change Java if Javascript or Ruby or Scala can do the job for you right now? And what about the suggestion to write a CheckedInteger type that does what you need? You can get what you need without waiting for some potential future revolution in Java, and without leaving the comforting security of your favorite language. >> It'll come down to someone's perception of how valuable that feature >> is against the cost. > > Sure (assuming you're talking about the cost of adding that feature to > javac and JVM etc), I'm speaking hypothetically. > > @IntegerOverflowExceptions(true) > int c = a + b; > @IntegerOverflowExceptions(false) > > It looks horrid to me, and presumably there's lots of issues to > overcome, better syntax to achieve the same ends, but essentially, if > Sunacle felt it worthwhile, something could be done to introduce new > behaviours whilst making them optional for existing code that those > behaviours would break? > > Whilst I personally (think I) have no need for arithmetic overflow > checking of this sort, I imagine some clever language designers could > provide for it in a way that didn't break existing crypto libraries that > rely on such overflows being ignored. > > Perhaps I'm wrong, but people seem to be saying "you just can't do this > because it would break existing code" - I haven't grasped why those > people are sure this is the case. > That's not my claim. My claim is that you just can't do this irresponsibly lest you break existing code. I also believe that others' suggestions in this thread can solve the problem immediately without requiring Draconian and slow-to-arrive changes in the language. > Despite the above, I'm in favour of keeping the language relatively simple. > That's especially valid given that the language supports the desired functionality as long as you're willing to be a programmer and write the necessary code. I especially endorse Arved's comment: > Why are you wanting to rely on overflow detection to > save your program when 99 percent of the possible legal values for your > chosen data type are also wrong for the design problem, and you're > obviously not concerned about that at all? Why don't you write a proper > class for your data type? -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> |
|---|---|
| Date | 2011-07-21 15:38 +0000 |
| Message-ID | <slrnj2ghv0.6gl.avl@gamma.logic.tuwien.ac.at> |
| In reply to | #6342 |
lewbloch <lewbloch@gmail.com> wrote: > And what about the suggestion to write a CheckedInteger type that does > what you need? That has been answered already, but you may have missed it, or maybe blocked the one who answered this seriously and (imho) agreeably. Due to Java's lack of operator overloading, doing Math with non-primitive types is just painful. PS: my approach would be a new keyword like strictfp (which may modify floating point semantics compared to not-applying it), just one for modifying integral semantics: arithmetic overflow checks and runtime checks on cast to narrower types. Just like use of "strictfp" can be expected to slow down programs, the same would be acceptable for an integral pendant.
[toc] | [prev] | [next] | [standalone]
| From | lewbloch <lewbloch@gmail.com> |
|---|---|
| Date | 2011-07-21 09:03 -0700 |
| Message-ID | <7a23c9d2-508f-4dbd-af91-8cdf2a9764e1@p29g2000pre.googlegroups.com> |
| In reply to | #6344 |
On Jul 21, 8:38 am, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote: > lewbloch <lewbl...@gmail.com> wrote: > > And what about the suggestion to write a CheckedInteger type that does > > what you need? > > That has been answered already, but you may have missed it, or maybe > blocked the one who answered this seriously and (imho) agreeably. > > Due to Java's lack of operator overloading, doing Math with > non-primitive types is just painful. > I saw that suggestion, but painful != impossible. And how freaking "painful" is it to read method calls anyway? "Painful" is digging ditches, tarring roofs, smelting steel, even working the floor at your neighborhood mall anchor store. All a programmer has to do is read method calls and do some typing. People need to get over themselves. So for those who "can't" do range checking because "method calls are too 'painful'" - Shut The Front Door, whiner! Jesus H. Tap-dancing Christ! Or get out of programming and get a real job. Do keep agitating for a better way. Just don't cavil that there's no way to do it now, because there is. Amazing. Yeesh. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Joshua Cranmer <Pidgeot18@verizon.invalid> |
|---|---|
| Date | 2011-07-21 12:00 -0700 |
| Message-ID | <j09t06$4bo$1@dont-email.me> |
| In reply to | #6345 |
On 7/21/2011 9:03 AM, lewbloch wrote: > On Jul 21, 8:38 am, Andreas Leitgeb<a...@gamma.logic.tuwien.ac.at> > wrote: >> lewbloch<lewbl...@gmail.com> wrote: >>> And what about the suggestion to write a CheckedInteger type that does >>> what you need? >> >> That has been answered already, but you may have missed it, or maybe >> blocked the one who answered this seriously and (imho) agreeably. >> >> Due to Java's lack of operator overloading, doing Math with >> non-primitive types is just painful. >> > > I saw that suggestion, but painful != impossible. And how freaking > "painful" is it to read method calls anyway? "Painful" is digging > ditches, tarring roofs, smelting steel, even working the floor at your > neighborhood mall anchor store. All a programmer has to do is read > method calls and do some typing. People need to get over themselves. No, painful is realizing that your attempts to make something work all fail because you need to put together two libraries that need different versions of the same library. Next step, writing a script to extract the necessary symbols from library v2 but not in v1, dump those out as assembly, and copy them over. I'd love to have the pain that comes with "I need to write out `+' as `plus'" right now. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
[toc] | [prev] | [next] | [standalone]
| From | Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> |
|---|---|
| Date | 2011-07-22 17:16 +0000 |
| Message-ID | <slrnj2jc3u.6gl.avl@gamma.logic.tuwien.ac.at> |
| In reply to | #6346 |
Joshua Cranmer <Pidgeot18@verizon.invalid> wrote: > On 7/21/2011 9:03 AM, lewbloch wrote: >> On Jul 21, 8:38 am, Andreas Leitgeb<a...@gamma.logic.tuwien.ac.at> >> wrote: >>> lewbloch<lewbl...@gmail.com> wrote: >>>> And what about the suggestion to write a CheckedInteger type that does >>>> what you need? >>> Due to Java's lack of operator overloading, doing Math with >>> non-primitive types is just painful. >> I saw that suggestion, but painful != impossible. And "not impossible" != "a satisfying alternative". > No, painful is realizing that your attempts to make something work all > fail because you need to put together two libraries that need different > versions of the same library. Next step, writing a script to extract the > necessary symbols from library v2 but not in v1, dump those out as > assembly, and copy them over. I'm not sure which relation to the current discussion you might have had in mind for posting your example, but having to resort to some wordy prefix-notation instead of infix-notation, may indeed just be comparable to fiddling with native machine code libraries compared to jar-files.
[toc] | [prev] | [next] | [standalone]
| From | David Lamb <dalamb@cs.queensu.ca> |
|---|---|
| Date | 2011-07-23 11:28 -0400 |
| Message-ID | <IMBWp.68441$5v5.52239@newsfe11.iad> |
| In reply to | #6404 |
On 22/07/2011 1:16 PM, Andreas Leitgeb wrote: > I'm not sure which relation to the current discussion you might have had > in mind for posting your example, but having to resort to some wordy > prefix-notation instead of infix-notation, may indeed just be comparable > to fiddling with native machine code libraries compared to jar-files. I have done all of those things, and for me, having to deal with method calls instead of infix (while annoying) is nowhere near as painful as the library comparison. Plus IMHO getting operator overloading *right* in a language isn't exactly trivial. It's not horrible, but not trivial either.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> |
|---|---|
| Date | 2011-07-23 21:03 +0000 |
| Message-ID | <slrnj2mdoi.6gl.avl@gamma.logic.tuwien.ac.at> |
| In reply to | #6452 |
David Lamb <dalamb@cs.queensu.ca> wrote: > On 22/07/2011 1:16 PM, Andreas Leitgeb wrote: >> I'm not sure which relation to the current discussion you might have had >> in mind for posting your example, but having to resort to some wordy >> prefix-notation instead of infix-notation, may indeed just be comparable >> to fiddling with native machine code libraries compared to jar-files. > I have done all of those things, and for me, having to deal with method > calls instead of infix (while annoying) is nowhere near as painful as > the library comparison. Comparing particular subjective painfulnesses doesn't contribute much to the discussion. It is my opinion, that operator overloading at least for a certain limited set of JSL classes (including BigDecimal and BigInteger as well as some new Complex class in addition to String's +), would be beneficial. Ditto for a new "strictint" keyword to enable detection and handling of integer overflows. There obviously won't be much agreement on how much effort these might be worth, and some may even claim that adding those would make Java worse. No consensus is likely to be reached here. And even if it were reached, chances would be neglectible that Java would grow a feature just because it reached consensus in c.l.j.p > Plus IMHO getting operator overloading *right* in a language isn't > exactly trivial. It's not horrible, but not trivial either. That's the kind of argument that made this posting worth answering. It becomes non-trivial when it comes to mixing types in expressions. There'd be some rules and maybe some "cannot"s but that wouldn't be a blocking point.
[toc] | [prev] | [next] | [standalone]
| From | Henderson <h1@g1.f1> |
|---|---|
| Date | 2011-07-23 22:55 -0400 |
| Message-ID | <j0g1i4$nus$1@speranza.aioe.org> |
| In reply to | #6480 |
On 23/07/2011 5:03 PM, Andreas Leitgeb wrote: > It is my opinion, that operator overloading at least for a certain > limited set of JSL classes (including BigDecimal and BigInteger as > well as some new Complex class in addition to String's +), would > be beneficial. Ditto for a new "strictint" keyword to enable > detection and handling of integer overflows. An obvious suggestion would be to allow it on all java.lang.Number subclasses, but a + b among these is only defined if a is a Number class that has an overload of .plus(x) that is applicable to an argument of a supertype of b, and the most specific such is chosen; and if a is a primitive, is treated as b + a; a * b analogously; a - b with a primitive uses (b - a).negate() and expects the return type of minus to support negate(); and for division we likewise need .reciprocal(). We could go further and rewrite Number.java so that it is Number<T extends Number<T>> and defines: public T plus (? super T) public T plus (int) public T plus (long) public T plus (float) public T plus (double) public T minus (? super T) public T minus (int) ... public T times (? super T) ... public T dividedBy (? super T) ... public T negate () public T reciprocal () or something of the sort. I think short overloads can be left out as they can just auto-promote to int and use the int version and the int version won't be less efficient, unlike (on 32 bit hardware) the long version. The operator expressions then become shorthands for the method calls above, and generate compile time type errors if one is needed and missing, e.g. MyBigInteger.plus(BigInteger) is not defined but MyBigInteger.plus(MyBigInteger) is and one mixes the two types in a + expression. (Integer etc. needn't be explicitly supported as autounboxing can be used to call the primitive plus (int) or whatever if necessary.)
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2011-07-24 09:16 -0700 |
| Message-ID | <ueidnUcxuMPT2LHTnZ2dnUVZ_uKdnZ2d@earthlink.com> |
| In reply to | #6495 |
On 7/23/2011 7:55 PM, Henderson wrote: > On 23/07/2011 5:03 PM, Andreas Leitgeb wrote: >> It is my opinion, that operator overloading at least for a certain >> limited set of JSL classes (including BigDecimal and BigInteger as >> well as some new Complex class in addition to String's +), would >> be beneficial. Ditto for a new "strictint" keyword to enable >> detection and handling of integer overflows. > > An obvious suggestion would be to allow it on all java.lang.Number > subclasses, but a + b among these is only defined if a is a Number class > that has an overload of .plus(x) that is applicable to an argument of a > supertype of b, and the most specific such is chosen; and if a is a > primitive, is treated as b + a; a * b analogously; a - b with a > primitive uses (b - a).negate() and expects the return type of minus to > support negate(); and for division we likewise need .reciprocal(). > > We could go further and rewrite Number.java so that it is Number<T > extends Number<T>> and defines: I don't think it would be wise to tie operator overloading to Number. Number defines a series of conversions that make some sense for those types that represent subsets of the real line. You cannot return "the value of the specified number as a double" if the specified number is complex. I would prefer the complex type to have separate, meaningfully named, methods returning as double each of the real part, the complex part, the absolute value, and the phase. I think it might be better to create a marker interface java.math.Arithmetic. I do like the idea of a fixed mapping from operators to method names that are normal identifiers. I don't think all arithmetic types should be required to support all operations. For example, consider negate and an unsigned type, or reciprocal and an integer type. Patricia
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2011-07-24 10:40 -0700 |
| Message-ID | <j0hle9$7da$1@dont-email.me> |
| In reply to | #6508 |
On 7/24/2011 9:16 AM, Patricia Shanahan wrote:
> I think it might be better to create a marker interface
> java.math.Arithmetic. I do like the idea of a fixed mapping from
> operators to method names that are normal identifiers.
I'd be concerned that a marker interface could be abused.
public abstract class BaseNumber extends Number {
public abstract BaseNumber add( Number n );
public abstract BaseNumber subtract( Number n );
public abstract BaseNumber mul( Number n );
public abstract BaseNumber[] div( Number n );
public abstract BaseNumber modulo( Number n );
}
Then restrict operator overloading to a class like BaseNumber and its
subclasses. Some classes in the existing Java API like BigDecimal may
need to also extend BaseNumber.
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2011-07-24 10:54 -0700 |
| Message-ID | <up6dnQu11_30wbHTnZ2dnUVZ_h2dnZ2d@earthlink.com> |
| In reply to | #6512 |
On 7/24/2011 10:40 AM, markspace wrote:
> On 7/24/2011 9:16 AM, Patricia Shanahan wrote:
>> I think it might be better to create a marker interface
>> java.math.Arithmetic. I do like the idea of a fixed mapping from
>> operators to method names that are normal identifiers.
>
>
> I'd be concerned that a marker interface could be abused.
>
> public abstract class BaseNumber extends Number {
> public abstract BaseNumber add( Number n );
> public abstract BaseNumber subtract( Number n );
> public abstract BaseNumber mul( Number n );
> public abstract BaseNumber[] div( Number n );
> public abstract BaseNumber modulo( Number n );
> }
>
> Then restrict operator overloading to a class like BaseNumber and its
> subclasses. Some classes in the existing Java API like BigDecimal may
> need to also extend BaseNumber.
Whatever is done can, and will, be abused. People will just make their
non-arithmetic classes for which they want "+" extend BaseNumber, and
meanwhile complex would be forced to provide a meaningless conversion to
byte.
Patricia
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2011-07-24 11:09 -0700 |
| Message-ID | <j0hn52$i44$1@dont-email.me> |
| In reply to | #6513 |
On 7/24/2011 10:54 AM, Patricia Shanahan wrote: > meanwhile complex would be forced to provide a meaningless conversion to > byte. It could just throw an error. Collections uses this technique to make unmodifiable Collection's. An unmodifiable List for example throws UnsupportedOperation if add() is invoked. 'Taint the prettiest but it works.
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2011-07-24 12:53 -0700 |
| Message-ID | <Y6ydnUjy3vy05bHTnZ2dnUVZ_rednZ2d@earthlink.com> |
| In reply to | #6514 |
On 7/24/2011 11:09 AM, markspace wrote: > On 7/24/2011 10:54 AM, Patricia Shanahan wrote: >> meanwhile complex would be forced to provide a meaningless conversion to >> byte. > > > It could just throw an error. Collections uses this technique to make > unmodifiable Collection's. An unmodifiable List for example throws > UnsupportedOperation if add() is invoked. 'Taint the prettiest but it > works. > > As well as not being particularly pretty, it changes what could be a compile time error to an exception during execution. Note that misuses of arithmetic operator overloading can use exactly the same technique - extend Number and throw exceptions for the Number methods. I still don't see the advantage over a marker interface. Patricia
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2011-07-24 15:15 -0700 |
| Message-ID | <j0i5if$fu2$1@dont-email.me> |
| In reply to | #6517 |
On 7/24/2011 12:53 PM, Patricia Shanahan wrote: > I still don't see the advantage over a marker interface. The advantage of a class instead of an interface is that extends is required. Since Java doesn't support multiple inheritance, opportunities for abuse are reduced. I also think there is a mental barrier to is-a abstract class versus just a marker interface. The former has design implications that many would not wish to break just to get a little operator overloading.
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2011-07-24 15:41 -0700 |
| Message-ID | <HoadnSELmJgDArHTnZ2dnUVZ_rudnZ2d@earthlink.com> |
| In reply to | #6518 |
On 7/24/2011 3:15 PM, markspace wrote: > On 7/24/2011 12:53 PM, Patricia Shanahan wrote: >> I still don't see the advantage over a marker interface. > > > The advantage of a class instead of an interface is that extends is > required. Since Java doesn't support multiple inheritance, opportunities > for abuse are reduced. I also think there is a mental barrier to is-a > abstract class versus just a marker interface. The former has design > implications that many would not wish to break just to get a little > operator overloading. > > > I don't see how forcing is-a Number distinguishes between arithmetic types and non-arithmetic types. The main feature of Number is a set of methods that presume natural mapping from each Number subclass into the real line. If people are expected to live with that for arithmetic types that are not subsets of the reals, why do you believe they will be reluctant to live with it for non-arithmetic types, some of which do have a natural mapping into the reals? Patricia
[toc] | [prev] | [next] | [standalone]
| From | Henderson <h1@g1.f1> |
|---|---|
| Date | 2011-07-25 03:21 -0400 |
| Message-ID | <j0j5ie$v55$1@speranza.aioe.org> |
| In reply to | #6508 |
On 24/07/2011 12:16 PM, Patricia Shanahan wrote:
> On 7/23/2011 7:55 PM, Henderson wrote:
>> We could go further and rewrite Number.java so that it is Number<T
>> extends Number<T>> and defines:
>
> I don't think it would be wise to tie operator overloading to Number.
> Number defines a series of conversions that make some sense for those
> types that represent subsets of the real line.
I wasn't thinking beyond the real line to the more abstract stuff
mathematicians futz around with and consider to have addition and
multiplication.
But short of giving general operator overloading to the masses (which
the gurus in charge of Java clearly do not want to do), there *is* a
way: introduce an abstract superclass, say, AbstractNumber or
ArithmeticComposable or something for "things that aren't necessarily
normal numbers, but have the basic arithmetic operations".
> I think it might be better to create a marker interface
> java.math.Arithmetic.
That sneaks in arbitrary operator overloading through the back door, as
people slap "implements java.math.Arithmetic" on
"JFoobarSQLQueryEnumerator" and implement ".plus" for it. ;)
Even as things go, I'd like there to be some compiler magic making the
ArithmeticComposables (or whatever) have automatically final fields,
anything with that as an ancestor, as well. It should be that a += b
changes what math object the reference a points to, but doesn't change a
for anybody else, so all the arithmetic operations should return new
objects (as currently seems to be the case for BigInteger and
BigDecimal), not mutate the original.
> I do like the idea of a fixed mapping from
> operators to method names that are normal identifiers.
It's also the only way to do it without adding new keywords and syntax
in a probably source-compatibility-breaking way. And do we really want
C++'s "operator+" notation?
> I don't think
> all arithmetic types should be required to support all operations. For
> example, consider negate and an unsigned type, or reciprocal and an
> integer type.
There's two approaches to dealing with that.
1. AbstractNumber implements everything, but they all throw
UnsupportedOperationException. You override what you can support.
2. AbstractNumber doesn't even specify some of these, but +, -, etc.
may expand into them anyway, and the compiler will then complain
if the corresponding named method is not found.
One problem with this, though, is that implementing a - b when a is
primitive and b isn't, and likewise a / b, seems to require having
negate and reciprocal, respectively, supported by whatever the return
type of b - a and b / a would be.
There's also a possible precision problem with a/b being computed as
1/(b/a) in these cases.
As an alternative, perhaps boxing transformations can be expected
instead: valueOf(int), etc. methods will be used so if b is of an
ArithmeticComposable type Foo with a valueOf(int) method and a is an
int, or can be widened to int (short, byte), then a + b becomes
Foo.valueOf(a).plus(b).
Of course, valueOf may need to cope with values out of range. What if
Foo is your hypothetical unsigned type and a is -42? RuntimeExceptions
seem indicated in these cases. We already have an ArithmeticException
class, currently used for BigInteger/BigDecimal ops that result in
division by zero or non-representable values (in the case of a BD with
unlimited precision -- another spot where we could sorely use a Rational
class). I'd suggest including an ArithmeticRangeException subclass of
that for use in such valueOf methods.
And once boxing conversions are being included, why not go ahead and
allow any ArithmeticComposable with intValue or similarly-named methods
be autounboxed when used in contexts that expect a primitive? (Though a
+ b and other arithmetic situations will never unbox b instead of boxing
a, presuming that the specialized type of b is desired. Manual unboxing
can be done if the opposite is desired, e.g. a + b.intValue().)
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2011-07-25 00:56 -0700 |
| Message-ID | <6bmdnfQwfsYovLDTnZ2dnUVZ_qydnZ2d@earthlink.com> |
| In reply to | #6524 |
On 7/25/2011 12:21 AM, Henderson wrote: > On 24/07/2011 12:16 PM, Patricia Shanahan wrote: >> On 7/23/2011 7:55 PM, Henderson wrote: >>> We could go further and rewrite Number.java so that it is Number<T >>> extends Number<T>> and defines: >> >> I don't think it would be wise to tie operator overloading to Number. >> Number defines a series of conversions that make some sense for those >> types that represent subsets of the real line. > > I wasn't thinking beyond the real line to the more abstract stuff > mathematicians futz around with and consider to have addition and > multiplication. Historically, complex numbers were indeed invented by and for mathematicians for the abstract satisfaction of having solutions for all quadratic equations. However, as happens surprisingly often when mathematicians think they have invented something abstract for their own amusement, scientists and engineers turned them into useful tools for practical uses. For example, a complex number can represent both magnitude and phase of an alternating current. That simplifies some electrical engineering calculations. I've seen far too many uses of complex numbers in scientific and engineering programs to be really comfortable with the fact that Java lacks a practical way to express anything other than the simplest complex number expressions. Patricia
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Date | 2011-07-25 07:03 -0300 |
| Message-ID | <acbXp.39645$7K4.37524@newsfe14.iad> |
| In reply to | #6527 |
On 11-07-25 04:56 AM, Patricia Shanahan wrote: > On 7/25/2011 12:21 AM, Henderson wrote: >> On 24/07/2011 12:16 PM, Patricia Shanahan wrote: >>> On 7/23/2011 7:55 PM, Henderson wrote: >>>> We could go further and rewrite Number.java so that it is Number<T >>>> extends Number<T>> and defines: >>> >>> I don't think it would be wise to tie operator overloading to Number. >>> Number defines a series of conversions that make some sense for those >>> types that represent subsets of the real line. >> >> I wasn't thinking beyond the real line to the more abstract stuff >> mathematicians futz around with and consider to have addition and >> multiplication. > > Historically, complex numbers were indeed invented by and for > mathematicians for the abstract satisfaction of having solutions for all > quadratic equations. However, as happens surprisingly often when > mathematicians think they have invented something abstract for their own > amusement, scientists and engineers turned them into useful tools for > practical uses. > > For example, a complex number can represent both magnitude and phase of > an alternating current. That simplifies some electrical engineering > calculations. > > I've seen far too many uses of complex numbers in scientific and > engineering programs to be really comfortable with the fact that Java > lacks a practical way to express anything other than the simplest > complex number expressions. > > Patricia I agree. Unless it were a trivial and very limited use of complex numbers I'd likely skip Java as a candidate for doing that work. But if the application had a moderate need for complex numbers, but also a compelling argument for using Java for most of the logic, I would consider Scala for the complex numbers bit. Or Jython for that matter. But for an application that was all about science and engineering computations my first few choices of programming languages would not include Java anyway. Nor C#, even though that has much better support for complex. Just as when I was doing primarily scientific programming (12 or more years ago) I believe that faced with the same questions today I'd still look first at what language has got the best built-ins and libraries for the specific job, including not just data manipulation but also data visualization. Another interesting consideration is languages that have type systems that support the notion of dimension. I've played a bit with that in F# and Fortress, and I believe that language support for units of measure is also very important in ensuring program correctness. AHS
[toc] | [prev] | [next] | [standalone]
| From | Thomas Richter <thor@math.tu-berlin.de> |
|---|---|
| Date | 2011-07-26 09:43 +0200 |
| Message-ID | <j0lr6i$p6$1@news.belwue.de> |
| In reply to | #6527 |
Am 25.07.2011 09:56, schrieb Patricia Shanahan: > On 7/25/2011 12:21 AM, Henderson wrote: >> On 24/07/2011 12:16 PM, Patricia Shanahan wrote: >>> On 7/23/2011 7:55 PM, Henderson wrote: >>>> We could go further and rewrite Number.java so that it is Number<T >>>> extends Number<T>> and defines: >>> >>> I don't think it would be wise to tie operator overloading to Number. >>> Number defines a series of conversions that make some sense for those >>> types that represent subsets of the real line. >> >> I wasn't thinking beyond the real line to the more abstract stuff >> mathematicians futz around with and consider to have addition and >> multiplication. > > Historically, complex numbers were indeed invented by and for > mathematicians for the abstract satisfaction of having solutions for all > quadratic equations. Not at all! There was simply no need to solve quadratic equations like x^2 + 4 = 0 simply because everyone knew, and it was obvious, that this equation *does not have* a solution. Complex numbers were invented as a tool to solve *cubic* equations. The tricky thing is that, if you want to solve a cubic equation, you *know* that it must either have one, two or three solutions, ever. However, in the three-solution case, a closed formula for computing the solutions was found, but this equation required you, somewhere in the middle, to handle with roots of negative numbers. All these strange negative roots then vanish again in the final solution using rules like sqrt(-1) * sqrt(-1) = -1, and then cancel out, so everything was "correct" in the end. All what happened then is that these rules for manipulating the strange temporary = "imaginary" numbers where written down, and *this* gave the complex numbers. Thus, complex numbers weren't an abstract invention by crazy mathematicians trying to solve what wasn't possible to solve, but rather as a toolkit to solve something very practical, namely to apply an algorithm for solving cubic(!) equations. This is very much a useful task, as it is to use complex numbers to describe AC currents. That java lacks operator overloading is a historic decision, probably taken on the basis that C++ started with this feature, and everyone considered it "so cool" that it was misused for all types of nonsense. Basically, I don't consider the choice of the C++ STL to use << and >> operators for input and output a sane one, and probably the java language designers had the same impression, so wanted to avoid it, but then overdid it by disallowing operator overloading in total. Nowadays, one can probably say that operator overloading *is* a useful tool, but as for all useful tools it is one that should be handled with care, and a tool that can cause quite some trouble in the hands of fools. Thus, what C++ overdid, and Java "under"-did. From today's perspective, I *would* prefer to have operator overloading in java, but apply it only where it makes sense and the semantics of operators is correct. That is, apply it to numeric types (numbers including complex numbers, matrices, vectors). Appyling it to I/O as does C++ is, IMHO, not a good idea. Greetings, Thomas
[toc] | [prev] | [next] | [standalone]
Page 12 of 14 — ← Prev page 1 … 10 11 [12] 13 14 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web