On Sep 13, 2013, at 7:02 PM, Dmitry Nadezhin wrote:
I agree with 1100 for this review (JDK7).
OK. I will post an approval request to 7u-dev for the patch as-is.
I think that we shouldn't change from 1100 to 768 in JDK8 because this is a
small performance enhancement.
This will save time
I would suggest leaving it at 1100 for this review (JDK7) and to 768 (0x003) in
JDK8. The latter will require another issue to be filed.
On Sep 12, 2013, at 9:25 PM, Dmitry Nadezhin wrote:
For me, it is the only consideration.
I'm sure in 768 because I proved it formally using ACL2 tool.
I agree with 1100 for this review (JDK7).
I think that we shouldn't change from 1100 to 768 in JDK8 because this is a
small performance enhancement.
This will save time for fixing other bugs.
The performance enhancement could be smarter if we replace constant
MAX_NDIGIT by some piece-linear
This explanation seems to combine numbers of binary digits (1075)
and numbers of decimal digits (17), and therefore makes me a little
nervous, though I think 1100 is a conservative choice that, even if not
100% correct, will be 99.(over 700 9s)% correct.
David
On 2013-09-12, at 1:17 AM, Dmitry
The reason while binary and decimal digits are mixed can be ullustrated by
such example.
It is necessary 3 decimal fraction digits to represent exactly pbinary
power pow(2,-3) :
pow(2,-3)=1/8=0.125
On Thu, Sep 12, 2013 at 3:57 PM, David Chase david.r.ch...@oracle.comwrote:
This explanation
On 09/12/2013 09:17 AM, Dmitry Nadezhin wrote:
The patch is correct when decimal ULP of kept digits is pow(10,-1075)
of less. pow(2,53) has 17 decimal decimal digits. MAX_NDIGITS = 1100
1075 + 17 .
OK. That makes more sense. Can we please add the short comment in the
code (maybe next time
On 2013-09-12, at 8:18 AM, Dmitry Nadezhin dmitry.nadez...@gmail.com wrote:
The reason while binary and decimal digits are mixed can be ullustrated by
such example.
It is necessary 3 decimal fraction digits to represent exactly pbinary
power pow(2,-3) :
pow(2,-3)=1/8=0.125
On Thu, Sep
I think the reason you use 1075 digits is because it takes 1075 decimal digits
behind the decimal point to exactly represent 2^-1075,
and that is 1/2 ulp. When you discard the tail, if it happens to be all
zeroes, I hope you replace it with a zero, not a one, because otherwise you can
round
Never mind, this is in the context of FloatingDecimal and any trailing zeroes
are properly discarded.
Carry on, this code looks correct, despite my misunderstanding the explanation.
David
On 2013-09-12, at 12:32 PM, David Chase david.r.ch...@oracle.com wrote:
I think the reason you use 1075
Aleksey, I like your wording of the comment. Thank you very much.
I would reformulate a little:
We can demonstrate (link) that decimal ulp should be less than 10^(-1075)
to guarantee correctness
===
We can demonstrate (link) that decimal ulp less than 10^(-1075) is enough
to guarantee
JDK repository constains sources and tests now.
Where should proofs live ?
And also where should benchmarks live ?
On Thu, Sep 12, 2013 at 10:32 PM, Brian Burkhalter
brian.burkhal...@oracle.com wrote:
What should be put in for link?
Thanks,
Brian
On Sep 12, 2013, at 11:10 AM, Dmitry
What should be put in for link?
Thanks,
Brian
On Sep 12, 2013, at 11:10 AM, Dmitry Nadezhin wrote:
Aleksey, I like your wording of the comment. Thank you very much.
I would reformulate a little:
We can demonstrate (link) that decimal ulp should be less than 10^(-1075)
to guarantee
On 2013-09-12, at 1:17 AM, Dmitry Nadezhin dmitry.nadez...@gmail.com wrote:
The optimal constant for double conversion could be 768 ,
the optimal constant for float conversion could be 142,
but I leave this optimization to JDK 9.
It would be helpful to mention in the proof/comment, that 768
I know, I checked the census. The Reviewed-by header field can include any
OpenJDK member AFAIK. The approval for pushing is a separate story and has to
be handled via e-mail on the 7u-dev list (and a 7u-dev committer will be needed
eventually).
Thanks,
Brian
On Sep 12, 2013, at 1:57 PM,
On Sep 12, 2013, at 1:00 PM, David Chase wrote:
On 2013-09-12, at 1:17 AM, Dmitry Nadezhin dmitry.nadez...@gmail.com wrote:
The optimal constant for double conversion could be 768 ,
the optimal constant for float conversion could be 142,
but I leave this optimization to JDK 9.
It would be
On 13.09.2013, at 0:49, Brian Burkhalter brian.burkhal...@oracle.com wrote:
I updated the webrev to include a comment for MAX_NDIGITS sans both hyperlink
and the foregoing verbiage:
http://cr.openjdk.java.net/~bpb/8024356/
Thumbs up.
-Aleksey
Careful, I don't think I'm a Reviewer.
I merely had the misfortune to care a whole lot about this stuff once long long
ago.
David
On 2013-09-12, at 4:49 PM, Brian Burkhalter brian.burkhal...@oracle.com wrote:
On Sep 12, 2013, at 1:00 PM, David Chase wrote:
On 2013-09-12, at 1:17 AM, Dmitry
Should we change conservative constant 1100 to optimal constant 768 ?
My opinion is no (in JDK7), because the constant 1100 has lower cost of
review.
I mean that chances that a reviewer approves 1100 are higher than chances
that [s]he approves 768.
On Fri, Sep 13, 2013 at 12:49 AM, Brian
If that's the only consideration then just use 0x300 instead, which is
easier to read *and* makes more sense anyway, in the context of the test.
On 09/12/2013 10:13 PM, Dmitry Nadezhin wrote:
Should we change conservative constant 1100 to optimal constant 768 ?
My opinion is no (in JDK7),
For me, it is the only consideration.
I'm sure in 768 because I proved it formally using ACL2 tool.
On Fri, Sep 13, 2013 at 7:45 AM, David M. Lloyd david.ll...@redhat.comwrote:
If that's the only consideration then just use 0x300 instead, which is
easier to read *and* makes more sense anyway,
The short answer: because it is a backport to JDK 7 of part of this JDK 8
change:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017958.html
The long answer is the theory behind the change.
Java conversion from decimal string to double is specified as if it happens
in two steps:
Please review at your convenience.
Issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024356
Webrev: http://cr.openjdk.java.net/~bpb/8024356/
Thanks,
Brian
22 matches
Mail list logo
