From: Screamin Lord Byron on
On 07/13/2010 01:02 PM, Screamin Lord Byron wrote:
> just like it prints 0.8999999999999999 as a
> result of 2. - 0.1.

Typo

2. - 1.1

Anyway, the result isn't exact, of course, but I don't think it would be
such a good idea if println did rounding to show us "expected" 0.9.
From: Patricia Shanahan on
Screamin Lord Byron wrote:
> On 07/13/2010 03:11 AM, Arne Vajhøj wrote:
>> On 12-07-2010 12:36, Screamin Lord Byron wrote:
>>> On 07/12/2010 05:15 PM, markspace wrote:
>>>> J.H.Kim wrote:
>>>>> Hi, everyone
>>>>>
>>>>> My java compiler and interpreter cannot display floating point
>>>>> variable.
>>>>>
>>>>> public class PrintTest {
>>>>> public static void main(String[] args) {
>>>>> double a = 3.141592;
>>>>> System.out.println(a);
>>>>> }
>>>>> }
>>>>>
>>>>> The routine above does not display 3.141592.
>>>> <http://docs.sun.com/source/806-3568/ncg_goldberg.html>
>>>>
>>>> Floating point numbers aren't exact. You can't get exactly 3.141592 out
>>>> of any floating point system. Consider using BigDecimal if you need
>>>> "exact" numbers.
>>>
>>> Well, in this example there is no calculation, and significand fits
>>> within 52 bits of IEEE 754 double type so it should be printed out as
>>> expected: 3.141592. Please someone correct me if I'm wrong.
>> Even though 7 decimals digits is less than 52 bits, then it is
>> far from guaranteed that a 7 decimals number can be represented
>> exact within 52 bit.
>
> I am aware there is a problem of representing fractions in any numeral
> system (for example, decimal 0.1 can't be exactly represented in binary,
> just as 1/3 can't be exactly represented in decimal), and here we're not
> saying nothing like double d = 2. - 0.1;
>
> Am I wrong if I say that the literal 3.141592 is represented in memory
> like this: the sign is 0, the significand is 3141592 and the exponent is
> -6. There are no mathematical operations with this number, so it's sole
> representation is in fact exact, is it not? The println should print it
> like it's represented, just like it prints 0.8999999999999999 as a
> result of 2. - 0.1.
>
>

You are wrong. 3.141592 in Java is a double literal, and double is a
binary floating point type. See
http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.2

"The details of proper input conversion from a Unicode string
representation of a floating-point number to the internal IEEE 754
binary floating-point representation are described for the methods
valueOf of class Float and class Double of the package java.lang."

The actual rule for double is described in
http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/lang/Double.html#valueOf(java.lang.String)

"Otherwise, s is regarded as representing an exact decimal value in the
usual "computerized scientific notation" or as an exact hexadecimal
value; this exact numerical value is then conceptually converted to an
"infinitely precise" binary value that is then rounded to type double by
the usual round-to-nearest rule of IEEE 754 floating-point arithmetic,
which includes preserving the sign of a zero value."

The compiler's input conversion for 3.141592 is necessarily inexact for
the reason you mentioned in the first paragraph.

Patricia
From: Roedy Green on
On Tue, 13 Jul 2010 00:07:36 +0900, "J.H.Kim" <frog1120(a)gmail.com>
wrote, quoted or indirectly quoted someone who said :

> double a = 3.141592;
> System.out.println(a);

see http://mindprod.com/jgloss/decimalformat.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

You encapsulate not just to save typing, but more importantly, to make it easy and safe to change the code later, since you then need change the logic in only one place. Without it, you might fail to change the logic in all the places it occurs.
From: J.H.Kim on
J.H.Kim wrote:

> My compiler version is
>
> frog1120:/home/frog/Java/Work/012# javac -version
> Eclipse Java Compiler v_774_R33x, 3.3.1, Copyright IBM Corp 2000, 2007.
>
> and interpreter version is
>
> frog1120:/home/frog/Java/Work/012# java -version
> java version "1.5.0"
> gij (GNU libgcj) version 4.3.2
> Copyright (C) 2007 Free Software Foundation, Inc.
>

I solved problem by replacing java toolkit with SUN java JDK and JRE.
Thank you.

Best Regards,
J.Hwan Kim
From: John B. Matthews on
In article <2ZGdncexkoRQ76HRnZ2dnUVZ_oednZ2d(a)earthlink.com>,
Patricia Shanahan <pats(a)acm.org> wrote:

> Screamin Lord Byron wrote:
> > On 07/13/2010 03:11 AM, Arne Vajhøj wrote:
> >> On 12-07-2010 12:36, Screamin Lord Byron wrote:
> >>> On 07/12/2010 05:15 PM, markspace wrote:
> >>>> J.H.Kim wrote:
> >>>>> Hi, everyone
> >>>>>
> >>>>> My java compiler and interpreter cannot display floating point
> >>>>> variable.
> >>>>>
> >>>>> public class PrintTest {
> >>>>> public static void main(String[] args) {
> >>>>> double a = 3.141592;
> >>>>> System.out.println(a);
> >>>>> }
> >>>>> }
> >>>>>
> >>>>> The routine above does not display 3.141592.
> >>>> <http://docs.sun.com/source/806-3568/ncg_goldberg.html>
> >>>>
> >>>> Floating point numbers aren't exact. You can't get exactly 3.141592 out
> >>>> of any floating point system. Consider using BigDecimal if you need
> >>>> "exact" numbers.
> >>>
> >>> Well, in this example there is no calculation, and significand
> >>> fits within 52 bits of IEEE 754 double type so it should be
> >>> printed out as expected: 3.141592. Please someone correct me if
> >>> I'm wrong.
> >> Even though 7 decimals digits is less than 52 bits, then it is far
> >> from guaranteed that a 7 decimals number can be represented exact
> >> within 52 bit.
> >
> > I am aware there is a problem of representing fractions in any
> > numeral system (for example, decimal 0.1 can't be exactly
> > represented in binary, just as 1/3 can't be exactly represented in
> > decimal), and here we're not saying nothing like double d = 2. -
> > 0.1;
> >
> > Am I wrong if I say that the literal 3.141592 is represented in
> > memory like this: the sign is 0, the significand is 3141592 and the
> > exponent is -6. There are no mathematical operations with this
> > number, so it's sole representation is in fact exact, is it not?
> > The println should print it like it's represented, just like it
> > prints 0.8999999999999999 as a result of 2. - 0.1.
>
> You are wrong. 3.141592 in Java is a double literal, and double is a
> binary floating point type. See
> http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.2
>
> "The details of proper input conversion from a Unicode string
> representation of a floating-point number to the internal IEEE 754
> binary floating-point representation are described for the methods
> valueOf of class Float and class Double of the package java.lang."
>
> The actual rule for double is described in
> http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/lang/Double.html#valueOf(java.lang.String)
>
> "Otherwise, s is regarded as representing an exact decimal value in
> the usual "computerized scientific notation" or as an exact
> hexadecimal value; this exact numerical value is then conceptually
> converted to an "infinitely precise" binary value that is then
> rounded to type double by the usual round-to-nearest rule of IEEE 754
> floating-point arithmetic, which includes preserving the sign of a
> zero value."
>
> The compiler's input conversion for 3.141592 is necessarily inexact
> for the reason you mentioned in the first paragraph.

I often use this online calculator to peek at the internal representation:

<http://babbage.cs.qc.edu/IEEE-754/Decimal.html>

For double a = 3.141592, Long.toHexString(Double.doubleToRawLongBits(a))
yields 400921fafc8b007a, which breaks down in binary and decimal as
follows:

sign: 0 -> +
exponent: 10000000000 = 1024 - 1023 = 1
significand: 1.1001001000011111101011111100100010110000000001111010
= 1.5707960000000000

2^1 * 1.570796 = 3.141592, also expanded here:

<http://en.wikipedia.org/wiki/Floating_point#Overview>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>