[Insight-developers] itkImageConstIteratorWithIndex.h
Joshua Cates
cates@sci.utah.edu
Wed, 30 Apr 2003 10:46:16 -0600 (MDT)
Hi
I've been out for a few days so let me know if any of this was resolved in
the TCON. I will likely need to change documentation in the Software
Guide.
For those not as familiar with the iterators, here is a current breakdown
of how different iterators define Begin and End positions:
A = first valid pixel in the region
B = one before the first valid pixel in the region
C = last valid pixel in the region
D = one after the last valid pixel in the region
E = cannot be determined on initialization
No = not implemented
Parent class IsAtBegin() GoToBegin() IsAtEnd() GoToEnd()
1.ImageRegionConstIterator A A D D
2.ConstNeighborhoodIterator A A D D
3.RandomConstIteratorWithIndex A A D D
4.ImageConstIteratorWithIndex B A D C
5.ConditionalIterator No No E No
1-3 are modeled on STL forward iterators. They all define operator--,
however, so they can also be used as reverse iterators through the
slightly funkier syntax Jim described in an earlier email. 3 has random
Begin and End positions, but can be used forward/reverse exactly as 1-2.
4 are modeled simultaneously on both STL forward and reverse iterators.
Each has two different definitions of Begin and End depending on the
context in which it is used.
To avoid confusion among users and developers, I think we should
standardize the meaning of Begin and End as defined in 1-3 and add
ReverseEnd and ReverseBegin concepts to iterators that want them. I think
this can be done without any code modification by adding "Reverse" to the
name of two methods:
In all 4-based iterators:
GoToEnd() becomes GoToReverseBegin()
IsAtBegin() becomes IsAtReverseEnd().
These changes won't break any existing forward iteration code and would
keep forward iteration syntax consistent across all ITK iterators. I
don't think any implemenational modifications are required and no
functionality is lost or gained.
One more issue remains: With 1-3 it is safe to iterate forward and
backward in the same loop. I do not know if the implementation of all
4-based iterators supports this. If not, we should document clearly.
Josh.
______________________________
Josh Cates
School of Computer Science
University of Utah
Email: cates@sci.utah.edu
Phone: (801) 587-7697
URL: http://www.sci.utah.edu/~cates
On Wed, 23 Apr 2003, Luis Ibanez wrote:
>
> 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
> >
> >
> >
>
>
>
>
>