[ImageJ-devel] [fiji-devel] RE: Simplifying loops?

Stephan Saalfeld saalfeld at mpi-cbg.de
Wed Jun 16 13:46:54 CDT 2010


Hi Aivar,

don't take me too literal, that code was just a crazy example :).  I
fully agree about not lumping together different kinds of exceptions.
Cursor.getType() (it will BTW be renamed to Cursor.type() because it is
not a getter) may or may not throw an Exception when out of bounds.  In
case it does, an appropriate exception is NoSuchElementException that is
thrown by Iterator.  Currently, it does not but it should.  Keep also in
mind, that this exception is by no means a sign for Cursors being out of
bounds.  Cursors with an OutOfBoundsStrategy will very well return a
Type there and not throw such Exception.

I am not deprecating the idea that Cursors are Iterators, why do you
think that?  They are Iterators for convenient loop constructs and
scripting language bindings.  In addition to Iterators, they can also
move without asking for a value which is sometimes desired.

Best,
Stephan


On Wed, 2010-06-16 at 13:16 -0500, Aivar Grislis wrote:
> Cursor<T>  c;
> try {
>      for (;;c.fwd()){
>          // meat of the loop
> }
> catch (Exception e){}
> 
> Using Exceptions for normal program flow might be considered bad Java form, also lumping together IndexOutOfBounds and NoSuchElementException by just catching the general Exception (because it could actually be some other kind of Exception happening).
> 
> Cursor.getType() could return null when out of bounds (a possibility Brian mentioned).  Cursor.next() would return null also, since you're deprecating the idea of Cursor being an Iterator, it doesn't have to throw that NoSuchElementException.
> 
> (You could check for the null to break out of the loop or the code above would still work, at the expense of having two exceptions: e.g. IndexOutOfBounds caught within Cursor and NullPointerException caught here).
> 
> Aivar
> 
> 
> On 6/16/10 4:29 AM, Stephan Saalfeld wrote:
> > http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=imglib.git;a=blob;f=mpicbg/imglib/cursor/CursorImpl.java;h=6bafb73226e2b0cb90289a382d4d4769c510d62b;hb=master#l81
> >
> > public T next(){ fwd(); return getType(); }
> >
> > That is, next() is fwd() + getType(), whereas getType() might be
> > computationally expensive.  Sometimes, not for each move, you want to
> > get the value, then next() would slow things down.
> >
> > Best,
> > Stephan
> >
> >
> > On Tue, 2010-06-15 at 08:22 -0500, Brian Selinsky wrote:
> >    
> >> so what is the difference between fwd() and next()?
> >>
> >> if the same I would prefer next() (for consistency) and previous()
> >>
> >>
> >>
> >> On 06/14/10, Stephan Saalfeld<saalfeld at mpi-cbg.de>  wrote:
> >>
> >>      
> >>> Self-correction:
> >>> fwd() and bck() will not return boolean because I do not want them to
> >>> check anything by default.  In the following example, all pixels are
> >>> iterated until an exception (e.g. IndexOutOfBounds on type() call)
> >>> occurs:
> >>>
> >>> Cursor<T>  c;
> >>> try {
> >>>      for (;;c.fwd()){
> >>>          // meat of the loop
> >>> }
> >>> catch (Exception e){}
> >>>
> >>> I assume that this is the fastest way to iterate over all pixels
> >>> assuming that something at the basic language level is throwing an
> >>> appropriate Exception.
> >>>
> >>> Best,
> >>> Stephan
> >>>
> >>>
> >>>
> >>> On Mon, 2010-06-14 at 20:06 +0200, Stephan Saalfeld wrote:
> >>>        
> >>>> Hi,
> >>>>
> >>>> we implement java.lang.Iterator<T extends Type<T>>  where next() returns
> >>>> T, so no, next() cannot return boolean, fwd() and back() might do that.
> >>>> In the coming changes, Image<T>  implements java.lang.Iterable<T>, such
> >>>> that the Java language shortcut works:
> >>>>
> >>>> Image<  T>  image;
> >>>> for ( final T : image ) {
> >>>>      // meat of the loop
> >>>> }
> >>>>
> >>>> How's that?
> >>>>
> >>>> Currently, Cursor<T>  implements Iterable<T>  such that you can do:
> >>>>
> >>>> Cursor<T>  cursor;
> >>>> for (final T : cursor ) ...
> >>>>
> >>>> instead,  but that's less sensible and will not stay.
> >>>>
> >>>> Best,
> >>>> Stephan
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Mon, 2010-06-14 at 18:54 +0200, Johannes Schindelin wrote:
> >>>>          
> >>>>> Hi,
> >>>>>
> >>>>> On Mon, 14 Jun 2010, Stephan Preibisch wrote:
> >>>>>
> >>>>>            
> >>>>>> This is definitely something we could do as far as the linked iterators
> >>>>>> work. Right now we did not do that because it is quite often extra work,
> >>>>>> e.g. if you copy an image you need only one check instead of two:
> >>>>>>
> >>>>>> cursor1, cursor2;
> >>>>>>
> >>>>>> while ( cursor1.hasNext() )
> >>>>>> {
> >>>>>> 	cursor1.fwd();
> >>>>>> 	cursor2.fwd();
> >>>>>> 	// meat of the loop
> >>>>>> }
> >>>>>>              
> >>>>> Ah, I see. Maybe just a shortcut
> >>>>>
> >>>>> 	public boolean next() {
> >>>>>          	if (!hasNext())
> >>>>>                  	return false;
> >>>>>          	fwd();
> >>>>>          	return true;
> >>>>> 	}
> >>>>>
> >>>>> to optimize for the common case?
> >>>>>
> >>>>> Ciao,
> >>>>> Dscho
> >>>>>
> >>>>>            
> >>>>          
> >>>
> >>> _______________________________________________
> >>> ImageJ-devel mailing list
> >>> ImageJ-devel at imagejdev.org
> >>> http://imagejdev.org/mailman/listinfo/imagej-devel
> >>>        
> >
> >
> > _______________________________________________
> > ImageJ-devel mailing list
> > ImageJ-devel at imagejdev.org
> > http://imagejdev.org/mailman/listinfo/imagej-devel
> >    
> 






More information about the ImageJ-devel mailing list