[Insight-developers] Lots of new warnings: Adding an alternative GetInverse() method to the transform hierarchy.

[Gaëtan Lehmann]

Hi Luis,

Thanks for taking care of those constraints.

The code would be quite the same in all the cases:

// code for null pointer when inverse can't be computed
TransformBase::Pointer inv = trans->GetInverse();
if( inv.IsNull() )
   {
   // treat the error
   }
// code continued


// code for exception when inverse can't be computed, without  
IsInversible()
try
   {
   TransformBase::Pointer inv = trans->GetInverse();
   // code continued
   }
catch(...)
   {
   // treat the error
   }


// code with IsInversible(), and with or without exception
if( !trans->IsInversible() )
   {
   // treat the error
   }
TransformBase::Pointer inv = trans->GetInverse();
// code continued


// code with boolean when inverse can't be computed (the problematic  
one with wrappers)
TransformBase::Pointer inv;
if( !trans->GetInverse(inv) )
   {
   // treat the error
   }
// code continued


All of them have advantages:
* IsInvertible() is the much explicit option. It makes the code a bit  
easier to read in my opinion
* implementing everything in a single method — no IsInvertible() — is  
less error-prone for the developer
* exceptions are safest than checking for null pointer
* exceptions let the non invertible case be treated elsewhere
* exceptions have a cost — it may be a problem if GetInverse() is  
often called

I guess the usage of GetInverse() will help to make a part of the  
decision about exceptions — if it is used often in loops, it would be  
preferable to avoid them.
In any case, I would personally like to have the IsInvertible() method.

Regards,

Gaëtan



Le 29 juin 08 à 16:32, Luis Ibanez a écrit :

>
> Hi Steve,
>
> I agree that both options of having GetInverse() returning a
> pointer and having an IsInvertible() method make sense.
>
> In the meantime we have backed up the modifications that we
> put in yesterday, until we sort out a good design that satisfy
> all constraints, including the need for making these methods
> available through the Wrapping.
>
> Something to keep in mind with the IsInvertible() method, is that
> in some transforms, the result will depend on the current values
> of the Transform. (e.g. in Affine Trasnsforms).
>
>
>   Regards,
>
>
>      Luis
>
>
>
> -----------------------
> Steve M. Robbins wrote:
>> On Sat, Jun 28, 2008 at 10:50:22PM -0400, Luis Ibanez wrote:
>>> This may help to find a better choice among the current options
>>> of API for GetInverse().
>> Among the options proposed, returning a pointer to the transformation
>> is most appealing to me:
>>       virtual TransformBase::Pointer  GetInverse() const
>> with the guarantee that the pointer is never null; i.e. that
>> non-invertibility is signalled by an exception.
>> In addition, I would propose that
>>       virtual bool IsInvertible() const
>> be available so that programs that *do* want to check for
>> invertibility can do so without using a try/catch.
>> Regards,
>> -Steve
>> ------------------------------------------------------------------------
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers

-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.mandriva.org
http://www.itk.org  http://www.clavier-dvorak.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20080629/922ae73a/attachment.pgp>