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

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

Re: Possible loss of precision

Show all headers | View raw

On 11/14/2013 6:31 PM, Eric Sosman wrote:
> On 11/14/2013 6:03 PM, Gene Wirchenko wrote:
>> On Thu, 14 Nov 2013 20:39:42 +0100, Michael Jung
>> <miju@golem.phantasia.org> wrote:
>>
>>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>> char x = 'C' + 1;
>>>> x = x + 1;
>>>>    in a block, one gets an error message
>>>> »possible loss of precision«
>>>>    for »x = x + 1«. Ok, fair enough: »x + 1« has type »int«,
>>>>    and precision is lost when assigning this to the variable x
>>>>    of type char.
>>>>    I was somewhat surprised, though, that »char x = 'C' + 1;«
>>>>    does not yield an error, even though the type of »'C' + 1«
>>>>    is int, too. Possibly, this time, the compiler can figure
>>>>    out that the actual value still fits into a char.
>>>>    But then, »int i = 2.0;« gives an error, even though the
>>>>    compiler should see that »2.0« can be represented as an int.
>>>
>>> You are right that x+1 is "promoted" to int and the second assignment
>>> fails.  In the other cases the compiler will follow JLS 15.28 => 5.2.
>>> This concerns constant expressions first and the second allows a
>>> narrowing in rare cases, of which the first line is one but the
>>> "int i = 2.0" isn't.
>>
>>       Why isn't it though?
>
>      Speculation: The fact that a floating-point expression happens
> to evaluate to a number with no fractional part doesn't mean the
> value "is" an integer.  One reasonable view of FP is that a value
> is just a representative of a range of real values, namely, all
> those real values that round to the representative.  In this
> view, converting 2.0 to 2 *does* lose precision, specifically,
> the amount of wiggle room.

     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?

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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