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 08:46:11 -0700
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <iqm848$52b$1@dont-email.me>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 14 May 2011 15:46:17 +0000 (UTC)
Injection-Info: mx03.eternal-september.org; posting-host="WVxXJ+PBP15/OyWIUXGhOQ"; logging-data="5195"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19ctRoBhmrhL0cBd2zDtOL06C+Ip6SsR5Y="
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.1105140954470.12373@urchin.earth.li>
Cancel-Lock: sha1:2kDWOxy1MDoQym8ZAlSNUTzwQNo=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4076

On 5/14/2011 2:18 AM, Tom Anderson wrote:

> The semantics of which, i've realised, is an utter can of worms. Does this:
>
> byte b = 100;
> byte c = (b + b) - b;
>
> Throw an exception?


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.


> One semantics that would work (i think) would be that all expressions
> are evaluated at infinite precision,


If you've ever actually tried to use BigDecimal with its "infinite 
precision" mode, you know that this blows up pretty quickly due to out 
of memory errors.  The first time you try to evaluate 1/3, it throws an 
error.  Infinite precision is not the answer.

Once again, I'm only interested in *incorrect results* being detected. 
As long as the result can be guaranteed correct, then it's fine, however 
the compiler and optimizer choose to implement it.