digitalmars.D.bugs - [Issue 366] New: Adding trailing zeros to a real literal makes it smaller!
- d-bugmail puremagic.com (20/20) Sep 25 2006 http://d.puremagic.com/issues/show_bug.cgi?id=366
- d-bugmail puremagic.com (12/12) Sep 25 2006 http://d.puremagic.com/issues/show_bug.cgi?id=366
- Don Clugston (6/24) Sep 25 2006 In fact, adding ANY digits to the literal makes it smaller. This one
- Walter Bright (5/18) Sep 26 2006 Those extra digits are beyond the precision of the floating point
- Don Clugston (23/43) Sep 26 2006 Don't worry, I'm a constant user of the %a format!
- Walter Bright (3/7) Sep 26 2006 Might as well leave it as a bug, then, although the issue is with
http://d.puremagic.com/issues/show_bug.cgi?id=366 Summary: Adding trailing zeros to a real literal makes it smaller! Product: D Version: 0.168 Platform: PC OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: clugdbug yahoo.com.au I know that conversions of decimal literals to floating point is always a bit dodgy -- but this particular behaviour is hard to understand. Happens with lots of numbers. static assert( 0.6600_0112_2408_4800_3227e-8L <= 0.6600_0112_2408_4800_32270000e-8L); --
Sep 25 2006
http://d.puremagic.com/issues/show_bug.cgi?id=366 bugzilla digitalmars.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID Conversion from decimal to binary is done using "round to nearest", not "truncate towards zero". Round to nearest will 50% of the time result in larger numbers than truncating towards 0. Adding 0's to the literal is the same as truncate towards zero. --
Sep 25 2006
d-bugmail puremagic.com wrote:http://d.puremagic.com/issues/show_bug.cgi?id=366 bugzilla digitalmars.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID Conversion from decimal to binary is done using "round to nearest", not "truncate towards zero". Round to nearest will 50% of the time result in larger numbers than truncating towards 0. Adding 0's to the literal is the same as truncate towards zero.In fact, adding ANY digits to the literal makes it smaller. This one also fails: static assert( 0.6600_0112_2408_4800_3227e-8L <= 0.6600_0112_2408_4800_3227999999999999999999999999999999e-8L);
Sep 25 2006
Don Clugston wrote:Those extra digits are beyond the precision of the floating point format. Try printing them out in %a format to see the bit pattern. The behavior is governed by C's strtold, and it does the same thing in gcc. I can send you the source to strtold if you want to examine it.Conversion from decimal to binary is done using "round to nearest", not "truncate towards zero". Round to nearest will 50% of the time result in larger numbers than truncating towards 0. Adding 0's to the literal is the same as truncate towards zero.In fact, adding ANY digits to the literal makes it smaller. This one also fails: static assert( 0.6600_0112_2408_4800_3227e-8L <= 0.6600_0112_2408_4800_3227999999999999999999999999999999e-8L);
Sep 26 2006
Walter Bright wrote:Don Clugston wrote:Don't worry, I'm a constant user of the %a format! I've been reading a recent draft of the IEEE 754R standard. It states: (here μ = real.dig, but could be quadruple.dig if it were expanded). ----------- If more than μ digits are given for decimal-string to internal conversions, the result of the conversion shall be as if it were carried out in two steps: First round the given number to μ decimal digits, and then convert the resulting μ-digit number to the target format, in both cases rounding correctly according to the prevailing rounding mode. As a consequence of the foregoing, conversions shall be monotonic: increasing the value of an internal floating-point number shall not decrease its value after conversion to an external character sequence, and increasing the value of a external character sequence shall not decrease its value after conversion to an internal floating-point number. ------------ It's the first step (decimal rounding) that appears to be missing. I don't know how much of a change this is from IEEE 754. Without monotonicity, you need to be very careful about increasing the precision of constants.Those extra digits are beyond the precision of the floating point format. Try printing them out in %a format to see the bit pattern. The behavior is governed by C's strtold, and it does the same thing in gcc. I can send you the source to strtold if you want to examine it.Conversion from decimal to binary is done using "round to nearest", not "truncate towards zero". Round to nearest will 50% of the time result in larger numbers than truncating towards 0. Adding 0's to the literal is the same as truncate towards zero.In fact, adding ANY digits to the literal makes it smaller. This one also fails: static assert( 0.6600_0112_2408_4800_3227e-8L <= 0.6600_0112_2408_4800_3227999999999999999999999999999999e-8L);
Sep 26 2006
Don Clugston wrote:It's the first step (decimal rounding) that appears to be missing. I don't know how much of a change this is from IEEE 754. Without monotonicity, you need to be very careful about increasing the precision of constants.Might as well leave it as a bug, then, although the issue is with strtold which the D lexer relies on.
Sep 26 2006