Re: Default Floating Point Format Specifiers

[Paige DePol <lual@...>]

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

> On Thu, Jul 03, 2014 at 01:36:06PM -0500, Paige DePol wrote:
>> On Jul 3, 2014, at 6:09 AM, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:
>> 
>>>> The problem, according to the IEEE floating point entries on Wikipedia, is that there are not enough digits specified.
>>> 
>>> This is on purpose so that numbers appear right for the casual user:
>>> 
>>>> a=0.1
>>>> =a
>>>    0.1
>>>> =string.format("%.17g",a)
>>>    0.10000000000000001
>>> 
>>> We don't want needless noise when using print (and other automatic
>>> conversions via tostring). If you need round-trip strings, then use
>>> string.format.
>> 
>> Ah, well that is a great reason to not specify larger format specifiers, I
>> didn't realise 0.1 would turn into 0.10000000000000001 with a larger
>> specifier. When I was reading about specifier digits I did not find any
>> information on this side-effect.
> <snip>
> 
> I assumed you already understood that part of the issue considering the
> examples you originally provided.

Somehow I missed it, or it just didn't sink in. Was having a serious bout of heartburn in the middle of the night so may not have quite been taking in as much as I normally would. ;(

Well, actually looking at the examples I provided originally I was commenting about the "%.14g" specifier rounding off -1.00000000000001 to -1.0, not that 0.1 would turn into 0.10000000000000001. Different sides of the same coin, I guess! 


> Round-tripping _within_ a single application is straight forward, at least
> theoretically. (Presuming, as Luiz pointed out, that's what you actually
> want to accomplish.) But then there are a bunch of other issues if the
> strings you generate are released into the wild. It's kind of a headache for
> things like JSON, as well. It's relatively safe to assume binary64 IEEE754
> these days (especially since it's the standard in JavaScript), but you can't
> always assume that the library routines used to parse the numbers do the
> expected thing.

I think reasons like this are why I will simply pass through the original characters used to specify the numbers instead of round-tripping them.


> The latest version of Visual Studio (14 STP) actually supports
> DBL_DECIMAL_DIG (from C11), but they also changed the behavior of the printf
> and strtod, which suggests to me that their old versions were probably a
> source of interoperability headaches, even regarding regular decimal
> conversions.
> 
> See http://blogs.msdn.com/b/vcblog/archive/2014/06/18/crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1.aspx
> 
> I think until hexidecimal floats are widely supported you just have to be
> conservative about what kind of precision you can expect when round-tripping
> floats.
> 
> Maybe it's not as much of an issue as I think it is. It would be a cool
> project, though, to document all the various behaviors across platforms,
> versions, and languages. You'd probably get serious linkage from Stack
> Overflow and other technical sites.

I think someone else other than me would need to document all that... but you are right, they probably would get some serious linkage back from Stack Overflow!

Thank you again, William and Luiz, for your feedback on my post, it has cleared some things up for me! :)

~pmd