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.com>wrote: > 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), 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 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 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 refers to >>> the >>> decimal representation that has had leading zeroes between decimal point >>> and mantissa trimmed. >>> >>> >>> 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/<http://cr.openjdk.java.net/~bpb/8024356/> >>> >>> If there is any more tweaking of comments which needs to be effected >>> prior >>> to an approval request being posted to 7u-dev, please let me know. >>> >>> Thanks, >>> >>> Brian >>> >>> > > -- > - DML >
