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

[Stephan Preibisch]

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.

@Override
public Object iterationOrder()
{
	if ( iterationOrder == null )
		iterationOrder = new FlatIterationOrder( this );
	return iterationOrder;
}

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>  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
> http://imagej.net/mailman/listinfo/imagej-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120321/a38c56d8/attachment.html>