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 13 of 14 — ← Prev page 1 … 11 12 [13] 14 Next page →
| From | Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> |
|---|---|
| Date | 2011-07-25 11:06 +0000 |
| Message-ID | <slrnj2qjgv.6gl.avl@gamma.logic.tuwien.ac.at> |
| In reply to | #6524 |
Henderson <h1@g1.f1> wrote:
>> 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. ;)
It's quite likely that the reviewer who inevitably will shoot the
programmer for this, will have the jury's sympathy and not be
punished... ;)
A more fundamental problem with operator overloading for "Arithmetic"
types is, when Arithmetic types can or cannot be mixed for a particular
operation.
Simple example: what would be the sum of
BigInteger("123456789012345678901234567890123456789012") and some
Complex( 0.0 , Math.PI )? Ok, preferences likely go towards
Complex as the result for this particular example, but there must
be some formalism as to how this addition would be actually
calculated: either there would have to be an over*load* of
.plus(...) for each and every other type, or there must be some
bottleneck like "double" through which unknown Arithmetic-
implementations for the right operand are going to be queezed to
perform the actual calculation.
Such cross-type-behaviour can be deliberately defined for a fixed
handful of new types, but not generally among any two implementors
(or subclasses) of some interface (or baseclass). (I anticipate
that someone will now throw up .equals(), but that's of course
a much simpler matter ("just return false") with respect to
unrelated argument types.)
PS:
I have a faible for philosophical discussions of what new features
would or would not improve Java, and what dangers linger behind them.
I do not think, that any of this discussion or outcomes will have an
influence on what may or may not go into a new version of Java.
[toc] | [prev] | [next] | [standalone]
| From | Henderson <h1@g1.f1> |
|---|---|
| Date | 2011-07-25 11:12 -0400 |
| Message-ID | <j0k14r$7rr$1@speranza.aioe.org> |
| In reply to | #6530 |
On 25/07/2011 7:06 AM, Andreas Leitgeb wrote:
> Henderson<h1@g1.f1> wrote:
>>> 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. ;)
>
> It's quite likely that the reviewer who inevitably will shoot the
> programmer for this, will have the jury's sympathy and not be
> punished... ;)
>
> A more fundamental problem with operator overloading for "Arithmetic"
> types is, when Arithmetic types can or cannot be mixed for a particular
> operation.
>
> Simple example: what would be the sum of
> BigInteger("123456789012345678901234567890123456789012") and some
> Complex( 0.0 , Math.PI )?
Ideally, it would be a Complex with bignum components, preserving precision.
This seems to require Complex<BaseType> rather than just Complex.
Of course you also raise a valid point regarding overloading for
conversions. Probably you'd have to create a whole framework, with a
NVector<T> for "things with dimension > 1 over the real numbers" and
NVector<BigDecimal> of appropriate dimensionality as the conversion
intermediary (so as not to lose either precision or dimensions in going
to the intermediary) -- just BigDecimal when one-dimensional. Then
conversion to and from BigDecimal and NVector<BigDecimal> is all that is
required.
Until some enterprising mathematician thinks up something that can be
added and multiplied, but has no sensible correspondence to any subset
of any kind of vectors of real numbers ...
I think you can cram matrices in there, and complex numbers. Numbers mod
something, too -- though do you quietly truncate when converting to
these, or throw an exception? Of course, primitive int is already
actually an integers-mod-2^32 type so that may be considered already
settled.
A quick search of wikipedia for "numbers" and looking at terms in the
results that seem to describe funny kinds of numbers turns up "p-adic
numbers" and "hyperreal numbers" that I'm guessing would still run into
problems here. No operator overloading for those, then. :)
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2011-07-25 09:09 -0700 |
| Message-ID | <Nb2dnW_mPtWqCLDTnZ2dnUVZ_qudnZ2d@earthlink.com> |
| In reply to | #6536 |
On 7/25/2011 8:12 AM, Henderson wrote:
> On 25/07/2011 7:06 AM, Andreas Leitgeb wrote:
...
>> Simple example: what would be the sum of
>> BigInteger("123456789012345678901234567890123456789012") and some
>> Complex( 0.0 , Math.PI )?
>
> Ideally, it would be a Complex with bignum components, preserving
> precision.
Treat x+y as x.plus(y). Apply the usual compile and run time method
invocation rules. The type of the result of x+y is the return type of
x.plus(y). Report the usual errors.
That strategy would require some explicit conversions but is much
clearer than anything that attempts inference for user-defined
arithmetic types beyond the method invocation conversions.
It leaves the choice of the return type to the writers of the classes
and the code using them, where it should be for generality.
> Until some enterprising mathematician thinks up something that can be
> added and multiplied, but has no sensible correspondence to any
> subset of any kind of vectors of real numbers ...
How about the symmetries of a square? Or, for that matter, any arbitrary
group? If you have a group, you have addition.
At one level, every practical type is limited to values that can be
represented by finite bit strings, and those bit strings can all be
mapped to natural numbers.
The key question is how "sensible" is the correspondence. We already
have some awkwardness in making Double implement Comparable and extend
Number, because Double can have Not-a-Number values. Double has to
pretend NaNs are numbers in some Comparable and Number contexts, even
though their whole point is to represent the lack of a numerical result.
Patricia
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2011-07-25 09:30 -0700 |
| Message-ID | <78ednRjnJuyDB7DTnZ2dnUVZ_gadnZ2d@earthlink.com> |
| In reply to | #6537 |
On 7/25/2011 9:09 AM, Patricia Shanahan wrote:
...
> The key question is how "sensible" is the correspondence. We already
> have some awkwardness in making Double implement Comparable and extend
> Number, because Double can have Not-a-Number values. Double has to
> pretend NaNs are numbers in some Comparable and Number contexts, even
> though their whole point is to represent the lack of a numerical result.
...
Returning to the original topic of this thread, I think one of the worst
decisions in the early Java design was to treat NaN as zero on
conversion to an integer type.
Consider the following program:
public class DivisionExample {
public static void main(String[] args) {
System.out.println(0.0 / 0.0);
System.out.println((long) (0.0 / 0.0));
try {
System.out.println(0 / 0);
} catch (ArithmeticException e) {
System.out.println("Integer division: " + e.getMessage());
}
}
}
It prints:
NaN
0
Integer division: / by zero
If the undefined 0/0 division is done in an integer type it throws an
exception. If it is done in double and the double is output as a double,
it is a NaN. If the double is converted to integer, the already detected
NaN condition is silently turned into a zero.
Patricia
[toc] | [prev] | [next] | [standalone]
| From | David Lamb <dalamb@cs.queensu.ca> |
|---|---|
| Date | 2011-07-25 13:33 -0400 |
| Message-ID | <SNhXp.70431$5v5.35598@newsfe11.iad> |
| In reply to | #6536 |
On 25/07/2011 11:12 AM, Henderson wrote: > Until some enterprising mathematician thinks up something that can be > added and multiplied, but has no sensible correspondence to any subset > of any kind of vectors of real numbers ... They're called "Rings": http://en.wikipedia.org/wiki/Ring_%28mathematics%29
[toc] | [prev] | [next] | [standalone]
| From | "John B. Matthews" <nospam@nospam.invalid> |
|---|---|
| Date | 2011-07-26 03:04 -0400 |
| Message-ID | <nospam-4D1654.03043626072011@news.aioe.org> |
| In reply to | #6542 |
In article <SNhXp.70431$5v5.35598@newsfe11.iad>, David Lamb <dalamb@cs.queensu.ca> wrote: > On 25/07/2011 11:12 AM, Henderson wrote: > > Until some enterprising mathematician thinks up something that can > > be added and multiplied, but has no sensible correspondence to any > > subset of any kind of vectors of real numbers ... > > They're called "Rings": > http://en.wikipedia.org/wiki/Ring_%28mathematics%29 The interface org.jscience.mathematics.structure.Ring represents just such an algebraic structure: <http://jscience.org/api/org/jscience/mathematics/structure/Ring.html> Both Complex and Polynomial implement Ring<R>, and there's a an example using Polynomial<Complex> here: <http://sites.google.com/site/drjohnbmatthews/polyroots> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
[toc] | [prev] | [next] | [standalone]
| From | Joshua Cranmer <Pidgeot18@verizon.invalid> |
|---|---|
| Date | 2011-07-26 03:28 -0400 |
| Message-ID | <j0lqb6$lh$1@dont-email.me> |
| In reply to | #6536 |
On 7/25/2011 11:12 AM, Henderson wrote:
> Until some enterprising mathematician thinks up something that can be
> added and multiplied, but has no sensible correspondence to any subset
> of any kind of vectors of real numbers ...
You've never taken abstract algebra, have you? Polynomials are the most
common counterexample I can think of (although they are treatable as an
infinite vector space over any finite field). You can also generalize
functions over the real numbers as a ring, and I'd find it hard pressed
to come up with a scheme that can sensibly "correspond to any subset of
any kind of vectors of real numbers" that can handle things as wildly
varying as f(x) = 1, f(x) = sin x, f(x) = integral from 0 to x of
exp(-t^2) dt, f(x) = 1 if x is rational and 1/x if x is irrational, or
f(x) = sum from n = 0 to infinity of 1/2 ^n cos(9^n pi x) (the
Weierstrass function).
Of course, if you just want addition, I can pull any old group out of a
hat. Symmetries of an n-gon are a particular favorite example for
nonabelian groups, as are permutations of sets.
> I think you can cram matrices in there, and complex numbers. Numbers mod
> something, too -- though do you quietly truncate when converting to
> these, or throw an exception? Of course, primitive int is already
> actually an integers-mod-2^32 type so that may be considered already
> settled.
What do you mean by "truncate" in modular arithmetic? Mod 10, 1 and 11
are the same thing (the set of numbers {..., -9, 1, 11, ... }).
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
[toc] | [prev] | [next] | [standalone]
| From | Henderson <h1@g1.f1> |
|---|---|
| Date | 2011-07-26 04:53 -0400 |
| Message-ID | <j0lv9r$l57$1@speranza.aioe.org> |
| In reply to | #6567 |
On 26/07/2011 3:28 AM, Joshua Cranmer wrote:
> On 7/25/2011 11:12 AM, Henderson wrote:
>> Until some enterprising mathematician thinks up something that can be
>> added and multiplied, but has no sensible correspondence to any subset
>> of any kind of vectors of real numbers ...
[delete bestiary]
Yeesh. Anyone adding operator overloading to Java in a sane way has his
work cut out for him, it seems.
> What do you mean by "truncate" in modular arithmetic? Mod 10, 1 and 11
> are the same thing (the set of numbers {..., -9, 1, 11, ... }).
As in, if you have a mod10 type, and you assign 36 to it, do you just
silently accept that and store it internally as 6, or do you throw an
exception if the input isn't in the range 0 to 9?
[toc] | [prev] | [next] | [standalone]
| From | Joshua Cranmer <Pidgeot18@verizon.invalid> |
|---|---|
| Date | 2011-07-26 11:35 -0400 |
| Message-ID | <j0mmsn$b6e$1@dont-email.me> |
| In reply to | #6569 |
On 07/26/2011 04:53 AM, Henderson wrote:
> On 26/07/2011 3:28 AM, Joshua Cranmer wrote:
>> What do you mean by "truncate" in modular arithmetic? Mod 10, 1 and 11
>> are the same thing (the set of numbers {..., -9, 1, 11, ... }).
>
> As in, if you have a mod10 type, and you assign 36 to it, do you just
> silently accept that and store it internally as 6, or do you throw an
> exception if the input isn't in the range 0 to 9?
There is nothing inherently correct about the elements in mod 10
arithmetic having values 0 to 9, so 36 is as valid in mod 10 as 6 is.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2011-07-26 10:48 -0700 |
| Message-ID | <QdudnSIccYaWY7PTnZ2dnUVZ_smdnZ2d@earthlink.com> |
| In reply to | #6577 |
On 7/26/2011 8:35 AM, Joshua Cranmer wrote:
> On 07/26/2011 04:53 AM, Henderson wrote:
>> On 26/07/2011 3:28 AM, Joshua Cranmer wrote:
>>> What do you mean by "truncate" in modular arithmetic? Mod 10, 1 and 11
>>> are the same thing (the set of numbers {..., -9, 1, 11, ... }).
>>
>> As in, if you have a mod10 type, and you assign 36 to it, do you just
>> silently accept that and store it internally as 6, or do you throw an
>> exception if the input isn't in the range 0 to 9?
>
> There is nothing inherently correct about the elements in mod 10
> arithmetic having values 0 to 9, so 36 is as valid in mod 10 as 6 is.
>
I think there may be at least two different models of mod 10 arithmetic
in this discussion, but they should lead to the same answer for this issue.
The one I prefer is based on equivalence classes:
The integers are partitioned into 10 equivalence classes where two
integers n and m are in the same class if, and only if, n - m is an
integer multiple of 10.
Mod 10 arithmetic is a set of operations on those equivalence classes.
For example, if x and y are two of the classes, x + y is the class
containing the sum of an arbitrary element of x and an arbitrary element
of y. It is easy to show that you get the same class for the sum,
regardless of the choice of an element of x and an element of y.
In this model, there is an obvious conversion from integer to mod 10 -
pick the class containing the integer. 36 maps to {..., -4, 6, 16, ...}
in exactly the same way as 6 maps to the same class.
We cannot store an infinite set, so we need some label to represent each
of the equivalence classes. Each contains exactly one of the integers 0
through 9, and we often use that integer to name and represent the class.
The usual answer for the conversion of a mod 10 class to an integer is
to return the integer in 0 through 9 that is a member of the class.
The other view is that mod 10 arithmetic is a form of finite range
arithmetic on the integers 0 through 9. x + y is the integer sum of x
and y, reduced by subtraction of an integer multiple of 10 to a number
in the range 0 through 9.
In this model, 36 does not exist in mod 10. However, I still think there
is an obvious mapping. Suppose 36 arose as an intermediate result from
e.g. 4 * 9 in mod 10 arithmetic. The mod 10 result would be 6. I think
that gives a clear model for converting an integer to mod 10 - reduce it
to an integer in the range 0 through 9 by subtraction of an integer
multiple of 10.
Patricia
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2011-07-21 17:00 -0400 |
| Message-ID | <4e289382$0$309$14726298@news.sunsite.dk> |
| In reply to | #6344 |
On 7/21/2011 11:38 AM, Andreas Leitgeb wrote: > 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. Somehow I think that sounds very Java'ish. (and if someone are in doubt then that is good when the context is Java) Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2011-07-20 19:50 -0400 |
| Message-ID | <4e2769dc$0$314$14726298@news.sunsite.dk> |
| In reply to | #6302 |
On 7/20/2011 6:36 AM, Arved Sandstrom wrote: > On 11-07-19 10:31 PM, Arne Vajhøj wrote: >> On 7/19/2011 9:07 PM, markspace wrote: >>> On 7/19/2011 5:54 PM, Arne Vajhøj wrote: >>>>> On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net> wrote: >>>>>> Java is designed to behave that way. That does not mean that it >>>>>> is not wrong. >>> >>> > On 7/8/2011 4:15 PM, lewbloch wrote: >>>>> >>>>> It doesn't mean that it is wrong. >>>>> >>> >>>> Yes, but given that there are already two languages under discussion, >>>> then it seems rather obvious that his point is that Java should have >>>> been designed different 16 years ago not change overflow handling >>>> in Java 8. >>> >>> >>> I think the point being made is that it's behavior that could be >>> improved *now*. >>> >>> The prescience required to see 16 years into the future is darn hard. I >>> don't think anyone at all has that kind of skill or knowledge. It would >>> have been better however to acknowledge sometime in the past that Java >>> needed to be improved in some fundamental ways and then make those >>> changes. >>> >>> Generics should have been reifiable, primitives should be "first class >>> objects," integer math should be checked for overflow where the >>> programmer deems needed. These things have been lacking for some time, >>> and are still needed, imo. >> >> Today it is a must that changes must not break existing code. >> >> That still leaves some room for improvements. >> >> But it tend to become messy. >> >> Sometimes we just need to realize that a wrong decision was >> made, that we are stuck with it and that it should be done >> correctly in the next language. > Changes, even backwards-incompatible changes, to version X of a language > do not break existing code *unless* users of that existing code make a > conscious choice to operate that code in the new environment. I am not > convinced there is a strong need to do that. > > As an example, and I'm sure I'm not alone in this, I routinely maintain > applications in 2011 that are J2EE 1.4 or Java EE 5. No shortage of them > are J2EE 1.4. Some colleagues who maintain other big web apps I am > familiar with have to deal with Struts 1. The penetration of Java EE 6 > applications and Java EE 6 servers into the local big business and > government scene is paltry. > > In terms of the associated Java versions, it's true that many folks use > Java 5 or 6 (frequently 1.6 latest update) even if they are developing > for a J2EE 1.4 server, but in my experience there has rarely been a > compelling need for it. To put it another way, I have little time for > someone who argues that they just absolutely need a cool Java 6 language > feature but they can't be bothered to upgrade from J2EE 1.4. > > Looking at the Oracle support roadmaps for J2SE/Java SE, fact is that > J2SE 1.4, and Java 5/6, will have some form of adequate support for a > long time yet (http://www.oracle.com/technetwork/java/eol-135779.html). > If Java 8, for example, decided to make some backwards-incompatible > changes to the language, people with existing code bases would have > sufficient options with Java 7 or earlier to keep them happy for a long, > long time. I simply do not see the validity of an argument that says > that the existence of an incompatible Java 8 or 9 is going to affect any > of these people. As it is, I expect not to be primarily working with > Java EE 6 and JDK 7 until 2015 at the earliest...and that may be > optimistic for the Java EE side of things. It is true that migrating code to new EE and SE versions are usually a lot behind. But eventually the code get lifted. Typical because the vendors stop support for the platform. And changes that does not create runtime exceptions or compile time warnings, but silently changes the semantics are about as bad as they get. The fact that it may take many years before the problems are felt does not make the problem smaller. > As far as "next" languages go, we've already been getting them on the > JVM: Scala and Clojure for example. Or you just abandon the JVM > entirely. 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. Ironically, the > conservative users that we are pandering to with this approach wouldn't > be in any hurry to use the latest JDK anyway...if ever. Why not? Not wanting to spend 6 or 7 digit dollar amounts verifying that code still works as original intended does not imply that you may not want new features. It just put (harsh) restrictions on how the new features can be implemented. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Date | 2011-07-20 23:21 -0300 |
| Message-ID | <43MVp.69006$_I7.9664@newsfe08.iad> |
| In reply to | #6318 |
On 11-07-20 08:50 PM, Arne Vajhøj wrote: > On 7/20/2011 6:36 AM, Arved Sandstrom wrote: >> On 11-07-19 10:31 PM, Arne Vajhøj wrote: >>> On 7/19/2011 9:07 PM, markspace wrote: >>>> On 7/19/2011 5:54 PM, Arne Vajhøj wrote: >>>>>> On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net> wrote: >>>>>>> Java is designed to behave that way. That does not mean that it >>>>>>> is not wrong. >>>> >>>> > On 7/8/2011 4:15 PM, lewbloch wrote: >>>>>> >>>>>> It doesn't mean that it is wrong. >>>>>> >>>> >>>>> Yes, but given that there are already two languages under discussion, >>>>> then it seems rather obvious that his point is that Java should have >>>>> been designed different 16 years ago not change overflow handling >>>>> in Java 8. >>>> >>>> >>>> I think the point being made is that it's behavior that could be >>>> improved *now*. >>>> >>>> The prescience required to see 16 years into the future is darn hard. I >>>> don't think anyone at all has that kind of skill or knowledge. It would >>>> have been better however to acknowledge sometime in the past that Java >>>> needed to be improved in some fundamental ways and then make those >>>> changes. >>>> >>>> Generics should have been reifiable, primitives should be "first class >>>> objects," integer math should be checked for overflow where the >>>> programmer deems needed. These things have been lacking for some time, >>>> and are still needed, imo. >>> >>> Today it is a must that changes must not break existing code. >>> >>> That still leaves some room for improvements. >>> >>> But it tend to become messy. >>> >>> Sometimes we just need to realize that a wrong decision was >>> made, that we are stuck with it and that it should be done >>> correctly in the next language. > >> Changes, even backwards-incompatible changes, to version X of a language >> do not break existing code *unless* users of that existing code make a >> conscious choice to operate that code in the new environment. I am not >> convinced there is a strong need to do that. >> >> As an example, and I'm sure I'm not alone in this, I routinely maintain >> applications in 2011 that are J2EE 1.4 or Java EE 5. No shortage of them >> are J2EE 1.4. Some colleagues who maintain other big web apps I am >> familiar with have to deal with Struts 1. The penetration of Java EE 6 >> applications and Java EE 6 servers into the local big business and >> government scene is paltry. >> >> In terms of the associated Java versions, it's true that many folks use >> Java 5 or 6 (frequently 1.6 latest update) even if they are developing >> for a J2EE 1.4 server, but in my experience there has rarely been a >> compelling need for it. To put it another way, I have little time for >> someone who argues that they just absolutely need a cool Java 6 language >> feature but they can't be bothered to upgrade from J2EE 1.4. >> >> Looking at the Oracle support roadmaps for J2SE/Java SE, fact is that >> J2SE 1.4, and Java 5/6, will have some form of adequate support for a >> long time yet (http://www.oracle.com/technetwork/java/eol-135779.html). >> If Java 8, for example, decided to make some backwards-incompatible >> changes to the language, people with existing code bases would have >> sufficient options with Java 7 or earlier to keep them happy for a long, >> long time. I simply do not see the validity of an argument that says >> that the existence of an incompatible Java 8 or 9 is going to affect any >> of these people. As it is, I expect not to be primarily working with >> Java EE 6 and JDK 7 until 2015 at the earliest...and that may be >> optimistic for the Java EE side of things. > > It is true that migrating code to new EE and SE versions are usually > a lot behind. > > But eventually the code get lifted. > > Typical because the vendors stop support for the platform. > > And changes that does not create runtime exceptions or compile > time warnings, but silently changes the semantics are about as > bad as they get. > > The fact that it may take many years before the problems are felt does > not make the problem smaller. I should point out that I'm not talking about arithmetic overflow checking or any other specific feature here. I am quite unconcerned about arithmetic overflow checking in Java, because I see at least two better solutions than changing the language: either (1) using a different language, or (2) being aware of your quantities and actually putting some thought into your design to avoid overflow. These have been suggested already. I'm talking about backwards-incompatible changes in general. There's no need to worry about "silent changes to semantics", because by definition you cannot expect your old source to be compatible with this newest version. You're told that, and you're told why. You can figure out what you need to change if you intend to upgrade some codebase, compiler warnings or no compiler warnings. Talking about Java specifically, SE or EE, there is a great deal of advance warning. You're typically going to have close to a decade of warning that you need to make certain modifications, if a version at some point introduces backwards incompatibilities. This is more than enough time. Since changes that _are_ backwards incompatible will almost certainly be important changes that should have been introduced much earlier anyway, and everyone's code should use them, and it will help everyone's code, where's the downside in forcing people to do some necessary work? People certainly do take advantage of new APIs and language features that _are_ backwards compatible, and they need to put in a lot of work to do that, so how is it somehow a bad thing that they've got to do a bit of work to upgrade a codebase into a new backwards-incompatible version? Call me a bit unsympathetic perhaps. I deal almost every day with people who want to do bleeding edge SOA on J2EE 1.4 app servers, and they agonize about upgrades that are all over 5 years old themselves. So I see the problem more that the vendors are too frigging lenient with support. Mainly because it's a cash cow. >> As far as "next" languages go, we've already been getting them on the >> JVM: Scala and Clojure for example. Or you just abandon the JVM >> entirely. 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. Ironically, the >> conservative users that we are pandering to with this approach wouldn't >> be in any hurry to use the latest JDK anyway...if ever. > > Why not? Because I used the word "conservative". IOW, your typical GiantCorp or government department that wants new functionality all the time but could care less about the language features or new APIs. The ones that expect you to implement the latest and greatest ideas with 10-year-old J2EE APIs because getting them to upgrade to Java EE 5 in the year 2011 is a frightening proposition. If a company or government IT shop is willing to keep up with the latest Java SE/EE releases then they are not conservative. > Not wanting to spend 6 or 7 digit dollar amounts verifying that > code still works as original intended does not imply that you may > not want new features. What percentage of business types do you think care about new language features and new APIs? 10 percent? 5 percent? One percent? What they care about is can you develop their latest pet project for them. Since we devs usually can cobble something together, albeit with difficulty, even with ancient libraries and old language versions, that's how it goes in real life. Let me give you just one example; not so many months ago I had to go through a lengthy and arduous process with one client, involving much analysis and multiple meetings, offering assurances all the way up to Director of IT level, just to bump up an EclipseLink minor version. To the typical conservative client any upgrade of any library is a Big Deal. You certainly won't see them clamouring for the speedy adoption of a new JDK because it offers support for lambdas. As for code working as originally intended, show me the production application that is substantively defect-free and works as originally intended. About the worst that will happen with an upgrade is that the typical app will break in new ways. Sometimes these new breakages are beneficial even. I'm minded of when we moved a complex J2EE app from one old app server over to a newish one from another vendor. Suddenly dozens of new defects appeared. Turned out that all of them were real code defects and that the old app server simply sucked that bad. My feeling is that forced adoption of better VMs and better servers and better language features, backwards-incompatible or no, is generally a good thing - it exposes flaws in codebases. They didn't get _created_, they were already there. > It just put (harsh) restrictions on how the new features can > be implemented. > > Arne Yeah. The harshness resides in forcing people to rewrite some to make their code better. AHS
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2011-07-21 12:52 +0000 |
| Message-ID | <j097dv$7rj$3@localhost.localdomain> |
| In reply to | #6323 |
On Wed, 20 Jul 2011 23:21:53 -0300, Arved Sandstrom wrote: > Talking about Java specifically, SE or EE, there is a great deal of > advance warning. You're typically going to have close to a decade of > warning that you need to make certain modifications, if a version at > some point introduces backwards incompatibilities. This is more than > enough time. > Arguably, the delay in removing deprecated features (which amounts to the same thing) is a waste of time: Y2K showed us that, with absolutely nothing being done ahead of time in most shops, the result was the expensive last minute panic. In fact, you can make the opposite argument: delay too long and there will be nobody left who remembers which programs might be affected or even that there is a problem. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Henderson <h1@g1.f1> |
|---|---|
| Date | 2011-07-21 15:58 -0400 |
| Message-ID | <j0a0dk$4of$1@speranza.aioe.org> |
| In reply to | #6339 |
On 21/07/2011 8:52 AM, Martin Gregorie wrote: > Arguably, the delay in removing deprecated features (which amounts to the > same thing) is a waste of time: Y2K showed us that, with absolutely > nothing being done ahead of time in most shops, the result was the > expensive last minute panic. > > In fact, you can make the opposite argument: delay too long and there > will be nobody left who remembers which programs might be affected or > even that there is a problem. One problem with removing deprecated features, at least from Snoracle's standpoint, is that organizations will be even more reluctant to update Java if doing so might require extensive modifications to all their stuff's source code.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2011-07-21 17:06 -0400 |
| Message-ID | <4e2894c8$0$309$14726298@news.sunsite.dk> |
| In reply to | #6323 |
On 7/20/2011 10:21 PM, Arved Sandstrom wrote: > On 11-07-20 08:50 PM, Arne Vajhøj wrote: >> On 7/20/2011 6:36 AM, Arved Sandstrom wrote: >>> On 11-07-19 10:31 PM, Arne Vajhøj wrote: >>>> On 7/19/2011 9:07 PM, markspace wrote: >>>>> On 7/19/2011 5:54 PM, Arne Vajhøj wrote: >>>>>>> On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net> wrote: >>>>>>>> Java is designed to behave that way. That does not mean that it >>>>>>>> is not wrong. >>>>> >>>>> > On 7/8/2011 4:15 PM, lewbloch wrote: >>>>>>> >>>>>>> It doesn't mean that it is wrong. >>>>>>> >>>>> >>>>>> Yes, but given that there are already two languages under discussion, >>>>>> then it seems rather obvious that his point is that Java should have >>>>>> been designed different 16 years ago not change overflow handling >>>>>> in Java 8. >>>>> >>>>> >>>>> I think the point being made is that it's behavior that could be >>>>> improved *now*. >>>>> >>>>> The prescience required to see 16 years into the future is darn hard. I >>>>> don't think anyone at all has that kind of skill or knowledge. It would >>>>> have been better however to acknowledge sometime in the past that Java >>>>> needed to be improved in some fundamental ways and then make those >>>>> changes. >>>>> >>>>> Generics should have been reifiable, primitives should be "first class >>>>> objects," integer math should be checked for overflow where the >>>>> programmer deems needed. These things have been lacking for some time, >>>>> and are still needed, imo. >>>> >>>> Today it is a must that changes must not break existing code. >>>> >>>> That still leaves some room for improvements. >>>> >>>> But it tend to become messy. >>>> >>>> Sometimes we just need to realize that a wrong decision was >>>> made, that we are stuck with it and that it should be done >>>> correctly in the next language. >> >>> Changes, even backwards-incompatible changes, to version X of a language >>> do not break existing code *unless* users of that existing code make a >>> conscious choice to operate that code in the new environment. I am not >>> convinced there is a strong need to do that. >>> >>> As an example, and I'm sure I'm not alone in this, I routinely maintain >>> applications in 2011 that are J2EE 1.4 or Java EE 5. No shortage of them >>> are J2EE 1.4. Some colleagues who maintain other big web apps I am >>> familiar with have to deal with Struts 1. The penetration of Java EE 6 >>> applications and Java EE 6 servers into the local big business and >>> government scene is paltry. >>> >>> In terms of the associated Java versions, it's true that many folks use >>> Java 5 or 6 (frequently 1.6 latest update) even if they are developing >>> for a J2EE 1.4 server, but in my experience there has rarely been a >>> compelling need for it. To put it another way, I have little time for >>> someone who argues that they just absolutely need a cool Java 6 language >>> feature but they can't be bothered to upgrade from J2EE 1.4. >>> >>> Looking at the Oracle support roadmaps for J2SE/Java SE, fact is that >>> J2SE 1.4, and Java 5/6, will have some form of adequate support for a >>> long time yet (http://www.oracle.com/technetwork/java/eol-135779.html). >>> If Java 8, for example, decided to make some backwards-incompatible >>> changes to the language, people with existing code bases would have >>> sufficient options with Java 7 or earlier to keep them happy for a long, >>> long time. I simply do not see the validity of an argument that says >>> that the existence of an incompatible Java 8 or 9 is going to affect any >>> of these people. As it is, I expect not to be primarily working with >>> Java EE 6 and JDK 7 until 2015 at the earliest...and that may be >>> optimistic for the Java EE side of things. >> >> It is true that migrating code to new EE and SE versions are usually >> a lot behind. >> >> But eventually the code get lifted. >> >> Typical because the vendors stop support for the platform. >> >> And changes that does not create runtime exceptions or compile >> time warnings, but silently changes the semantics are about as >> bad as they get. >> >> The fact that it may take many years before the problems are felt does >> not make the problem smaller. > > I should point out that I'm not talking about arithmetic overflow > checking or any other specific feature here. I am quite unconcerned > about arithmetic overflow checking in Java, because I see at least two > better solutions than changing the language: either (1) using a > different language, or (2) being aware of your quantities and actually > putting some thought into your design to avoid overflow. These have been > suggested already. > > I'm talking about backwards-incompatible changes in general. There's no > need to worry about "silent changes to semantics", because by definition > you cannot expect your old source to be compatible with this newest > version. You're told that, and you're told why. You can figure out what > you need to change if you intend to upgrade some codebase, compiler > warnings or no compiler warnings. > > Talking about Java specifically, SE or EE, there is a great deal of > advance warning. You're typically going to have close to a decade of > warning that you need to make certain modifications, if a version at > some point introduces backwards incompatibilities. This is more than > enough time. Since changes that _are_ backwards incompatible will almost > certainly be important changes that should have been introduced much > earlier anyway, and everyone's code should use them, and it will help > everyone's code, where's the downside in forcing people to do some > necessary work? People certainly do take advantage of new APIs and > language features that _are_ backwards compatible, and they need to put > in a lot of work to do that, so how is it somehow a bad thing that > they've got to do a bit of work to upgrade a codebase into a new > backwards-incompatible version? There are usually plenty of warnings. But that does not make the cost go away. And cost is bad. >> Not wanting to spend 6 or 7 digit dollar amounts verifying that >> code still works as original intended does not imply that you may >> not want new features. > > What percentage of business types do you think care about new language > features and new APIs? 10 percent? 5 percent? One percent? What they > care about is can you develop their latest pet project for them. Since > we devs usually can cobble something together, albeit with difficulty, > even with ancient libraries and old language versions, that's how it > goes in real life. > > Let me give you just one example; not so many months ago I had to go > through a lengthy and arduous process with one client, involving much > analysis and multiple meetings, offering assurances all the way up to > Director of IT level, just to bump up an EclipseLink minor version. To > the typical conservative client any upgrade of any library is a Big > Deal. You certainly won't see them clamouring for the speedy adoption of > a new JDK because it offers support for lambdas. More breaking of existing code will make it even harder to get permission to upgrade. It is exactly to get permission to upgrade that the compatibility is so important. > As for code working as originally intended, show me the production > application that is substantively defect-free and works as originally > intended. About the worst that will happen with an upgrade is that the > typical app will break in new ways. > > Sometimes these new breakages are beneficial even. I'm minded of when we > moved a complex J2EE app from one old app server over to a newish one > from another vendor. Suddenly dozens of new defects appeared. Turned out > that all of them were real code defects and that the old app server > simply sucked that bad. My feeling is that forced adoption of better VMs > and better servers and better language features, backwards-incompatible > or no, is generally a good thing - it exposes flaws in codebases. They > didn't get _created_, they were already there. Most/all code has bugs but migrating to a new runtime with slightly different semantics will most likely increase the number of bugs (the old ones will not go away and new will come). Arne
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2011-07-20 14:35 -0700 |
| Message-ID | <sbie2719hkei1cqd8pijdg10nefr5n1g5v@4ax.com> |
| In reply to | #6297 |
On Tue, 19 Jul 2011 21:31:54 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:
[snip]
>Sometimes we just need to realize that a wrong decision was
>made, that we are stuck with it and that it should be done
>correctly in the next language.
The wrong decision was made in C, Java was a next language, and
the correction did not happen in Java (or a number of other next
languages for that matter).
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2011-07-20 18:22 -0400 |
| Message-ID | <4e275522$0$310$14726298@news.sunsite.dk> |
| In reply to | #6314 |
On 7/20/2011 5:35 PM, Gene Wirchenko wrote: > On Tue, 19 Jul 2011 21:31:54 -0400, Arne Vajhøj<arne@vajhoej.dk> > wrote: [snip back] >>> I think the point being made is that it's behavior that could be >>> improved *now*. >>> >>> The prescience required to see 16 years into the future is darn hard. I >>> don't think anyone at all has that kind of skill or knowledge. It would >>> have been better however to acknowledge sometime in the past that Java >>> needed to be improved in some fundamental ways and then make those changes. >>> >>> Generics should have been reifiable, primitives should be "first class >>> objects," integer math should be checked for overflow where the >>> programmer deems needed. These things have been lacking for some time, >>> and are still needed, imo. >>Today it is a must that changes must not break existing code. >> >>That still leaves some room for improvements. >> >>But it tend to become messy. [/snip back] >> Sometimes we just need to realize that a wrong decision was >> made, that we are stuck with it and that it should be done >> correctly in the next language. > > The wrong decision was made in C, Java was a next language, and > the correction did not happen in Java (or a number of other next > languages for that matter). In the context of whether to change Java or not that is utterly irrelevant. Arne
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2011-07-21 14:54 -0700 |
| Message-ID | <nu7h279ke4rg49f9ctaje44gr1rjlk8ts9@4ax.com> |
| In reply to | #6316 |
On Wed, 20 Jul 2011 18:22:24 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:
>On 7/20/2011 5:35 PM, Gene Wirchenko wrote:
>> On Tue, 19 Jul 2011 21:31:54 -0400, Arne Vajhøj<arne@vajhoej.dk>
>> wrote:
[snip]
>>> Sometimes we just need to realize that a wrong decision was
>>> made, that we are stuck with it and that it should be done
>>> correctly in the next language.
>>
>> The wrong decision was made in C, Java was a next language, and
>> the correction did not happen in Java (or a number of other next
>> languages for that matter).
>
>In the context of whether to change Java or not that is utterly irrelevant.
The original decision right or wrong?
If that is so, why the language changes over the years?
Really, the changes could be made to allow for backward
compatibility.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | rop rop <rop049@gmail.com> |
|---|---|
| Date | 2011-07-08 15:34 -0700 |
| Message-ID | <658108b9-3fa9-41dd-8701-9f342633864c@x12g2000yql.googlegroups.com> |
| In reply to | #5975 |
On Jul 8, 2:29 am, lewbloch <lewbl...@gmail.com> wrote: > > Exactly. C does not do that sort of checking, and the meme has > > spread widely. I would much prefer to have things blow up when wrong > > than not blow up. It makes for smaller messes. > > the problem with that statement is that it's not wrong for Java > primitive integer types to wrap around. > > It is, in fact, wrong for them to throw an overflow exception, as many > have pointed out in this thread. > > -- > Lew Hi Lew, Yes, I am sure we all know that it IS 100% per the Java-spec -- no need to point out that... That being said, I personally think it must be one of the most epic design errors in software-history, to DELIBERATELY design a programming-language this way. To me its like... WHAT THE H*** WERE THEY THINKING? :) I mean, it's fine if you have an OPTION for users to turn off overflow- checking, for performance reasons, or whatever other reason someone can dream up. BUT, to make it so difficult for users that (as far as I have been googling up) after 15+years of Java-evolution and refinement, still NOBODY has came up with a simple and robust way of including such an extremely basic "feature" for a software-language. I am a big fan of Java and the "echo-system" around it and all the fun we're having with it every day -- this one being the only BIG EXCEPTION I can think of. What I would hope for is that, still, at some point in the future, there will actually be an OPTION in the JVM to turn on overflow- checking. That way, it can be adopted by users who really value robust and bug- free software, without breaking backwards compatibility with existing code.
[toc] | [prev] | [next] | [standalone]
Page 13 of 14 — ← Prev page 1 … 11 12 [13] 14 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web