[ImageJ-devel] [fiji-devel] Re: equal iteration order

[Tobias Pietzsch]

Hi Steffi,

On 03/21/2012 06:57 PM, Stephan Preibisch wrote:
> Hi Tobias,
>
> great!
>
> Just one question, should we always create the instance in each Img like
> ArrayImg from the beginning or maybe just instantiate it once
> equalIterationOrder is called the first time?
>
> This would reduce the initial overhead of each Img, just imagine you
> have a lot of small ones ... Because I guess there are a lot of examples
> where this method will never be called.

Sure. That will work as well.
You could also return a new instance everytime iterationOrder() is
called, if you expect that to happen rarely or never.

For now, I followed this conventions:

* Imgs create their IterationOrder instance in the constructor.
* IterableInterval that are basically not compatible to anything
   else, e.g. KDTree, just return "this" (only compatible with
   themselves.
* wrapper classes propagate iterationOrder() to the wrapped class.

best regards,
Tobias


>
> @Override
> public Object iterationOrder()
> {
> if ( iterationOrder== null )
> iterationOrder = new FlatIterationOrder( this );
> returniterationOrder;
> }
>
> Steffi
>
> On Mar 21, 2012, at 13:27 , Tobias Pietzsch wrote:
>
>> Hi,
>>
>> I cleaned up the "equal iteration order" mechanism.
>>
>>
>> In the end, I did not use an interface "FlatIterationOrder".
>> The reason was that this interface can not be propagated through wrapper
>> classes (like ImgPlus). Even though ImgPlus.equalIterationOrder( f )
>> propagates to its wrapped img like
>>
>> return img.equalIterationOrder( f );
>>
>> this breaks when you try to compare the iteration orders of two ImgPlus
>> for instance. The first solution to this would be to
>>
>> return f.equalIterationOrder( img );
>>
>> and assume f does the same and you propagate alternately down to the
>> un-wrapped IterableIntervals. However, you would have to be super
>> careful not to provoke infinite loops in this way.
>>
>>
>>
>> So instead of this, I introduced a new method in the
>> IterableRealInterval interface:
>>
>> public Object iterationOrder()
>>
>> It is supposed to return an Object that represents the particular
>> iteration order. Comparison of iteration orders is via Object.equals().
>> That is, if you want to find whether IterableIntervals A and B have
>> equal iteration order, you ask whether
>>
>> A.iterationOrder().equals(B.iterationOrder()).
>>
>> equalIterationOrder() is deprecated. I still changed it everywhere to
>> have it still work but some day we should remove it to keep the
>> IterableRealInterval interface as small as possible.
>>
>> So, FlatIterationOrder is a class now. If you support flat iteration
>> order, then your iterationOrder() method should return a
>> FlatIterationOrder instance constructed with your Interval.
>>
>>
>> best regards,
>> Tobias
>>
>> On 03/13/2012 02:40 PM, Albert Cardona wrote:
>>> El 13 de març de 2012 9:39, Albert Cardona<sapristi at gmail.com
>>> <mailto:sapristi at gmail.com>> ha escrit:
>>>> ImgLib2'ers:
>>>>
>>>> Instead of this:
>>>>
>>>> ( IterableRandomAccessibleInterval.class.isInstance( f ) ||
>>>> ArrayImg.class.isInstance( f ) || ListImg.class.isInstance( f ) ) )
>>>>
>>>> Why not create the empty interface EqualIterationOrder and make all
>>>> the above classes implement it? This way code will be future-proof,
>>>> and flexible to user-defined new Img classes.
>>>>
>>>> Albert
>>>
>>>
>>> Too early in the morning. I meant a new interface "FlatIterationOrder".
>>>
>>> Albert
>>>
>>>
>>
>>
>> _______________________________________________
>> ImageJ-devel mailing list
>> ImageJ-devel at imagej.net <mailto:ImageJ-devel at imagej.net>
>> http://imagej.net/mailman/listinfo/imagej-devel
>