[ImageJ-devel] [fiji-devel] RE: Simplifying loops?
Aivar Grislis
grislis at wisc.edu
Wed Jun 16 15:21:06 CDT 2010
Sorry I misunderstood a comment and jumped to a wrong conclusion about: "Currently, Cursor<T> implements Iterable<T> such that you can do...instead, but that's less sensible_and will not stay_."
Anyway, perhaps there could be a differently-named additional version of next() that returns null (and of fwd()/back() that return booleans), if needed.
Won't "for (;;c.fwd()) {}" loop forever with a Cursor with an OutOfBoundStrategy? :) I don't mean to keep this thread going on and on; I'm sure you'll sort it all out.
Aivar
On 6/16/10 1:46 PM, Stephan Saalfeld wrote:
> 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
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20100616/4ec4b789/attachment.html>
More information about the ImageJ-devel
mailing list