[Insight-developers] Better Point Casting

[Miller, James V (CRD)]

It would be a little more convenient to have the Cast...() method return 
the casted values rather than have to pass an appropriate one in. But since
we can't have an overloaded function with the same input parameters and only
differ in return type, then we are probably stuck.

As for the "confusion" associated with these casts: I think as long as they are 
not implicit casts then we are okay.  If the developer needs to do an explicit cast
we should not stand in their way.

As for my example:

A neighborhood's radius is a Size<>. This makes sense in the context of a neighborhood because it
specifies a "number" of pixels in each dimension.

The Ellipsoid spatial function needs to have a center specified and the length of the
principal axes (actually the half length of the principal axes).  The center and 
lengths are specified as Points<>. This pretty much makes sense since these are "spatial functions",
though you could argue that the lengths of the principal 
axes should be Vectors<>.

What I was doing was making an ellipsoid that would fill a specified Neighborhood. Since
Neighborhoods always have a center pixel and the length of each dimension is
odd, the center of the ellipse would be at the center pixel of the Neighborhood which
happens to have pixel coordinate values that match the Neighborhood radius values.

The bottom line was that I knew what I was doing and was aware that the coordinates
I wanted to specify for my spatial function matched the "radius size" of my 
Neighborhood.  But since there was not "converter" function, I had to write
a series of small loops. These small loops can confuse the reader of the code because
unless they are commented well, there is nothing to indicate why the "copy" is being
done.

As for the Point/Vector issue, I think have these explicit converters is 
fine. While you say that it confuses the context between points and vectors, 
I would say there are times where you want to treat the coordinates of a set
of points as simply vectors in a particular vector space. If the developer really
wants to do this conversion, we should simplify the task.  The important thing 
is that these are explicit converters that have to be called by the developer
we would not be providing implicit cast operators to go from Points to Vectors.






-----Original Message-----
From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
Sent: Wednesday, February 20, 2002 10:02 AM
To: Miller, James V (CRD)
Cc: Lydia Ng; insight-developers@public.kitware.com
Subject: Re: [Insight-developers] Better Point Casting



Miller, James V (CRD) wrote:

> I was thinking it might be nice to have CastFrom() on other objects as 
> well.
> In particular: Index, Offset, Size, ContinuousIndex, ...


Totally agree with that, we have a lot of for() loops here
and there for doing this (as you already noted).

Should we restrict the number of combination to those that
make sense ?  

We could just add a limited liability function:

     template < arraytype A, arraytype B >
     void
     CastAtYourOwnRisk( const arraytype & A, arraytype & B );

templated function (not belonging to any class) relying on the
types to have defined: { ValueType, Dimension and operator[] }.
...trust the users and hope for the best....!


I would rather not allow casting Points to Vectors because
that blurrs the distintion between both concepts and removes
all the interest in having both classes we could just have
itkArrays in that case. Same thing goes for the distinction
between Index and Size for example.

>
> Should this be a class member or a separate function?

It looks like separate functions will provide more flexibility.
Maybe putting all of then in an    itkCasting.h      file ?

>
> When I want to use the Radius of a Neighborhood as the
> Center of an EllipsoidSpatialFunction, I need to create a
> Point and copy the radius:

Isn't this a missuse of the concepts ?
Why would you like to use a radius as a center ?
I can see the need for using an Index as a Point and vice-versa;
the same relation seems to work for Size and Vector.
In general trying to cast:  Index to Size or Point to Vector
should be an indication that something wrong is going on.

>
> If we use functions outside of the class, we could avoid
> templated member functions.

This seems to be the best option.
It will be a matter of selecting what combinations of casting
should be allowed.


I'm having trouble finding  a good differenciation between
an itkPoint and an itkContinuousIndex. It looks like a Point
could be used everywhere a ContinuousIndex is being used.

It is just a distinction of the reference system ?


Luis