Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #26510
| Newsgroups | comp.lang.java.programmer |
|---|---|
| Date | 2013-11-15 07:01 -0800 |
| References | <loss-20131113231933@ram.dialup.fu-berlin.de> <87txfe22o1.fsf@golem.phantasia.org> <kkla89tv4vb3c60ao7qkj2hr3kd0ims4gc@4ax.com> <l63mh7$afg$1@dont-email.me> <l63sqt$9bm$1@dont-email.me> |
| Message-ID | <4a561493-66cd-44c0-839a-542d752c405c@googlegroups.com> (permalink) |
| Subject | Re: Possible loss of precision |
| From | taqmcg@gmail.com |
On Thursday, November 14, 2013 8:19:27 PM UTC-5, Eric Sosman wrote: > On 11/14/2013 6:31 PM, Eric Sosman wrote: > > As a more concrete example, > > static final double FOO = 17.316; > static final double BAR = 8.658; > int i = FOO / BAR; // Should javac be silent here? > > Neither the numerator nor the denominator can be represented > exactly as stated, yet the quotient is (probably; cook up your > own numbers if mine are faulty) exactly 2.0. Would it be a > good idea to let this construct slide through unremarked? Or > should javac acknowledge the inherent imprecisions in the > operations leading to the exactly-integral result? In this case it's pretty clear that the error should be signaled since we have a floating point expression that involves computations where roundoff's could do weird things: Consider the case when we use FOO = 3.3 and BAR = 1.1. Then the value of (int) (FOO/BAR) == 2 and I certainly wouldn't want to have a language where int i = 3.3/1.1; gives a different result than double x = 3.3; double y = 1.1; int i = x/y; When the integer value of the ration is a power of 2, then the internal floating point representations will differ only in the exponent, so you're likely get 'correct' values when you do the computation, but for all other integer ratios the actual value that a proper Java program would computer will often differ from the 'correct' value. And even for powers of two one is going to run into problems if denormalized floats or doubles are being used. If we exclude expressions there would be still hard cases: E.g., if we were allowing int i = 2.0; presumably we'd also want to allow int i = 1.234E3; // = 1234) but then you might be surprised to get an error for the equivalent int i = 1.2345E3; // = 1234.5 which doesn't really look very differnt. And what would one do with: int i = 123456789.f; which seems like a normal integer, but since we've gone beyond the precision of floats we'd find that float f = 123456789.f; int i = (int) f; yields i == 123456792 We wouldn't run into this when converting doubles to ints, but a similar problem occurs for doubles to longs. So any relaxation of the rule that there is a loss-of-precision error in converting floating point values to integral values would have to be either arbitrarily limited (say to |integers| < 100) or hedged with lots of caveats. Having a simple rule that you need to signal such a conversion with a cast seems like a reasonable choice. Personally I'd have preferred that Java be fully consistent here and not have the exception for operators like += double x = 1.; int i = 0; i += x; // is legal but I believe that exception is essentially required by the (imho) folly of automatic promotion of bytes, shorts and chars to ints. Regards, Tom McGlynn
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Possible loss of precision Michael Jung <miju@golem.phantasia.org> - 2013-11-14 20:39 +0100
Re: Possible loss of precision Gene Wirchenko <genew@telus.net> - 2013-11-14 15:03 -0800
Re: Possible loss of precision Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-11-14 18:31 -0500
Re: Possible loss of precision Joerg Meier <joergmmeier@arcor.de> - 2013-11-15 00:55 +0100
Re: Possible loss of precision Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-11-14 20:19 -0500
Re: Possible loss of precision taqmcg@gmail.com - 2013-11-15 07:01 -0800
Re: Possible loss of precision Martin Gregorie <martin@address-in-sig.invalid> - 2013-11-15 21:36 +0000
Re: Possible loss of precision Michael Jung <miju@golem.phantasia.org> - 2013-11-15 19:24 +0100
Re: Possible loss of precision Patricia Shanahan <pats@acm.org> - 2013-11-15 20:48 -0800
Re: Possible loss of precision Michael Jung <miju@golem.phantasia.org> - 2013-11-17 13:28 +0100
Re: Possible loss of precision Patricia Shanahan <pats@acm.org> - 2013-11-17 08:05 -0800
csiph-web