[Insight-developers] itkImageConstIteratorWithIndex.h

Mark Foskey mark_foskey@unc.edu
Thu, 24 Apr 2003 10:27:48 -0400


Ah, my ignorance of the details of ITK iterators becomes more apparent.

Most iterator types don't currently have Reverse versions.  It seems to 
me that they all should, except for those where a strong case can be 
made that one isn't necessary.  But doing that would increast the 
number of iterator classes greatly.

On the other hand, the design should be consistent.  If you buy that, 
and you still don't want to write a bunch more reverse iterators, and 
you also want graceful reverse iteration, then they should all work 
something like itkImageConstIteratorWithIndex, perhaps with a 
PixelsRemaining() method.

Miller, James V (Research) wrote:
> I guess getting up at 4am has started to get to me because
> I don't really see the issue.  In the ImageConstIterator and
> ImageReverseConstIterator, the definitions/implementations are:
> 
> IsAtBegin() - Am I at the first pixel?
> IsAtEnd() - Am I one past the last pixel?

But still,

> 
> Both of these implementations are based on whether the current
> "pointer" position is at the first pixel in the region or 
> at the last pixel in the region.
> 
> It is tricky to use the ImageConstIterator to walk backwards
> through a region because of these definitions. You end 
> doing things like
> 
> it.GoToEnd();
> do 
> {
> --it;
> 
> // do something with this pixel
> } while (!it.IsAtBegin());
> 
> This is a little klunky.  That is why there is an 
> ImageReverseConstIterator.
> 
> it.GoToBegin();
> while ( !it.IsAtEnd() )
> {
>   // do something
> 
>   ++it;
> }
> 
> 
> 
> 
> 
>>-----Original Message-----
>>From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
>>Sent: Thursday, April 24, 2003 9:27 AM
>>To: Miller, James V (Research)
>>Cc: Mark Foskey; Joshua Cates; insight-developers@public.kitware.com
>>Subject: Re: [Insight-developers] itkImageConstIteratorWithIndex.h
>>
>>
>>
>>Not really,
>>
>>Since the purpose of these methods is to control
>>the iterator's loops, both IsAtBegin() and IsAtEnd()
>>should return past-the-end conditions.  That is:
>>
>>IsAtBegin() should return = I'm before the begin
>>ItAtEnd()   should return = I'm past the end
>>
>>Just like the STL "end()" method.
>>Unless we agree in not using these methods for
>>controling loops anymore, and rely instead on a
>>new method : bool PixelsRemaining() const
>>
>>However,... once we stop using IsAtBegin() and
>>IsAtEnd() for controling loops... I don't see
>>much use for these methods.
>>
>>
>>    Luis
>>
>>
>>---------------------------------
>>Miller, James V (Research) wrote:
>>
>>>Luis,
>>>
>>>I think the IsAtBegin() and IsAtEnd() methods should always be able
>>>to answer the questions of whether the iterator is at the 
>>
>>first pixel
>>
>>>or one past the last pixel. 
>>>
>>>Couldn't the implementations of these methods be 
>>>
>>>  /** Is the iterator at the beginning of the region? 
>>
>>"Begin" is defined
>>
>>>   * as the first pixel in the region. */  
>>>  bool IsAtBegin(void) const
>>>    {
>>>    return (m_Position == m_Begin);
>>>    }
>>>
>>>  /** Is the iterator at the end of the region? "End" is 
>>
>>defined as one
>>
>>>   * pixel past the last pixel of the region. */
>>>  bool IsAtEnd(void) const
>>>    {
>>>    return (m_Position == m_End);
>>>    }
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
>>>>Sent: Wednesday, April 23, 2003 8:41 PM
>>>>To: Mark Foskey
>>>>Cc: Joshua Cates; Miller, James V (Research);
>>>>insight-developers@public.kitware.com
>>>>Subject: Re: [Insight-developers] itkImageConstIteratorWithIndex.h
>>>>
>>>>
>>>>
>>>>Hi
>>>>
>>>>The current behavior of IsAtBegin() and ItAtEnd() is
>>>>the right one. It shouldn't be changed. The issue is
>>>>just to document their behavior.
>>>>
>>>>----
>>>>
>>>>These two methods are intended to be the stopping conditions
>>>>of while loops.
>>>>
>>>>IsAtBegin() is only used when the iterator is use as a
>>>>reverse iterator like
>>>>
>>>>
>>>>   it.GoToEnd()
>>>>   while( !it.IsAtBegin() )
>>>>     {
>>>>     // do something here
>>>>     --it;
>>>>     }
>>>>
>>>>IsAtBegin() is not intended to be called in forward iteration.
>>>>
>>>>Same thing with IsAtEnd(), this method is not intended to be
>>>>called after GoToEnd() but rahter after GoToBegin(). Like in
>>>>the classical loop:
>>>>
>>>>
>>>>   it.GoToBegin()
>>>>   while( !it.IsAtEnd() )
>>>>     {
>>>>     // do something here
>>>>     ++it;
>>>>     }
>>>>
>>>>The two methods are just returning if there are still some
>>>>pixels to be visited, not really if the iterator is at the
>>>>end position.
>>>>
>>>>We could as well rename both methods as:
>>>>
>>>>        it.PixelsRemaining()
>>>>
>>>>then,
>>>>both loops will look similar:
>>>>
>>>>
>>>>   it.GoToBegin()
>>>>   while( it.PixelsRemaining() )
>>>>     {
>>>>     // do something here
>>>>     ++it;
>>>>     }
>>>>
>>>>and
>>>>
>>>>
>>>>
>>>>   it.GoToEnd()
>>>>   while( it.PixelsRemaining() )
>>>>     {
>>>>     // do something here
>>>>     --it;
>>>>     }
>>>>
>>>>
>>>>
>>>>
>>>>   Luis
>>>>
>>>>
>>>>
>>>>------------------
>>>>
>>>>Mark Foskey wrote:
>>>>
>>>>>OK, I will investigate.
>>>>>
>>>>>Joshua Cates wrote:
>>>>>
>>>>>
>>>>>>I agree.  This sounds like a bug to me.
>>>>>>
>>>>>>Josh.
>>>>>>
>>>>>>
>>>>>>On Wed, 23 Apr 2003, Miller, James V (Research) wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I think your examples should both print 1.
>>>>>>>
>>>>>>>So if possible (without breaking existing code), I would 
>>>>>>
>>>>change the
>>>>
>>>>>>>code. A
>>>>>>>call to IsAtBegin() should return true if it is called 
>>>>>>
>>>>immediately
>>>>
>>>>>>>after a
>>>>>>>GoToBegin(). Same for "end" versions.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: Mark Foskey [mailto:mark_foskey@unc.edu]
>>>>>>>>Sent: Wednesday, April 23, 2003 12:12 PM
>>>>>>>>To: insight-developers@public.kitware.com
>>>>>>>>Subject: [Insight-developers] itkImageConstIteratorWithIndex.h
>>>>>>>>
>>>>>>>>
>>>>>>>>In itkImageConstIteratorWithIndex.h, both IsAtBegin() 
>>>>>>>
>>>>and IsAtEnd()
>>>>
>>>>>>>>return !m_Remaining.  It appears that
>>>>>>>>
>>>>>>>>  it.GoToBegin();
>>>>>>>>  std::cout << it.IsAtBegin() << std::endl;
>>>>>>>>
>>>>>>>>  it.GoToEnd();
>>>>>>>>  std::cout << it.IsAtEnd() << std::endl;
>>>>>>>>
>>>>>>>>will both print 0.  Do we at least want to document 
>>>>>>>
>>>>this behavior?
>>>>
>>>>>>>>I can imagine scenarios where you might want to test 
>>>>>>>
>>whether an
>>
>>>>>>>>iterator has been incremented since GoToBegin() was 
>>>>>>>
>>>>called, although
>>>>
>>>>>>>>I think they would be rare.
>>>>>>>>
>>>>>>>>--
>>>>>>>>Mark Foskey    (919) 843-5436  Computer-Aided Diagnosis and 
>>>>>>>
>>>>Display Lab
>>>>
>>>>>>>>mark_foskey@unc.edu            Department of Radiology, 
>>>>>>>
>>>>CB 7515, UNC
>>>>
>>>>>>>>http://www.cs.unc.edu/~foskey  Chapel Hill, NC  27599-7515
>>>>>>>>
>>>>>>>>_______________________________________________
>>>>>>>>Insight-developers mailing list
>>>>>>>>Insight-developers@public.kitware.com
>>>>>>>>http://public.kitware.com/mailman/listinfo/insight-developers
>>>>>>>>
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>Insight-developers mailing list
>>>>>>>Insight-developers@public.kitware.com
>>>>>>>http://public.kitware.com/mailman/listinfo/insight-developers
>>>>>>>
>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>Insight-developers mailing list
>>>>>>Insight-developers@public.kitware.com
>>>>>>http://public.kitware.com/mailman/listinfo/insight-developers
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>_______________________________________________
>>>Insight-developers mailing list
>>>Insight-developers@public.kitware.com
>>>http://public.kitware.com/mailman/listinfo/insight-developers
>>>
>>
>>
>>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers


-- 
Mark Foskey    (919) 843-5436  Computer-Aided Diagnosis and Display Lab
mark_foskey@unc.edu            Department of Radiology, CB 7515, UNC
http://www.cs.unc.edu/~foskey  Chapel Hill, NC  27599-7515