On Mon, Aug 12, 2013 at 11:55 AM, Florian Weimer <[email protected]> wrote:
> * Jonathan S. Shapiro: > > > Base conversion is definitely complicated, but I'm pretty sure you have > > your conversions wrong below. First, your output values don't match what > C# > > is getting, > > It's quite common that the conversion in the opposite direction rounds > away some information because 0.1 + 0.2 = 0.30000000000000004 leads to > bug reports. Perhaps C# does this as well? > Depends on the output printing mode, but I was paying attention to that, so I used a third-party class that prints the representations precisely. > > so can you say how you produced them? > > I wrote a Python script to find this counterexample. > I'm sure there are bugs in my current quick-and-dirty implementation, but I'd suspect the Python string->double conversion code before I'd suspect a conceptual error. > > Second, a 64-bit single-precision unsigned integer has far more precision > > than a 64-bit double precision float. > > But apparently not enough. Sorry; that's just not true. A double precision float effectively has a 53 bit significand (52-bits plus an implicit "1" in the most significant bit position). Though IEEE doesn't specify how rounding modes apply to string->double conversion, even the obscure IEEE rounding modes can be done with an additional 3 bits of internal precision. So yes, a 64-bit unsigned integer really *does* have enough bits. I've looked at several really good implementations of string->double and double->string conversions, including one by Jonathan Rees, who is both knowledgeable about the underlying numerical analysis issues and obsessive about this kind of accuracy. Use of a 64-bit unsigned for this conversion is more or less the standard approach. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
