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

>> <(E-Mail Removed)> wrote:

>>

>>> (E-Mail Removed)-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

(E-Mail Removed)d