[Insight-users] Code integration and code design - Question

[Matt McCormick]

Hi Stephane,

Great to hear you are making progress.

The Module Group directory, "ThirdParty", "Segmentation", "Remote",
"External", etc. is for organization purposes, and Modules can be
moved around without effecting a build.  Therefore, even if a Module
would eventually land in the "ThirdParty" group, it can live in
"Remote" or "External" without an problem.

The next steps may be to submit new articles to the Insight Journal.
Xiaoxiao Liu (in CC) is currently working on updates to the Insight
Journal submission process to make it easier to accept Modules and get
them tested.  Coordination with her would be excellent.

Then, the submit a patch for the Remote Module.

  http://www.itk.org/Wiki/ITK/Policy_and_Procedures_for_Adding_Remote_Modules

More information on patch submission can also be found here:

  http://insightsoftwareconsortium.github.com/ITKBarCamp-doc/CommunitySoftwareProcess/SubmitAPatchToGerrit/index.html

Thanks,
Matt


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