On Mon, Aug 26, 2013 at 1:47 PM, Florian Weimer <[email protected]> wrote:
> * Jonathan S. Shapiro: > > >> The two floating point values have the IEEE representation > >> 3FEFFFFFFFFFFFFD and 3FEFFFFFFFFFFFFE. > > > OK. Let's work the example. Please start by telling me which > > floating point values you are using, and which representation you > > are using when you give me these hex values. > > These are double-precision IEEE binary floating-point values. As it > is customary when writing down numbers, the most significant bit comes > first. > That makes sense, but there is no universal convention about the ordering of exponent, sign, and mantissa when a raw hex number is written. > > > Different hardware places the mantissa and sign in > > different positions, so what I'm asking is which bits of your hex > > representation are the exponent, sign, and mantissa. > > 1 sign bit, 11 bits exponent (using a biased encoding), and 52 bits of > mantissa, excluding the implicit leading one bit. > Yes. But in what order are these being concatenated to form a bit string before conversion to hex? And what were the *original* numbers (written in decimal form)? > > > Also, could you please stop complicating the exponents? Mixing bases > > and putting arithmetic in the exponents is just making things > > obfuscated. > > That's due to the biased exponent encoding. > Which is exactly why you shouldn't write them that way. Just write the intended exponent of the number you are trying to represent. I understand how the biasing process works. Or if you are going to write them that way, a stepwise explanation of your intent would make things clearer. > > I don't have time to re-derive the formal proof of correctness for > > precision. It's been done several times, and it's published in the > > literature. The bottom line is that if you require K bits of > > precision, and you have k+3 bits of precision (which my method > > *does* have), you have more than enough bits to round correctly, and > > that's all you need. > > I think the problem is that you need 170-odds bits of precision just > to tell the inputs apart, not only 53 bits. > > Michel Hack, "On Intermediate Precision Required for > Correctly-Rounding Decimal-to-Binary Floating-Point Conversion" gives > a recipe for constructing a much, much longer decimal input number. I'll read the paper later this afternoon. In the meantime, you should perhaps look at the following paper by Will Clinger: "How to Read Floating Point Numbers Accuraetly" http://www.cesura17.net/~will/Professional/Research/Papers/howtoread.pdf In particular, note that IEEE does not require that the result of input conversion be the best approximation. Depending on your point of view, that's either a hole in the IEEE spec or a hole in any given language spec. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
