Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #4098
| Path | csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail |
|---|---|
| From | markspace <-@.> |
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Java puzzler |
| Date | Sat, 14 May 2011 18:35:23 -0700 |
| Organization | A noiseless patient Spider |
| Lines | 60 |
| Message-ID | <iqnakv$t9g$1@dont-email.me> (permalink) |
| References | <4db69c13-878f-4806-adb2-a3c5adb1c48c@glegroupsg2000goo.googlegroups.com> <qrGdnWE1mOKFHVfQnZ2dnUVZ_uKdnZ2d@earthlink.com> <alpine.DEB.2.00.1105112141410.27211@urchin.earth.li> <I6SdnROEzeMni1bQnZ2dnUVZ_sKdnZ2d@earthlink.com> <alpine.DEB.2.00.1105122029030.7602@urchin.earth.li> <-8mdnSRPEIdA21HQnZ2dnUVZ_j2dnZ2d@earthlink.com> <iqhhim$blg$4@speranza.aioe.org> <iqhjks$798$1@dont-email.me> <AcCdnflMosQt-lHQnZ2dnUVZ_t2dnZ2d@earthlink.com> <iqhumi$750$1@dont-email.me> <jY-dnS9ZV4RyG1HQnZ2dnUVZ_tadnZ2d@earthlink.com> <alpine.DEB.2.00.1105140954470.12373@urchin.earth.li> <iqm848$52b$1@dont-email.me> <alpine.DEB.2.00.1105150033090.12373@urchin.earth.li> |
| Mime-Version | 1.0 |
| Content-Type | text/plain; charset=ISO-8859-1; format=flowed |
| Content-Transfer-Encoding | 7bit |
| Injection-Date | Sun, 15 May 2011 01:35:29 +0000 (UTC) |
| Injection-Info | mx02.eternal-september.org; posting-host="nn71ZrjugVG21e3EHm1tIQ"; logging-data="30000"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19IKr7oQEzHlUcJJU4vqgisqK9S3y2se4M=" |
| User-Agent | Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 |
| In-Reply-To | <alpine.DEB.2.00.1105150033090.12373@urchin.earth.li> |
| Cancel-Lock | sha1:j2KvtG3v3hh1wnOGFjPN/PZ3tjQ= |
| Xref | x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4098 |
Show key headers only | View raw
>> On 5/14/2011 2:18 AM, Tom Anderson wrote: >>> byte b = 100; >>> byte c = (b + b) - b; > On Sat, 14 May 2011, markspace wrote: >> I have no opinion about that. I'm only interested in cases where the >> actual result would be incorrect due to overflow at the machine level. On 5/14/2011 4:41 PM, Tom Anderson wrote: > So an expression which might give the right answer, or might blow up, > depending on how the compiler felt, is okay, just as long as it never > gives the wrong answer? Right. If c above in your example is 100, that's fine. Or if the machine tries to compute it without any algebraeic optimization and gets an overflow after the first operation, that's fine too. As long as it doesn't complete and tell me the answer is -20 or something, without throwing an exception. > I'm only saying that the semantics would be defined in terms of infinite > precision; the implementation could be anything the compiler can come up > with which simulates the semantics. Since we're talking about fairly > small expressions with integers, i would expect it to do a good job of > finding efficient ways to compute things. For example, in the c = (b + > b) - b case, it would be free to reduce that to c = b. I think I understand what you are saying, but that's not what I'm after, personally. What I'm saying is: at the machine level, the implementation is free to throw an excpetion if any intermediate calculation overflows. I think that's the difference between "infinite precision" and saying the compiler and optimizer have some latitude. What I'm really worried about is how do you simulate "infinite precision" with longs or something like that, where there is no larger width word? It becomes a mess. Then there's also really large numbers of small width integers, which could overflow quickly, but "infinite precision" means they don't overflow until the end. Both of those scenarios are impractical to implement with "infinite precision" I think. > The problem is that not all correct results are practical to compute > with finite-width arithmetic. That means that as well as a rule that > results have to be correct, we have to have a rule about when results > that would be correct explode. It's alright for a result to not be correct, as long the system throws an exception instead. That's the rule: incorrect result means throw an exception. Just to be 100% clear, what I'm really after is for Java to use the existing hardware detection that exists in most platforms for integer overflow/underflow. It's practically cost free, and would really go a long ways to making programs error-free, imo. That's what I'm gunning for.
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar
Re: Java puzzler Gábor Bakos <aborgabor@gmail.com> - 2011-05-11 01:44 -0700
Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-11 05:24 -0700
Re: Java puzzler Tom Anderson <twic@urchin.earth.li> - 2011-05-11 21:57 +0100
Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-11 16:07 -0700
Re: Java puzzler Tom Anderson <twic@urchin.earth.li> - 2011-05-12 21:38 +0100
Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-12 13:45 -0700
Re: Java puzzler Nancy 3 <n3@gmai1.c0m> - 2011-05-12 16:56 -0400
Re: Java puzzler markspace <-@.> - 2011-05-12 14:32 -0700
Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-12 16:05 -0700
Re: Java puzzler markspace <-@.> - 2011-05-12 17:40 -0700
Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-12 18:18 -0700
Re: Java puzzler markspace <-@.> - 2011-05-12 19:26 -0700
Re: Java puzzler Tom Anderson <twic@urchin.earth.li> - 2011-05-14 10:18 +0100
Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-14 08:09 -0700
Re: Java puzzler Lew <noone@lewscanon.com> - 2011-05-14 13:00 -0400
Re: Java puzzler Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-14 15:08 -0400
Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-14 13:25 -0700
Re: Java puzzler markspace <-@.> - 2011-05-14 08:46 -0700
Re: Java puzzler Spock <spock@starfleet.ufp> - 2011-05-14 19:33 -0400
Re: Java puzzler Tom Anderson <twic@urchin.earth.li> - 2011-05-15 00:41 +0100
Re: Java puzzler markspace <-@.> - 2011-05-14 18:35 -0700
Re: Java puzzler Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-14 23:43 -0400
Re: Java puzzler Tom Anderson <twic@urchin.earth.li> - 2011-05-15 11:16 +0100
Re: Java puzzler markspace <-@.> - 2011-05-15 05:40 -0700
Re: Java puzzler Tom Anderson <twic@urchin.earth.li> - 2011-05-15 15:23 +0100
Re: Java puzzler markspace <-@.> - 2011-05-15 08:09 -0700
Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-15 07:37 -0700
Re: Java puzzler markspace <-@.> - 2011-05-15 08:00 -0700
Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-15 08:16 -0700
Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-15 07:35 -0700
Re: Java puzzler markspace <-@.> - 2011-05-15 08:11 -0700
Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-15 08:15 -0700
Re: Java puzzler Lew <noone@lewscanon.com> - 2011-05-15 13:11 -0400
Re: Java puzzler Nancy 3 <n3@gmai1.c0m> - 2011-05-12 20:47 -0400
Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-12 18:00 -0700
Re: Java puzzler markspace <-@.> - 2011-05-12 18:01 -0700
Re: Java puzzler Nancy 3 <n3@gmai1.c0m> - 2011-05-12 21:22 -0400
Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-12 18:32 -0700
Re: Java puzzler Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-12 22:34 -0400
Re: Java puzzler Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-12 22:27 -0400
Re: Java puzzler "John B. Matthews" <nospam@nospam.invalid> - 2011-05-12 00:28 -0400
Re: Java puzzler Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-12 10:33 -0400
Re: Java puzzler Lew <noone@lewscanon.com> - 2011-05-11 09:12 -0400
Re: Java puzzler Lew <noone@lewscanon.com> - 2011-05-11 09:13 -0400
Re: Java puzzler markspace <-@.> - 2011-05-11 08:00 -0700
csiph-web