[Insight-developers] ImageRegion bounds caching

[M Stauffer (V)]

>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.
>________________________________