From dev-return-39797-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Fri Sep 17 01:55:48 2010
Return-Path:
Delivered-To: apmail-harmony-dev-archive@www.apache.org
Received: (qmail 38251 invoked from network); 17 Sep 2010 01:55:48 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
by 140.211.11.9 with SMTP; 17 Sep 2010 01:55:48 -0000
Received: (qmail 28333 invoked by uid 500); 17 Sep 2010 01:55:48 -0000
Delivered-To: apmail-harmony-dev-archive@harmony.apache.org
Received: (qmail 28215 invoked by uid 500); 17 Sep 2010 01:55:47 -0000
Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@harmony.apache.org
Delivered-To: mailing list dev@harmony.apache.org
Received: (qmail 28206 invoked by uid 99); 17 Sep 2010 01:55:46 -0000
Received: from Unknown (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Sep 2010 01:55:46 +0000
X-ASF-Spam-Status: No, hits=2.2 required=10.0
tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of devyoudw@gmail.com designates 74.125.83.49 as permitted sender)
Received: from [74.125.83.49] (HELO mail-gw0-f49.google.com) (74.125.83.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Sep 2010 01:55:23 +0000
Received: by gwj21 with SMTP id 21so790410gwj.36
for ; Thu, 16 Sep 2010 18:55:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:received:in-reply-to
:references:date:message-id:subject:from:to:content-type;
bh=Oh3beQ5WXE6TCfMjgCtHOCut6BCk0Bw9A4iYw/kwntU=;
b=OkpAeKH2NPp4cV1It2bYlG+zo4ASu61VJG6Yt87uVOB2bACR5tCpssvXmaxdyEY786
gOo776EYI29Gf7/XLVmUmQk6Nc+bW6p3qKIPU5sT9zQdAINwojo0qBSgAfzFHOa9GV5i
dlrklQCscWHGUQxXCjh+tN9pWG2gVSaYvI970=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
b=uGWh1eDWpuHqjh831xBKyVQRoeCeZzk7KgmYXSSQC9cEd7oo9A+qAgmTyZRIT03vYq
7wDAIZT13YlXYbYZaU4N5W0JbpxzmWwNPLLuAINrlcXVwO3I8CzdRVy7M2b7KbJNDvn3
l4hMfyJlEgT10iGnsFYOETSTtb+el6KwDbmnA=
MIME-Version: 1.0
Received: by 10.100.5.3 with SMTP id 3mr4670097ane.153.1284688502090; Thu, 16
Sep 2010 18:55:02 -0700 (PDT)
Received: by 10.100.119.7 with HTTP; Thu, 16 Sep 2010 18:55:02 -0700 (PDT)
In-Reply-To:
References:
Date: Fri, 17 Sep 2010 09:55:02 +0800
Message-ID:
Subject: Re: [classlib][luni]Float.toString - inaccuracy in the last digit
From: Deven You
To: dev@harmony.apache.org
Content-Type: multipart/alternative; boundary=0016e642d34ed06c3804906ad95f
X-Virus-Checked: Checked by ClamAV on apache.org
--0016e642d34ed06c3804906ad95f
Content-Type: text/plain; charset=ISO-8859-1
Thanks Chance,
I have read the spec again. From my understanding, the spec requires the
value "x" of finite decimal represented by the Float.toString() meet below
conditions:
1. the "f" is one of float values which are nearest to "x".
2. the number of the fractional part of "x" must be as many as need and the
more digits are needed to uniquely distinguish the argument value.
In our case, if 6.021427E18 is already meet the above conditions and if the
last digit "1" of 6.0214271E18 has no use to distinguish the argument value,
then our result is right and RI is not correct.
In Chance's reply, he has used one example to show this situation. If the
algorithm of our code just do the logic of what spec requires. I believe
harmony does the right things and RI is not correct.
2010/9/16 Shi Jun Zhang
> Hi,
>
> I'm curious whether the implementation in Harmony is wrong or RI just
> doesn't follow the spec.
>
> Here is the spec for java.lang.Float.toString(float f)
>
> public static String *toString*(float f)
>
> Returns a string representation of the float argument. All characters
> mentioned below are ASCII characters.
>
> - If the argument is NaN, the result is the string "NaN".
> - Otherwise, the result is a string that represents the sign and
> magnitude (absolute value) of the argument. If the sign is negative, the
> first character of the result is '-' ('\u002D'); if the sign is positive,
> no sign character appears in the result. As for the magnitude *m*:
> - If *m* is infinity, it is represented by the characters "Infinity";
> thus, positive infinity produces the result "Infinity" and negative
> infinity produces the result "-Infinity".
> - If *m* is zero, it is represented by the characters "0.0"; thus,
> negative zero produces the result "-0.0" and positive zero produces
> the result "0.0".
> - If *m* is greater than or equal to 10-3 but less than 107, then it
> is represented as the integer part of *m*, in decimal form with no
> leading zeroes, followed by '.' ('\u002E'), followed by one or more
> decimal digits representing the fractional part of *m*.
> - If *m* is less than 10-3 or greater than or equal to 107, then it is
> represented in so-called "computerized scientific notation." Let
> *n*be the unique integer such that 10
> *n* <= *m* < 10*n*+1; then let *a* be the mathematically exact
> quotient of *m* and 10*n* so that 1 <= *a* < 10. The magnitude is then
> represented as the integer part of *a*, as a single decimal digit,
> followed by '.' ('\u002E'), followed by decimal digits representing
> the fractional part of *a*, followed by the letter 'E' ('\u0045'),
> followed by a representation of *n* as a decimal integer, as produced
> by the method Integer.toString(int).
>
> How many digits must be printed for the fractional part of *m* or *a*?
> There
> must be at least one digit to represent the fractional part, and beyond
> that
> *as many, but only as many*, more digits as are needed to uniquely
> distinguish the argument value from adjacent values of type float. That is,
> suppose that *x* is the exact mathematical value represented by the decimal
> representation produced by this method for a finite nonzero argument *f*.
> Then *f* must be the float value nearest to *x*; or, if two float values
> are
> equally close to *x*, then *f* must be one of them and the least
> significant
> bit of the significand of *f* must be 0.
>
> To create localized string representations of a floating-point value, use
> subclasses of NumberFormat.
>
> *Parameters:*f - the float to be converted. *Returns:*a string
> representation of the argument. Please notice the words in red, "as many,
> but only as many". In Mohan's case, the binary value for float
> 6.0214271E18f
> is 01011110 10100111 00100000 11010000 and its exact decimal value is
> 6.021427051003641856E18, should the string representation be "6.021427E18"
> or "6.0214271E18" ?
>
> Let's look at the following 3 closest float value.
> Hex
> Binary Decimal
> 0x5EA720CF 01011110 10100111 00100000 11001111
> 6.021426501247827968E18
> 0x5EA720D0 01011110 10100111 00100000 11010000
> 6.021427051003641856E18
> 0x5EA720D1 01011110 10100111 00100000 11010001
> 6.021427600759455744E18
>
> The argument f is 6.021427051003641856E18. When x is 6.0214271E18, f is the
> float value nearest to x. When x is 6.021427E18, f is still the float value
> nearest to x. When x is 6.02143E18, f is NOT the float value nearest to x.
> So as my understanding, "6.021427E18" is the string should be returned, it
> contains "as many, but only as many" digits to represent the float value f.
> Is there any thing that i misunderstand?
>
> On Wed, Jul 28, 2010 at 1:33 AM, Mohanraj Loganathan
> wrote:
>
> > Following test[1] fails in Harmony. But passes in RI.
> >
> > [1] test:
> > float r=6.0214271E18f;
> > String s=Float.toString(r);
> > assertEquals("6.0214271E18",s);
> > Harmony prints: 6.021427E18 (note '1' is missing from the converted
> > string)
> >
> > When i looked into the implementation of harmony, i come to know its a
> > limitation to the algorithm implemented in Harmony (Printing
> > Floating-Point Numbers Quickly and Accurately, Robert G. Burger, and
> > R. Kent Dybvig, Programming Language Design and Implementation (PLDI)
> > 1996, pp.108-116)
> >
> >
> >
> https://svn.apache.org/repos/asf/harmony/enhanced/java/branches/java6/classlib/modules/luni/src/main/native/luni/shared/dblparse.c
> >
> > function:
> >
> java_org_apache_harmony_luni_util_NumberConverter_bigIntDigitGeneratorInstImpl
> >
> > I am clue-less to find the flaw in the implementation. Any comments
> > from experts of this area?
> >
> > I will raise a JIRA for this issue.
> >
> > Thanks and Regards,
> > Mohan
> >
>
>
>
> --
> Shi Jun Zhang
>
--0016e642d34ed06c3804906ad95f--