Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #26510

Re: Possible loss of precision

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

Show all headers | View raw


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


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