[vtk-developers] Image based axis test passing despite failure (Windows bug with label precision)

[Marcus D. Hanwell]

Not making any promises on when (or if) I can get to this, but I opened
https://gitlab.kitware.com/vtk/vtk/issues/17201 to track the issues I
brought up (the bug, and the non-failure of a test that looks like it
should fail). Hopefully the search engines connect the pieces in the future
should anyone hit a similar issue.

On Fri, Dec 8, 2017 at 2:05 PM, Marcus D. Hanwell <
marcus.hanwell at kitware.com> wrote:

> So, I built the simplest Visual Studio project, and it would appear that
> there is a bug in their STL implementation for ostringstream, setting
> precision to a non-zero value works as expected, but if you attempt to use
> scientific notation with a precision of 0 it uses 6! It works as expected
> with fixed notation.
>
> The pragmatic solution for Tomviz is to use 1 decimal place I think in
> this case. I am not sure how much value there is in adding custom code,
> this seems to be a bug across a number of Visual Studio versions. A simple
> Google didn't turn up any useful workarounds, maybe my Google skills are
> failing me today.
>
>
> On Fri, Dec 8, 2017 at 1:08 PM, Marcus D. Hanwell <
> marcus.hanwell at kitware.com> wrote:
>
>> I think we already clobber a lot of it by setting the numeric locale to
>> C, and there is code in the axes that is careful to avoid localized number
>> strings:
>>
>> void vtkAxis::GenerateLabelFormat(int notation, double n)
>> {
>>  std::ostringstream ostr;
>>  ostr.imbue(std::locale::classic());
>>
>>  switch(notation)
>>  {
>>    case 1:
>>      ostr << n;
>>      ostr.precision(this->Precision);
>>      ostr.setf(std::ios::scientific, std::ios::floatfield);
>>      this->TickLabels->InsertNextValue(ostr.str());
>>      break;
>> ...
>>
>> I can try tweaking some of this now I have a failing test at least. I
>> thought the image regression would have been sensitive enough to catch it.
>>
>> On Fri, Dec 8, 2017 at 12:58 PM, Jeff Baumes <jeff.baumes at kitware.com>
>> wrote:
>>
>>> Don't know about the image non-failure, but I've seen these settings
>>> interfere with how numbers are formatted across Windows applications (e.g.
>>> I think these settings affect how CSVs are exported from Excel for example):
>>>
>>> https://superuser.com/questions/969078/how-can-i-change-numb
>>> er-format-in-my-pc-windows-8
>>>
>>> On Fri, Dec 8, 2017 at 12:49 PM Marcus D. Hanwell <
>>> marcus.hanwell at kitware.com> wrote:
>>>
>>>> I had been meaning to look into this for a while, we have an issue on
>>>> Windows with chart axes displaying way too many decimal places using
>>>> scientific notation and set precision. I have confirmed on the dashboard
>>>> that this does in fact happen with the TestAxes test:
>>>>
>>>> https://open.cdash.org/testDetails.php?test=607700533&build=5173639
>>>>
>>>> I made the axis next to it invisible, so it begs the question of why
>>>> this was passing on Windows as I only see one baseline, and it looks
>>>> correct. Perhaps the test image is too crowded, and the fuzzing for the
>>>> image let it through unnoticed all this time?
>>>>
>>>> This is using the standard library calls to generate the labels, so
>>>> guessing this is a bug/feature in the Windows STL, I will dig into this but
>>>> wanted to point this passing failure out in case anyone had ideas on how it
>>>> might be prevented in the future.
>>>>
>>>> I noticed because we use this in Tomviz, and on Windows users
>>>> complained about us using 10 decimal places, asking for a more reasonable
>>>> number :-)
>>>> _______________________________________________
>>>> 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:
>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20171213/a4edabe1/attachment.html>