[vtk-developers] Call for Comments: Ascii representation of floats and doubles in files

[Bill Lorensen]

I'm having problems on a Windows platform. I'll be asking for help.

The ThirdParty stuff is tricky since not all ThirdParty packages
follow the recommended way.

Bill

On Wed, Mar 28, 2018 at 5:19 PM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> Funny coincidence, I just got bit but this double-string precision
> problem in a ParaView issue [1]. Looks forward to having this library
> in VTK so we can use it. Bill, if you need help with the 3rd party
> stuff, just holler.
>
> Utkarsh
>
>
> [1] https://gitlab.kitware.com/paraview/paraview/issues/18083
>
> On Wed, Mar 21, 2018 at 8:10 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> I'm still working in the MR. It works great but I'm having cmake issues on
>> Windows. Adding a new third party library is tricky.
>>
>> On Mar 21, 2018 2:08 PM, "Isaiah Norton" <isaiah.norton at gmail.com> wrote:
>>>
>>> +1. I needed this recently in Slicer, and ended up using ITK's version
>>> because we link it anyway.
>>>
>>>>
>>>> Not sure if we need to add a new third-party library for this, though,
>>>> especially one that duplicates so much of C++'s built-in machinery.
>>>
>>>
>>>  Grisu3 (double-conversion) appears to be ~13x faster than the C++ stream
>>> functions (and 6x faster than sprintf):
>>>
>>>   https://github.com/miloyip/dtoa-benchmark
>>>
>>> Those numbers are on VS2013/Windows, but that code is easy to build
>>> locally. The sprintf vs double-conversion conclusion holds on 2015 macbook
>>> with 10.12 SDK. The C++ stream functionality is somewhat closer to sprintf.
>>>
>>> [usual benchmark NaCl disclaimer here]
>>>
>>> On Thu, Mar 1, 2018 at 11:32 AM, David Gobbi <david.gobbi at gmail.com>
>>> wrote:
>>>>
>>>> I agree that floats should be printed so that conversion is lossless.
>>>> Python's console output does this and I find it incredibly useful.
>>>>
>>>> Not sure if we need to add a new third-party library for this, though,
>>>> especially one that duplicates so much of C++'s built-in machinery.
>>>> Isn't it just a matter of printing enough digits?  That's basically what
>>>> I do in my own code (plus checks for isnan(x) and isinf(x), and a
>>>> check of the size of fabs(x) for whether to force scientific notation.)
>>>>
>>>>  - David
>>>>
>>>>
>>>> On Thu, Mar 1, 2018 at 8:48 AM, Bill Lorensen <bill.lorensen at gmail.com>
>>>> wrote:
>>>>>
>>>>> Will,
>>>>>
>>>>> It would go in Common/Core I think. The vtk class would be very small.
>>>>>
>>>>> Bill
>>>>>
>>>>> On Thu, Mar 1, 2018 at 7:36 AM, Will Schroeder
>>>>> <will.schroeder at kitware.com> wrote:
>>>>> > If it works why mess with success? Where would this class
>>>>> > (vtkNumberToString) be placed, in Common/Core (like vtkIndent) or in
>>>>> > some IO
>>>>> > directory like VTK/IO/Core?
>>>>> >
>>>>> > On Thu, Mar 1, 2018 at 10:06 AM, Bill Lorensen
>>>>> > <bill.lorensen at gmail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> Folks,
>>>>> >>
>>>>> >> I'm working on some examples to save/restore camera, polydata,
>>>>> >> property, etc. in XML files. The files can be saved as binary or
>>>>> >> ascii. If I save/restore the info in binary, I get the same values
>>>>> >> for
>>>>> >> the saved info. But, to no surprise, when I save the same data in
>>>>> >> ascii, I don't get the same values. This is because the file writing
>>>>> >> code does not write enough significant digits.
>>>>> >>
>>>>> >> In ITK we solved this problem many years ago. ITK uses a reduced
>>>>> >> version of the Google double-conversion library,
>>>>> >> https://github.com/google/double-conversion.
>>>>> >>
>>>>> >> We added a small class to ITK that uses the library. The class,
>>>>> >> itkNumberToString, has a simple API. To convert floating and fixed
>>>>> >> point numbers to ascii without numerical precision erros,
>>>>> >>
>>>>> >> For example, to convert a float,
>>>>> >> #include "itkNumberToString.h:
>>>>> >> itk::NumberToString<float> convert;
>>>>> >> float a = 1.0f/3.0f;
>>>>> >> std::cout << convert(a) << std::endl;
>>>>> >>
>>>>> >> I propose a similar approach in VTK.
>>>>> >>
>>>>> >> Comments please,
>>>>> >>
>>>>> >> Bill
>>>>
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> https://vtk.org/mailman/listinfo/vtk-developers
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> https://vtk.org/mailman/listinfo/vtk-developers
>>
>>



-- 
Unpaid intern in BillsParadise at noware dot com