<div dir="ltr"><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.<br>
<br><div class="gmail_quote">On Fri, Dec 8, 2017 at 1:08 PM, Marcus D. Hanwell <span dir="ltr"><<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">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:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="font-family:monospace"><span style="color:rgb(0,0,0)">void vtkAxis::GenerateLabelFormat(<wbr>int notation, double n)
</span><br>{<br></span></div><div class="gmail_extra"><span style="font-family:monospace"><span style="color:rgb(0,0,0)"> std::ostringstream ostr;
</span><br> ostr.imbue(std::locale::<wbr>classic());</span></div><div class="gmail_extra"><span style="font-family:monospace"> <br></span>
<span style="font-family:monospace"><span style="color:rgb(0,0,0)"> switch(notation)
</span><br> {
<br> case 1:
<br> ostr << n;
<br> ostr.precision(this-><wbr>Precision);
<br> ostr.setf(std::ios::<wbr>scientific, std::ios::floatfield);
<br> this->TickLabels-><wbr>InsertNextValue(ostr.str());
<br> break;</span></div><div class="gmail_extra"><font face="monospace">...</font></div><div class="gmail_extra"><span style="font-family:monospace"><br></span></div><div class="gmail_extra">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.<span style="font-family:monospace"><br></span></div><div><div class="h5"><div class="gmail_extra"><span style="font-family:monospace"><br></span><div class="gmail_quote">On Fri, Dec 8, 2017 at 12:58 PM, Jeff Baumes <span dir="ltr"><<a href="mailto:jeff.baumes@kitware.com" target="_blank">jeff.baumes@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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):<div><br></div><div><a href="https://superuser.com/questions/969078/how-can-i-change-number-format-in-my-pc-windows-8" target="_blank">https://superuser.com/question<wbr>s/969078/how-can-i-change-<wbr>number-format-in-my-pc-windows<wbr>-8</a><br></div></div><br><div class="gmail_quote"><div><div class="m_-8182801099927534492gmail-h5"><div dir="ltr">On Fri, Dec 8, 2017 at 12:49 PM Marcus D. Hanwell <<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="m_-8182801099927534492gmail-h5"><div dir="ltr">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:<div><br></div><div><a href="https://open.cdash.org/testDetails.php?test=607700533&build=5173639" target="_blank">https://open.cdash.org/testDet<wbr>ails.php?test=607700533&build=<wbr>5173639</a><br></div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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 :-)</div></div></div></div>
______________________________<wbr>_________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensou<wbr>rce/opensource.html</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=<wbr>vtk-developers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mail<wbr>man/listinfo/vtk-developers</a><br>
<br>
</blockquote></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>