Some of the results of RyuFloat are different from that of JDK about ryu HOT 7 CLOSED

from ryu.

The initial report is a known issue (#8).

I didn't double-check all the values you provided, but here's RyuFloat debugging output for the first value 0.33007812f (you can edit RyuFloat.java line 86 and then run it as a main class to get this output):

IN=111110101010010000000000000000
   S=+ E=-25 M=11075584
Exact values
  m =44302336
  E =-1
  d+=330078139901161193847656250
  d =330078125000000000000000000
  d-=330078110098838806152343750
  e2=-27
44302336 * 5^27 / 10^18 = 44302336 * 5^9 / 2^18
Actual values
  d+=330078139
  d =330078125
  d-=330078110
  last removed=0
  e10=-9
  d+10=false
  d-10=false
Actual values after loop
  d+=33007813
  d =33007812
  d-=33007811
  last removed=5
  e10=-9
  d+10=false
  d-10=false
  output=33007813
  output_length=8
  output_exponent=-1
0.33007813 0.33007812

This is a bit much, but these are the most important lines:

  d+=330078139901161193847656250
  d =330078125000000000000000000
  d-=330078110098838806152343750

I'm using BigInteger to compute the exact decimal representation of the number itself, as well as the lower and upper bounds. For a complete explanation, I'll have to refer to the paper, but - briefly - the lower and upper bounds give the range within which the output must be in order to be round-trip safe, i.e., if you want the original number back, you must output a number that's between the bounds.

Here, the bounds are:

0.330078110098838806152343750 <= x <= 0.330078139901161193847656250

Both Ryu's output and the OpenJDK output numbers that are between the bounds. This is easy to see if you write them in the same column:

upper:   0.330078139901161193847656250
Ryu:     0.33007813
OpenJDK: 0.33007812
lower:   0.330078110098838806152343750

In fact, these are the only shortest decimal floating point numbers in this interval. But since we have a choice, which one should we take? We now look at the exact number, which is:

upper:   0.330078139901161193847656250
Ryu:     0.33007813
exact:   0.330078125000000000000000000
OpenJDK: 0.33007812
lower:   0.330078110098838806152343750

As you can see, the exact number has a 5 next, followed by zeroes. In this case, the Ryu's specification says that we need to round to even, so it should round down and output 0.33007812. It's not doing that right now.

from ryu.

As for printf, it doesn't use the same specification as Ryu - Ryu always outputs the shortest possible value that correctly converts back to the original number, and it should round-even in case of a tie.

from ryu.

I pushed a fix for 32-bit floats. Please follow #8 if you're interested in a complete resolution.

from ryu.

Shouldn't it be fixed for 64-bit doubles too?

Also, the following branch cannot be reached because the previous branch handles all cases when q <= 1:
https://github.com/ulfjack/ryu/blob/master/ryu/d2s.c#L330

from ryu.

Yes, it definitely needs to be fixed for doubles as well.

I don't understand your second statement, I'm afraid. Maybe the code has changed?

from ryu.

Never-mind about my 2nd statement, I have misunderstood those C statements.

Comparing with C version I see that the following statement possible was missed in Java: dvIsTrailingZeros &= lastRemovedDigit == 0 - for both rounding loops just before updating of the last removed digit.

from ryu.