<div>
Hi, me again,
</div><div><br></div><div>I am still on the integration of our code.</div><div><br></div><div>Following the links that Matt gave us on how to create external module and submit module :</div><div><a href="http://insightsoftwareconsortium.github.com/ITKBarCamp-doc/ITK/ConstructITKModule/index.html" style="color: rgb(0, 78, 185); ">http://insightsoftwareconsortium.github.com/ITKBarCamp-doc/ITK/ConstructITKModule/index.html</a></div><div><a href="http://www.itk.org/Wiki/ITK/Policy_and_Procedures_for_Adding_Remote_Modules" style="color: rgb(0, 106, 227); ">http://www.itk.org/Wiki/ITK/Policy_and_Procedures_for_Adding_Remote_Modules</a></div><div>We made two external modules:</div><div>- 1 external module containing the ITK classes that we have developed, that use Skewchuk's library and their validation tests (corresponding insight journal: <a href="http://hdl.handle.net/10380/3329">http://hdl.handle.net/10380/3329</a>).</div><div>- 1 external module containing Skewchuk's C library, with a test to validate the good behaviour of the library, as the library is not regularly tested.</div><div><br></div><div>The first module is classic ITK classes, no problems there. But the second external module is not ITK code but external code. Therefore should be, if I am not mistaken, a ThirdParty module.</div><div><br></div><div>How do we create a ThirdParty module, and what are the requirement for such module? </div><div>Is there a particular way to submit a ThirdParty module like for external module?</div><div>Well basically, how to change Skewchuk's external module into a ThirdParty module?</div><div><br></div><div>Thanks in advance and sorry for all those questions :).</div><div>--</div><div><div>Stephane</div><div><br></div></div>
<p style="color: #A0A0A8;">On Wednesday, 16 January 2013 at 10:53, ulysse wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div>
<div>
Dear Steve,
</div><div><br></div><div>Thanks for sharing your experience with Shewchuk's code.</div><div><br></div><div>When we started to use Shewchuk's code, we wrote a test to validate the robustness of the methods we were using.</div><div>Basically we define an "on the edge" case where both Shewchuk and classic method provide us with the same result.</div><div>Then we introduce an epsilon variation and test if that change Shewchuk and classic method result.</div><div><br></div><div>And we have good results as Shewchuk detect the change while classic method did not.</div><div><br></div><div>We have run this test on the several computer available to us:</div><div>- Mac Intel i5 with MacOSX 64bit and clang compiler.</div><div>- Intel Xeon W3503 with Windows 7 64bit and MVS 2008 and MVS 2012.</div><div>- Intel Core duo with Linux 32bit or windows XP 32bit and gcc compiler and MVS 2008.</div><div><br></div><div>All of them return good results on our test, no warning, error or any other change of behaviour. </div><div><br></div><div>Like Alex said, this does not insure us that their is no hidden problem. So we are welcoming any idea that could help us to improve the testing of Shewchuk's code and its integration.</div><div><br></div><div>Thanks in advance for your time :).</div><div><br></div><div><div>-- </div><div>Stephane.</div><div><br></div></div>
<p style="color: #A0A0A8;">On Monday, 31 December 2012 at 12:35, Steve M. Robbins wrote:</p><blockquote type="cite"><div>
<span><div><div><div>Hi Alex,</div><div><br></div><div>Apologies for the big delay in responding -- real life got in the way (birth </div><div>of second daughter).</div><div><br></div><div>So my memory of Shewchuk's code -- and this goes back to 2001, so it may be </div><div>faulty -- is that the code requires the floating point calculations to strictly </div><div>adhere to IEEE arithmetic in round-to-even mode. I ran into two problems: the </div><div>x86 machines extended precision, and the rounding mode.</div><div><br></div><div>The x86 machines used extended precision by default, which I had to disable in </div><div>my code prior to using Shechuk's predicates. Disabling extended precision </div><div>used platform-dependent system calls; I don't recall all the details and </div><div>eventually I used the GNU Scientific Library (GSL) method gsl_ieee_set_mode() </div><div>to hide the system variations. The other issue with this is that if you </div><div>change the IEEE mode, other system functions -- e.g. math library functions </div><div>like sin(), cos(), exp() -- may fail to work because they were coded assuming </div><div>extended precision. Or worse: calling sin() will turn on extended precision, </div><div>do the calculation and leave the system in extended precision. You might </div><div>consider wrapping your predicates in code that saves the floating point mode, </div><div>sets it for the calculation, then restores to the initial value. However, I </div><div>seem to recall that setting the IEEE mode took a non-trivial amount of time.</div><div><br></div><div>The second problem is similar: some machines I was using did not use "round-</div><div>to-even" as the default. I was using Pentium III running linux and SGI MIPS </div><div>machines (R10k, R12k) running IRIX. I think it may have been the latter. In </div><div>fact, I think the MIPS compiler by default did not obey all IEEE rules and I </div><div>had to use special compiler options to force strict IEEE compliance. A </div><div>portable library would have to ensure the correct rounding mode and possibly </div><div>restore it after the computation was done.</div><div><br></div><div>A possible third issue involves the IEEE fault handling. My initialization </div><div>code disables faults for denormalized numbers and for underflow. </div><div>Unfortunately, I can't recall for sure whether this was an issue for the </div><div>Shewchuk code or for something else.</div><div><br></div><div>And finally, if necessary, one has to be sure the code is built with options to </div><div>ensure strict IEEE compliance.</div><div><br></div><div>As noted, my experience was in 2001 and I have no idea whether any of this is </div><div>an issue with today's hardware.</div><div><br></div><div><br></div><div><br></div><div>On November 13, 2012 10:42:47 PM Alexandre GOUAILLARD wrote:</div><blockquote type="cite"><div><div>Dear steve,</div><div><br></div><div>That's a very good point.</div><div><br></div><div>Yes, we saw the warning. We have implemented a very simple test for the</div><div>robustness, which actually test both normal ITK, and the new code with 4</div><div>points lying on circle, and adding an arbitrary small number to the 4th</div><div>point coordinate, and we could not find a platform where this was a</div><div>problem. We tried linux with gcc 4.2, mac with both gcc and clang, and</div><div>windows (xp, 7) with MSVC 2005, 2008 and 2010.</div><div><br></div><div>Now, that does not mean there is no problem. </div></div></blockquote><div><br></div><div>Agreed: I would not find this convincing enough to bet my exact computation </div><div>results on it :-)</div><div><br></div><div>Regards,</div><div>-Steve</div></div></div></span>
</div></blockquote><div>
<br>
</div>
</div></div></span>
</blockquote>
<div>
<br>
</div>