[Insight-developers] ImageRegion bounds caching

[M Stauffer (V)]

When I include itkFloatingPointExceptionsConfigure.h in
Testing/Code/Common/itkImageRegionTest.cxx, the compiler doesn't find
it. Presumably it's because it's created by the cmake configuration
routine in the build dir, and the include paths aren't pointing there
from sources in the Testing dir. I don't know the intricacies of how the
includes are setup, but this seems the most likely reason.

So if I instead include itkFloatingPointExceptionsConfigure.h, and at
runtime use FloatingPointExceptions::GetEnabled(), it's working. I've
tried with builds both with and w/out FPE enabled, and it's working as
I'd expect. So is it safe to proceed thusly?

>-----Original Message-----
>From: Williams, Norman K [mailto:norman-k-williams at uiowa.edu] 
>Sent: Thursday, March 03, 2011 5:35 PM
>To: M Stauffer (V)
>Subject: Re: [Insight-developers] ImageRegion bounds caching
>
>#include "itkFloatingPointExceptionsConfigure.h"
>
>#ifdef ITK_USE_FPE
>....
>#endif
>
>It won't be defined unless you include the header ;-)
>
>I don't know if this was the best way to implement this, but 
>it got by all
>the evaluators on this patch in gerrit.
>
>On 3/3/11 4:18 PM, "M Stauffer (V)" <mstauff at verizon.net> wrote:
>
>>>If you start testing for NaNs, it would be good if there was a
>>>way to test
>>>for them that doesn't cause a numerical exception, if
>>>ITK_USE_FLOATINGPOINTEXCEPTIONS is turned on.
>>
>>OK, I understand better now. This is actually a problem in my Test
>>routine, because I explicitly set some test values to NaN to make sure
>>the IsInside methods returns false. I built with FPE enable and indeed
>>there is an exception generated. With FPE enabled, IsInside doesn't
>>*have* to return false for NaN since exceptions will be thrown anyway,
>>so ImageRegionTest wouldn't have to test for false being returned.s
>>
>>So I could ifdef out the code in my test when FPE is enabled. I tried,
>>but neither of these don't eval to true:
>>
>>#ifdef ITK_USE_FLOATINGPOINTEXCEPTION)
>>
>>#ifdef ITK_USE_FPE
>>
>>What should I do?
>>
>>Also ...
>>
>>>This might be tricky, because in my experience, anything you
>>>do with bad
>>>numeric values will throw an exception. In particular the case you
>>>mentioned:
>>>
>>>> ImageRegion::IsInside ContinousIndex ) does return false 
>for NaN, but
>>>> only because NaN is cast to integer which yields a massive negative
>>>> number that is out of bounds.
>>>
>>>
>>>assigning (double)NaN to an integer would throw an exception.
>>
>>Hmmm, that should have shown up before since this cast to integer was
>>already being done when I started looking at the code, and
>>ImageRegion::IsInsideBuffer is used a lot. Odd. I'll look to 
>see if that
>>throws an exception too.
>>
>>-M
>>
>>>
>>>On 3/2/11 2:05 PM, "M Stauffer (V)" <mstauff at verizon.net> wrote:
>>>
>>>>Hi,
>>>>
>>>>I think I wasn't clear. We're not trying to catch NaN exceptions or
>>>>explicitly identify NaN's. But rather we want 
>ImageRegion::IsInside to
>>>>return false when a NaN is present in the input index.
>>>>
>>>>We first saw a problem in ImageFunction::IsInsideBuffer, which was
>>>>returning true for indecies containing one or more NaN's. I
>>>submitted a
>>>>separate patch to fix it to return false when NaN's are in the input
>>>>index.
>>>>See http://review.source.kitware.com/#change,1110
>>>>
>>>>Cheers,
>>>>Michael
>>>>
>>>>>-----Original Message-----
>>>>>From: Williams, Norman K [mailto:norman-k-williams at uiowa.edu]
>>>>>Sent: Tuesday, March 01, 2011 4:47 PM
>>>>>To: M Stauffer (V); Luis Ibanez
>>>>>Cc: ITK
>>>>>Subject: Re: [Insight-developers] ImageRegion bounds caching
>>>>>
>>>>>2 things:
>>>>>
>>>>>1. Turning on numerical exceptions would have caught this.
>>>>>2. I don't know if there's a safe way to test for NaN and inf
>>>>>values with
>>>>>numeric exceptions turned on. If you're testing for them, it
>>>>>could make it
>>>>>so nothing would work with floating point exceptions turned on.
>>>>>
>>>>>On 3/1/11 2:27 PM, "M Stauffer (V)" <mstauff at verizon.net> wrote:
>>>>>>I will however add to ImageRegionTest to make sure that IsInside(
>>>>>>ContinuousIndex ) returns false for NaN and Inf values, as I did
>>>>>>recently for ImageFunction::IsInsideBuffer. Currently
>>>>>>ImageRegion::IsInside ContinousIndex ) does return false
>>>for NaN, but
>>>>>>only because NaN is cast to integer which yields a 
>massive negative
>>>>>>number that is out of bounds. The test will make sure this
>>>>>works on all
>>>>>>platforms and remains this way in the future.
>>>>>
>>>>>
>>>>>
>>>>>________________________________
>>>>>Notice: This UI Health Care e-mail (including attachments) is
>>>>>covered by the Electronic Communications Privacy Act, 18
>>>>>U.S.C. 2510-2521, is confidential and may be legally
>>>>>privileged.  If you are not the intended recipient, you are
>>>>>hereby notified that any retention, dissemination,
>>>>>distribution, or copying of this communication is strictly
>>>>>prohibited.  Please reply to the sender that you have received
>>>>>the message in error, then delete it.  Thank you.
>>>>>________________________________
>>>>
>>>>ITK_USE_FLOATINGPOINTEXCEPTIONS
>>>
>>>
>>>
>>>________________________________
>>>Notice: This UI Health Care e-mail (including attachments) is
>>>covered by the Electronic Communications Privacy Act, 18
>>>U.S.C. 2510-2521, is confidential and may be legally
>>>privileged.  If you are not the intended recipient, you are
>>>hereby notified that any retention, dissemination,
>>>distribution, or copying of this communication is strictly
>>>prohibited.  Please reply to the sender that you have received
>>>the message in error, then delete it.  Thank you.
>>>________________________________
>>
>
>
>
>________________________________
>Notice: This UI Health Care e-mail (including attachments) is 
>covered by the Electronic Communications Privacy Act, 18 
>U.S.C. 2510-2521, is confidential and may be legally 
>privileged.  If you are not the intended recipient, you are 
>hereby notified that any retention, dissemination, 
>distribution, or copying of this communication is strictly 
>prohibited.  Please reply to the sender that you have received 
>the message in error, then delete it.  Thank you.
>________________________________