-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Differences from paper #119
Comments
Hi Simon! That is an excellent question. The algorithm in the paper returns a conservative value for the required number of bits, not a tight bound. I have been trying to come up with tighter bounds, and I believe these are safe, though I don't have a published proof that they are. You might think that tighter bounds aren't necessary, as long as we're below 128 bits. However, tighter bounds allows us to use smaller lookup tables because we can trade bits for table size. Unfortunately, I didn't have time yet to implement that. Makes sense? -- Ulf |
Okay, thanks! |
Hi, I'm trying to implement the "step 0" for chapter 3.4 from the paper, more precisely the part where we build a lookup table for exponents less than 0. I'll make it clear that I'm not good at math and although I spent a lot of time to understand the math up to chapter 3.2, I'm not at ease with a lot of it. From Ryū: fast float-to-string conversion:
I tried that (for 64bit floating point numbers) but the values to store in the look up table seem to be more than 124 bits. So I guess I'm doing something wrong (the result for positive exponent seem to fit in 124 bit which confuses me even more). And result doesn't fit into 124 bits. What am I doing wrong ? |
@mrmixer The problem with your calculation is that you've made a couple of mistakes and you are using formulas which, although taken directly from the paper, are inconsistent with other parts of the paper and the code. I believe I can demonstrate the "right" formulas. I should first note that I'm just an amateur lurker and do not speak for Mr. Adams. I will use python3 to perform the calculation.
The 64-bit floating point exponent bias is 1023.
First, I'm going to assume that you want to perform the calculation for a very small number -
Note that if e == 0 then the decoded number will have an exponent of (1 - bias) not (e - bias) from your example.
Following the paper, we calculate ef by subtracting len(m) from the adjusted exponent. (You forgot this.)
Then we subtract 2 from ef to get e2, which is -1076 in this example.
The rest of this analysis assumes e2 < 0. Now we compute q. Here is where the paper is inconsistent and we need to consult the code (see below) to resolve this. This inconsistency is also reported in Issue 202 (no response): We incorporate aspects of the formula from the code and from section 3.4: q = max(0, ⌊-e2 * log₁₀5⌋ - 1) Lines 158 to 159 in cc41df9
Here is the final formula for q:
Now we compute k. Again, the paper is inconsistent. The code calculates it here: Lines 161 to 162 in cc41df9
So we see it is ⌈log₂ (5 ^ (-e2 - q))⌉ - B1. An inconsistent formula is given in Section 3.4 in both Step 0' and Step '3: ⌈log₂ (5 ^ q)⌉ - B1 Note that B1 is 125 in the code but it is 124 in the paper. I'm not sure why there is a difference by I doubt it is important.
Now we can calculate the multiplier: 5^(-e2 - q) / 2^k To stick with integer math, we avoid negative exponents:
Let's print the upper and lower bits and the length of the multiplier in bits:
Note that Line 364 in cc41df9
Also note that the multiplier will always have 125 bits, by design: ryu/src/main/java/info/adams/ryu/analysis/PrintDoubleLookupTable.java Lines 123 to 124 in cc41df9
So, these calculations are consistent with the code and resulted in the exact same numbers that can be found in the lookup table. So, I'm fairly confident this is the correct method, at least for e2 < 0. Here all the commands together so you can just cut and paste them all into python3:
|
@rick-masters Thanks for the reply. I can't say I remember anything from the paper, but I appreciate you taking the time to reply in case I ever want to look back at it. I ended up porting dragonbox into a single C file. |
See also issue 233. |
I noticed there are some differences in the constants from what the paper would suggest. For example,
ryu/ryu/d2s.h
Lines 40 to 41 in 5c36146
whereas the paper suggests these should both be 124 (Figure 4). Why the difference?
The text was updated successfully, but these errors were encountered: