lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Jul 2, 2014, at 8:29 PM, William Ahern <william@25thandClement.com> wrote:

> On Wed, Jul 02, 2014 at 04:06:08PM -0500, Paige DePol wrote:
>> However, there is one issue that appears to be Lua based, the default
>> floating point format specifiers.
>> 
>> By default we have these defines for float, double and long double:
>> 
>> float:	%.7g
>> double:	%.14g
>> lngdbl:	%.19Lg
>> 
>> The problem, according to the IEEE floating point entries on Wikipedia, is
>> that there are not enough digits specified. As per the Wikipedia articles
>> the number of significant digits are as follows:
>> 
>> float:	6-9 
>> double:	15-17
>> 80bit:	18-21 (probably `long double` for most people)
>> 128bit:	33-36 (`long double` for SPARC, PowerPC, Itanium)
> <snip>
>>> From what I have been able to find online these should be the proper format specifiers to display any numbers of the relevant data type:
>> 
>> float:	%.8f
>> double:	%.16f
>> 80bit:	%.20Lf
>> 128bit:	%.35Lf
>> 
> 
> I believe the portable way to do this is to use DBL_DECIMAL_DIG, like
> 
> 	printf("%.*g", DBL_DECIMAL_DIG, n);
> 
> although it may be more complicated than that.
> 
> However, DBL_DECIMAL_DIG was only added in C11. C99 has DECIMAL_DIG, which
> is the maximum number of decimal digits needed to round-trip the largest
> supported floating point type.
> 
> The * precision placeholder was added in C99.

For my preprocessor I think I am just going to follow how Luiz does it in his `lstrip` program and just dump out the original string used to parse the number instead of dumping out the converted number itself. This removes any issues with precision loss via the format specifier, so thank you Luiz for sharing your code!

Also, it looks like the format specifiers I gave previously were all off by one... sorry!

float:	%.9f
double:	%.17f
80bit:	%.21Lf
128bit:	%.36Lf

From what I can find online these should be the minimum specifiers for all digits to survive a round-trip conversion of the number, though really it depends a lot on the platforms implementation of floating point numbers. Thanks for the information William, you gave me a great starting point for understanding this issue! :)

~pmd