ggt-devel — Development discussion list

[ggt-devel] 2 pi

[Justin H. <ja...@vr...>]

Would there be any objections to adding another pi-related constant to 
gmtl/Math.h? We've got PI, PI_OVER_2, and PI_OVER_4 already. 

But (2 * PI) comes up quite a bit in calculations and I wanted to add it
as PI_TIMES_2 or TWO_PI.

justin

-----------------------------------------
Justin Hare  <ja...@vr...>
Virtual Reality Applications Center
Iowa State University, Howe Hall
http://www.vrac.iastate.edu/~jahare
-----------------------------------------

[ggt-devel] FAQ link on the main page

[Ben S. <bs...@ia...>]

I don't know about you guys, but I get asked all the time how to use 
GMTL. Since Justin created our wonderful FAQ, I added a link on the ggt 
home page directly so that I can refer them to the ggt home page. I 
thought I'd let y'all know so that you can do the same. ;)

cheers,
-----
Ben Scott
Research Assistant
VR Juggler Team
Virtual Reality Applications Center
bs...@vr...

Re: [ggt-devel] API oddities

[Kevin M. <ke...@vr...>]

yes. :)

On Fri, 18 Apr 2003, Patrick Hartling wrote:

> So what's the consensus on this?  If I'm going to change the API, I'd 
> like to do what people want.
> 
> Regarding the suggestion to rename one of the gmtl::cross() overloads to 
> gmtl::makeCross(), should it go in Generate.h?
> 
>   -Patrick
> 
> Allen Bierbaum wrote:
> > Ben Scott wrote:
> > 
> >> He means the prenormalization length.
> >>
> >> I agree with Kevin's comments. :)
> > 
> > 
> > I agreed with Kevin's comments, but then I thought some more and now I 
> > am not sure.
> > 
> > I do understand why we return the pre normalized length out the backend. 
> >  Doing this can help in some algorithms.  (I think dist from point to 
> > plane may be able to use this, but I don't remember).
> > 
> > But thinking about it why can't the user just do this:
> > 
> > float len = lengthSqr(vec);
> > if (not isEqual(len, 1.0, epsilon))
> >    len = Math::sqr(len);
> > vec /= len;
> > 
> > This can be easily written in any algorithm that wants to take advantage 
> > of the performance gain.
> > 
> > I am not insisting on doing it this way or anything, but it seems that 
> > making the API more complex for something that "might" be useful but can 
> > easily be done by the user really doesn't fit with our ideas.
> > 
> > (Also when you take into account that the method where we return the 
> > float from normalize() actually introduces another temporary for the 
> > return value it isn't even as optimal as the hand coded one above).
> > 
> > Thats what I am thinking right now at least... give me another couple 
> > minutes and I will have completely changed my mind and think we should 
> > just use templates, python, or some other crazy crap for all of it. :)
> > 
> > -Allen
> > 
> >>
> >> cheers,
> >> -ben
> >>
> >> Justin Hare wrote:
> >>
> >>>> normalizeAndGetLength( vec );  // reads well, and shows the special opt
> >>>> normalize( vec );            // standard method, ret vec out back
> >>>
> >>>
> >>>
> >>>
> >>> Wouldn't the length of the vector after normalization always be the 
> >>> same?
> >>> Or do you mean to return the pre-normalization length?
> 
> 
> 
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
home - http://www.vrsource.edu/~kevin           \        / 
music - http://subatomic.vrsource.org          \/  __    \/
                                                   \__     
                                            \_\            

Re: Pass-byvalue vs. pass-by-reference (was Re: [ggt-devel] API oddities)

[Patrick H. <pa...@13...>]

Darn, it looks as though the copy is necessary:

gmtl/Generate.h: In function `gmtl::AxisAngle<DATA_TYPE>&
    gmtl::set(gmtl::AxisAngle<DATA_TYPE>&, const gmtl::Quat<DATA_TYPE>&) 
[with
    DATA_TYPE = float]':
Test/TestSuite/TestCases/QuatGenTest.cpp:233:   instantiated from here
gmtl/Generate.h:518: no matching function for call to `normalize(const
    gmtl::Quat<float>&)'

The quaternion is normalized prior to the steps needed for the set 
operation.  Oh well.

  -Patrick

Kevin Meinert wrote:
> 
> Looks good.  Just make sure the copy isn't needed on them (compiler should 
> complain I think if you make it const and the func is writting to the 
> data).
> 
> 
> kevin
> 
> On Fri, 18 Apr 2003, Patrick Hartling wrote:
> 
> 
>>Here's the list I put together from the list of method instantiations 
>>needed for Python:
>>
>>gmtl::makeNormal(gmtl::Vec)
>>gmtl::set(gmtl::AxisAngle&, gmtl::Quat)
>>gmtl::setRot(gmtl::AxisAngle&, gmtl::Quat)
>>
>>In the first case, I *think* the gmtl::Vec<S, T> parameter should be a 
>>const reference.  In the other two, I would think that the gmtl::Quat<T> 
>>parameter should be a const reference, but this could be one of those 
>>places where a copy is more appropriate.
>>
>>Ths list is shorter than I remember, but that's probably because there 
>>are multiple variations of these instantiated based on the data types 
>>used (float, double, etc.).
>>
>>  -Patrick
>>
>>Ben Scott wrote:
>>
>>>Patrick Hartling wrote:
>>>
>>>[snip]
>>>
>>>
>>>>P.S. There are several places where data types are being passed by 
>>>>value where pass-by-reference behavior would be appropriate.  I didn't 
>>>>note where each of these is, but I should be able to find them in my 
>>>>long list of function instantiations.
>>>
>>>
>>>Please do keep a list as you find them and let us know what they are. 
>>>That way we can fix them if you don't. :)
>>>
>>>cheers,
>>>-----
>>>Ben Scott
>>>Research Assistant
>>>VR Juggler Team
>>>Virtual Reality Applications Center
>>>bs...@vr...
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This sf.net email is sponsored by:ThinkGeek
>>>Welcome to geek heaven.
>>>http://thinkgeek.com/sf
>>>_______________________________________________
>>>ggt-devel mailing list
>>>ggt...@li...
>>>https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>
>>
>>
>>
> 



-- 
Patrick L. Hartling			| Research Assistant, VRAC
pa...@13...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

Re: [ggt-devel] API oddities

[Patrick H. <pa...@13...>]

So what's the consensus on this?  If I'm going to change the API, I'd 
like to do what people want.

Regarding the suggestion to rename one of the gmtl::cross() overloads to 
gmtl::makeCross(), should it go in Generate.h?

  -Patrick

Allen Bierbaum wrote:
> Ben Scott wrote:
> 
>> He means the prenormalization length.
>>
>> I agree with Kevin's comments. :)
> 
> 
> I agreed with Kevin's comments, but then I thought some more and now I 
> am not sure.
> 
> I do understand why we return the pre normalized length out the backend. 
>  Doing this can help in some algorithms.  (I think dist from point to 
> plane may be able to use this, but I don't remember).
> 
> But thinking about it why can't the user just do this:
> 
> float len = lengthSqr(vec);
> if (not isEqual(len, 1.0, epsilon))
>    len = Math::sqr(len);
> vec /= len;
> 
> This can be easily written in any algorithm that wants to take advantage 
> of the performance gain.
> 
> I am not insisting on doing it this way or anything, but it seems that 
> making the API more complex for something that "might" be useful but can 
> easily be done by the user really doesn't fit with our ideas.
> 
> (Also when you take into account that the method where we return the 
> float from normalize() actually introduces another temporary for the 
> return value it isn't even as optimal as the hand coded one above).
> 
> Thats what I am thinking right now at least... give me another couple 
> minutes and I will have completely changed my mind and think we should 
> just use templates, python, or some other crazy crap for all of it. :)
> 
> -Allen
> 
>>
>> cheers,
>> -ben
>>
>> Justin Hare wrote:
>>
>>>> normalizeAndGetLength( vec );  // reads well, and shows the special opt
>>>> normalize( vec );            // standard method, ret vec out back
>>>
>>>
>>>
>>>
>>> Wouldn't the length of the vector after normalization always be the 
>>> same?
>>> Or do you mean to return the pre-normalization length?



-- 
Patrick L. Hartling			| Research Assistant, VRAC
pa...@13...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

Re: Pass-byvalue vs. pass-by-reference (was Re: [ggt-devel] API oddities)

[Kevin M. <ke...@vr...>]

Looks good.  Just make sure the copy isn't needed on them (compiler should 
complain I think if you make it const and the func is writting to the 
data).


kevin

On Fri, 18 Apr 2003, Patrick Hartling wrote:

> Here's the list I put together from the list of method instantiations 
> needed for Python:
> 
> gmtl::makeNormal(gmtl::Vec)
> gmtl::set(gmtl::AxisAngle&, gmtl::Quat)
> gmtl::setRot(gmtl::AxisAngle&, gmtl::Quat)
> 
> In the first case, I *think* the gmtl::Vec<S, T> parameter should be a 
> const reference.  In the other two, I would think that the gmtl::Quat<T> 
> parameter should be a const reference, but this could be one of those 
> places where a copy is more appropriate.
> 
> Ths list is shorter than I remember, but that's probably because there 
> are multiple variations of these instantiated based on the data types 
> used (float, double, etc.).
> 
>   -Patrick
> 
> Ben Scott wrote:
> > Patrick Hartling wrote:
> > 
> > [snip]
> > 
> >> P.S. There are several places where data types are being passed by 
> >> value where pass-by-reference behavior would be appropriate.  I didn't 
> >> note where each of these is, but I should be able to find them in my 
> >> long list of function instantiations.
> > 
> > 
> > Please do keep a list as you find them and let us know what they are. 
> > That way we can fix them if you don't. :)
> > 
> > cheers,
> > -----
> > Ben Scott
> > Research Assistant
> > VR Juggler Team
> > Virtual Reality Applications Center
> > bs...@vr...
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > ggt-devel mailing list
> > ggt...@li...
> > https://lists.sourceforge.net/lists/listinfo/ggt-devel
> 
> 
> 
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
home - http://www.vrsource.edu/~kevin           \        / 
music - http://subatomic.vrsource.org          \/  __    \/
                                                   \__     
                                            \_\            

Pass-byvalue vs. pass-by-reference (was Re: [ggt-devel] API oddities)

[Patrick H. <pa...@13...>]

Here's the list I put together from the list of method instantiations 
needed for Python:

gmtl::makeNormal(gmtl::Vec)
gmtl::set(gmtl::AxisAngle&, gmtl::Quat)
gmtl::setRot(gmtl::AxisAngle&, gmtl::Quat)

In the first case, I *think* the gmtl::Vec<S, T> parameter should be a 
const reference.  In the other two, I would think that the gmtl::Quat<T> 
parameter should be a const reference, but this could be one of those 
places where a copy is more appropriate.

Ths list is shorter than I remember, but that's probably because there 
are multiple variations of these instantiated based on the data types 
used (float, double, etc.).

  -Patrick

Ben Scott wrote:
> Patrick Hartling wrote:
> 
> [snip]
> 
>> P.S. There are several places where data types are being passed by 
>> value where pass-by-reference behavior would be appropriate.  I didn't 
>> note where each of these is, but I should be able to find them in my 
>> long list of function instantiations.
> 
> 
> Please do keep a list as you find them and let us know what they are. 
> That way we can fix them if you don't. :)
> 
> cheers,
> -----
> Ben Scott
> Research Assistant
> VR Juggler Team
> Virtual Reality Applications Center
> bs...@vr...
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel



-- 
Patrick L. Hartling			| Research Assistant, VRAC
pa...@13...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

Re: [ggt-devel] API oddities

[Kevin M. <ke...@vr...>]

I know there are a couple places that use by value simply because that 
function needed a copy anyway.  be careful with those... (shouldn't be too 
many of them)


On Wed, 16 Apr 2003, Ben Scott wrote:

> Patrick Hartling wrote:
> 
> [snip]
> 
> > P.S. There are several places where data types are being passed by value 
> > where pass-by-reference behavior would be appropriate.  I didn't note 
> > where each of these is, but I should be able to find them in my long 
> > list of function instantiations.
> 
> Please do keep a list as you find them and let us know what they are. 
> That way we can fix them if you don't. :)
> 
> cheers,
> -----
> Ben Scott
> Research Assistant
> VR Juggler Team
> Virtual Reality Applications Center
> bs...@vr...
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
home - http://www.vrsource.edu/~kevin           \        / 
music - http://subatomic.vrsource.org          \/  __    \/
                                                   \__     
                                            \_\            

Re: [ggt-devel] API oddities

[Allen B. <al...@vr...>]

Ben Scott wrote:
> He means the prenormalization length.
> 
> I agree with Kevin's comments. :)

I agreed with Kevin's comments, but then I thought some more and now I 
am not sure.

I do understand why we return the pre normalized length out the backend. 
  Doing this can help in some algorithms.  (I think dist from point to 
plane may be able to use this, but I don't remember).

But thinking about it why can't the user just do this:

float len = lengthSqr(vec);
if (not isEqual(len, 1.0, epsilon))
    len = Math::sqr(len);
vec /= len;

This can be easily written in any algorithm that wants to take advantage 
of the performance gain.

I am not insisting on doing it this way or anything, but it seems that 
making the API more complex for something that "might" be useful but can 
easily be done by the user really doesn't fit with our ideas.

(Also when you take into account that the method where we return the 
float from normalize() actually introduces another temporary for the 
return value it isn't even as optimal as the hand coded one above).

Thats what I am thinking right now at least... give me another couple 
minutes and I will have completely changed my mind and think we should 
just use templates, python, or some other crazy crap for all of it. :)

-Allen

> 
> cheers,
> -ben
> 
> Justin Hare wrote:
> 
>>> normalizeAndGetLength( vec );  // reads well, and shows the special opt
>>> normalize( vec );            // standard method, ret vec out back
>>
>>
>>
>> Wouldn't the length of the vector after normalization always be the same?
>> Or do you mean to return the pre-normalization length?
>>
>> -----------------------------------------
>> Justin Hare  <ja...@vr...>
>> Virtual Reality Applications Center
>> Iowa State University, Howe Hall
>> http://www.vrac.iastate.edu/~jahare
>> -----------------------------------------
>>
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel


-- 
-- Allen Bierbaum                         al...@vr...
-- PhD Candidate             txtmsg - 515...@us...
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu

Re: [ggt-devel] API oddities

[Ben S. <bs...@ia...>]

Patrick Hartling wrote:

[snip]

> P.S. There are several places where data types are being passed by value 
> where pass-by-reference behavior would be appropriate.  I didn't note 
> where each of these is, but I should be able to find them in my long 
> list of function instantiations.

Please do keep a list as you find them and let us know what they are. 
That way we can fix them if you don't. :)

cheers,
-----
Ben Scott
Research Assistant
VR Juggler Team
Virtual Reality Applications Center
bs...@vr...

Re: [ggt-devel] API oddities

[Ben S. <bs...@ia...>]

He means the prenormalization length.

I agree with Kevin's comments. :)

cheers,
-ben

Justin Hare wrote:
>>normalizeAndGetLength( vec );  // reads well, and shows the special opt
>>normalize( vec );            // standard method, ret vec out back
> 
> 
> Wouldn't the length of the vector after normalization always be the same?
> Or do you mean to return the pre-normalization length?
> 
> -----------------------------------------
> Justin Hare  <ja...@vr...>
> Virtual Reality Applications Center
> Iowa State University, Howe Hall
> http://www.vrac.iastate.edu/~jahare
> -----------------------------------------
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel

Re: [ggt-devel] API oddities

[Justin H. <ja...@vr...>]

> normalizeAndGetLength( vec );  // reads well, and shows the special opt
> normalize( vec );            // standard method, ret vec out back

Wouldn't the length of the vector after normalization always be the same?
Or do you mean to return the pre-normalization length?

-----------------------------------------
Justin Hare  <ja...@vr...>
Virtual Reality Applications Center
Iowa State University, Howe Hall
http://www.vrac.iastate.edu/~jahare
-----------------------------------------

Re: [ggt-devel] API oddities

[Kevin M. <ke...@vr...>]

I agree with the cross statement, and the makeCross.

For normalize, it returns float because it can be a useful optimization to 
not recompute it, and you don't have to catch it.  You're right that it 
isn't consistant, but here we chose the interface that would make the 
fastest code.

so what to do?...

makeCross wouldn't change behaviour, and it would fit the idea of gmtl 
better, so i'm all for it.

I'd almost like to have two normalize funcs, one that returns a vec, and 
one that returns a float. :(

normalize<float>( vec )
normalize<vec>( vec )

seems to be our way of doing this... but I don't like it in this case I 
guess.

I'd rather have this:

normalizeAndGetLength( vec );  // reads well, and shows the special opt
normalize( vec );            // standard method, ret vec out back


kevin

On Wed, 16 Apr 2003, Patrick Hartling wrote:

> In writing up the Python bindings for GMTL functions, I ran across what 
> seem to be inconsistencies in the GMTL API.  There are two functions in 
> particular: gmtl::cross() and gmtl::normalize().  In the case of 
> gmtl::cross(), there are two forms (using gmtl::Vec3f as an instantiating 
> type in this example):
> 
>     template gmtl::Vec3f cross(const gmtl::Vec3f&, const gmtl::Vec3f&);
>     template gmtl::Vec3f& cross(gmtl::Vec3f&, const gmtl::Vec3f&,
>                                 const gmtl::Vec3f&);
> 
> Why is there a version that returns a vector by value?  As far as I have 
> seen, this is the only such function in the entire GMTL API.  All the 
> others follow the second form where the result vector has to exist a 
> priori.  It might be appropriate for the first variant to be renamed 
> gmtl::makeCross().
> 
> With gmtl::normalize(), the vector version has both different syntax and 
> semantics WRT the quaternion version.  For example:
> 
>     template float normalize(gmtl::Vec3f&);
>     template gmtl::Quatf& normalize(gmtl::Quatf&);
> 
> In the vector case, gmtl::normalize() returns the length of the vector 
> before it was normalized.  Is that information typically useful?  The 
> quaternion version seems to follow the GMTL conventions more closely--at 
> least when compared to functions like gmtl::invert(), gmtl::transpose(), 
> and so on.
> 
> My confusion is based mostly on my declining math skills.  I would be 
> happy to learn that there are valid reasons for these inconsistencies, 
> though having inconsistencies such as these does make the Python mappings 
> a little more complicated.
> 
>   -Patrick
> 
> 
> P.S. There are several places where data types are being passed by value 
> where pass-by-reference behavior would be appropriate.  I didn't note 
> where each of these is, but I should be able to find them in my long list 
> of function instantiations.
> 
> 
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
home - http://www.vrsource.edu/~kevin           \        / 
music - http://subatomic.vrsource.org          \/  __    \/
                                                   \__     
                                            \_\            

[ggt-devel] API oddities

[Patrick H. <pa...@13...>]

In writing up the Python bindings for GMTL functions, I ran across what 
seem to be inconsistencies in the GMTL API.  There are two functions in 
particular: gmtl::cross() and gmtl::normalize().  In the case of 
gmtl::cross(), there are two forms (using gmtl::Vec3f as an instantiating 
type in this example):

    template gmtl::Vec3f cross(const gmtl::Vec3f&, const gmtl::Vec3f&);
    template gmtl::Vec3f& cross(gmtl::Vec3f&, const gmtl::Vec3f&,
                                const gmtl::Vec3f&);

Why is there a version that returns a vector by value?  As far as I have 
seen, this is the only such function in the entire GMTL API.  All the 
others follow the second form where the result vector has to exist a 
priori.  It might be appropriate for the first variant to be renamed 
gmtl::makeCross().

With gmtl::normalize(), the vector version has both different syntax and 
semantics WRT the quaternion version.  For example:

    template float normalize(gmtl::Vec3f&);
    template gmtl::Quatf& normalize(gmtl::Quatf&);

In the vector case, gmtl::normalize() returns the length of the vector 
before it was normalized.  Is that information typically useful?  The 
quaternion version seems to follow the GMTL conventions more closely--at 
least when compared to functions like gmtl::invert(), gmtl::transpose(), 
and so on.

My confusion is based mostly on my declining math skills.  I would be 
happy to learn that there are valid reasons for these inconsistencies, 
though having inconsistencies such as these does make the Python mappings 
a little more complicated.

  -Patrick


P.S. There are several places where data types are being passed by value 
where pass-by-reference behavior would be appropriate.  I didn't note 
where each of these is, but I should be able to find them in my long list 
of function instantiations.


-- 
Patrick L. Hartling			| Research Assistant, VRAC
pa...@13...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

Re: [ggt-devel] gmtl::makeInverse()

[Ben S. <bs...@ia...>]

It is an API change, but since the user never specifies the argument, 
they won't even notice the change. Also, the function is inlined in 
compiled code, so applications don't even have to worry about an ABI 
change. I think we should be OK with just bumping to 0.2.2.

cheers,
-Ben

Patrick Hartling wrote:
> Okay, the change is committed.  Since this changes the API, should the 
> version increase go to 0.3.0 or 0.2.2?  It removes a default argument 
> that I doubt anyone would have ever used, so 0.2.2 would probably be okay.
> 
>  -Patrick
> 
> Ben Scott wrote:
> 
>> You are right. makeInverse() shouldn't need Type2Type. The only reason 
>> I can think of that it might be there would be to work around a VC7 
>> compile error. However, I'm pretty sure that's not the case since I'm 
>> not seeing that in the CVS log.
>>
>> I give you the green light on removing the Type2Type. When you do 
>> though, make sure you modify the src argument to pass by const 
>> reference rather that const value. (I just noticed that error ...)
>>
>> cheers,
>> -Ben
>>
>> Patrick Hartling wrote:
>>
>>> Is there a reason that gmtl::makeInverse() (lines 1064-1070 of 
>>> Generate.h) uses the Type2Type idiom?  Just from looking at it, it 
>>> seems like there can be no ambiguity relating to overloading because 
>>> the return type always matches the parameter type.  Am I missing 
>>> something?
>>>
>>>  -Patrick
>>>
>>>
>>> P.S. I ask because the Type2Type thing doesn't work at all in 
>>> languages without generics (at least AFAICT), and the fewer places I 
>>> have to write wrappers, the better.
>>>
>>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by:
>> The Definitive IT and Networking Event. Be There!
>> NetWorld+Interop Las Vegas 2003 -- Register today!
>> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
> 
> 
> 
> 

Re: [ggt-devel] gmtl::makeInverse()

[Patrick H. <pa...@13...>]

Okay, the change is committed.  Since this changes the API, should the 
version increase go to 0.3.0 or 0.2.2?  It removes a default argument 
that I doubt anyone would have ever used, so 0.2.2 would probably be okay.

  -Patrick

Ben Scott wrote:
> You are right. makeInverse() shouldn't need Type2Type. The only reason I 
> can think of that it might be there would be to work around a VC7 
> compile error. However, I'm pretty sure that's not the case since I'm 
> not seeing that in the CVS log.
> 
> I give you the green light on removing the Type2Type. When you do 
> though, make sure you modify the src argument to pass by const reference 
> rather that const value. (I just noticed that error ...)
> 
> cheers,
> -Ben
> 
> Patrick Hartling wrote:
> 
>> Is there a reason that gmtl::makeInverse() (lines 1064-1070 of 
>> Generate.h) uses the Type2Type idiom?  Just from looking at it, it 
>> seems like there can be no ambiguity relating to overloading because 
>> the return type always matches the parameter type.  Am I missing 
>> something?
>>
>>  -Patrick
>>
>>
>> P.S. I ask because the Type2Type thing doesn't work at all in 
>> languages without generics (at least AFAICT), and the fewer places I 
>> have to write wrappers, the better.
>>
>>
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel



-- 
Patrick L. Hartling			| Research Assistant, VRAC
pa...@13...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

Re: [ggt-devel] Python interface to GMTL

[Allen B. <al...@vr...>]

Patrick Hartling wrote:
> Allen Bierbaum wrote:
> 
>> Patrick Hartling wrote:
>>
>>> Allen Bierbaum wrote:
>>>
>>>> Patrick Hartling wrote:
>>>>
>>>>> I have spent many hours today working on exposing GMTL classes and 
>>>>> functions for use with Python, and while I have made a ton of 
>>>>> progress, I have reached something of an impasse.  While it is 
>>>>> possible to instantiate and manipulate matrices, vectors, etc. in 
>>>>> Python, it is not possible at this moment to read any data from 
>>>>> them.  The GMTL interface is built up around C++ data access 
>>>>> idioms, and some of those (operator[] in particular) do not 
>>>>> translate to Python.  The biggest issue I face is that there is no 
>>>>> way (at this time) to map a C-style array to Python using 
>>>>> Boost.Python.  Even if there were a way to do that, Python doesn't 
>>>>> have a data structure with exactly the same semantics as a C-style 
>>>>> array.  The only GMTL class that is even close to having its data 
>>>>> be readable is gmtl::Matrix<>, and that's only because it overloads 
>>>>> operator(), one of the few class operators that can be overloaded 
>>>>> in Python.  Of course, I can't get the relevant Boost.Python code 
>>>>> to compile, so the point is moot.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Why can't we use python's [] operator?  Is there something about 
>>>> Boost::Python that prevents this overload from taking place or is 
>>>> the problem related to slicing?
>>>
>>>
>>>
>>>
>>> I don't know how to overload that operator.  Pyste didn't do it 
>>> automatically, and I have been having trouble making sense of how 
>>> Boost.Python does operator overloading.  My suspicion is that Python 
>>> itself doesn't allow that operator to be overloaded, but I could be 
>>> wrong.
>>
>>
>>
>> the python methods are:
>>
>> __getitem__ __setitem___ and __delitem__
> 
> 
> What documentation did you read to find out about these?  Methods like 
> this seem like a mystery to me, and I don't know where to look to read 
> more about them.  Searches on Google seem to turn up more about Jython 
> than anything else.  Maybe that's not such a bad start, though ...

I am just looking at standard language references.

In the python.org docs you can find the ones I am talking about at:

http://www.python.org/doc/current/ref/sequence-types.html

Basically there are just specific named methods that are used for 
operator based access in python.  The *item methods are the ones to do 
the container type access similar to op[] in C++.

> 
>> We probably only need to define the first two of them.  There may also 
>> be some issues to take into account to support slicing, but we could 
>> ignore those in the first pass at the interface.
> 
> 
> Are these issues in the documentation you're reading?

A little bit of a mention of it but nothing conclusive.  I think we just 
need to try it and see how it works.

-Allen


>  -Patrick
> 
> 


-- 
-- Allen Bierbaum                         al...@vr...
-- PhD Candidate             txtmsg - 515...@us...
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu

Re: [ggt-devel] Python interface to GMTL

[Patrick H. <pa...@13...>]

Allen Bierbaum wrote:
> Patrick Hartling wrote:
> 
>> Allen Bierbaum wrote:
>>
>>> Patrick Hartling wrote:
>>>
>>>> I have spent many hours today working on exposing GMTL classes and 
>>>> functions for use with Python, and while I have made a ton of 
>>>> progress, I have reached something of an impasse.  While it is 
>>>> possible to instantiate and manipulate matrices, vectors, etc. in 
>>>> Python, it is not possible at this moment to read any data from 
>>>> them.  The GMTL interface is built up around C++ data access idioms, 
>>>> and some of those (operator[] in particular) do not translate to 
>>>> Python.  The biggest issue I face is that there is no way (at this 
>>>> time) to map a C-style array to Python using Boost.Python.  Even if 
>>>> there were a way to do that, Python doesn't have a data structure 
>>>> with exactly the same semantics as a C-style array.  The only GMTL 
>>>> class that is even close to having its data be readable is 
>>>> gmtl::Matrix<>, and that's only because it overloads operator(), one 
>>>> of the few class operators that can be overloaded in Python.  Of 
>>>> course, I can't get the relevant Boost.Python code to compile, so 
>>>> the point is moot.
>>>
>>>
>>>
>>>
>>> Why can't we use python's [] operator?  Is there something about 
>>> Boost::Python that prevents this overload from taking place or is the 
>>> problem related to slicing?
>>
>>
>>
>> I don't know how to overload that operator.  Pyste didn't do it 
>> automatically, and I have been having trouble making sense of how 
>> Boost.Python does operator overloading.  My suspicion is that Python 
>> itself doesn't allow that operator to be overloaded, but I could be 
>> wrong.
> 
> 
> the python methods are:
> 
> __getitem__ __setitem___ and __delitem__

What documentation did you read to find out about these?  Methods like 
this seem like a mystery to me, and I don't know where to look to read 
more about them.  Searches on Google seem to turn up more about Jython 
than anything else.  Maybe that's not such a bad start, though ...

> We probably only need to define the first two of them.  There may also 
> be some issues to take into account to support slicing, but we could 
> ignore those in the first pass at the interface.

Are these issues in the documentation you're reading?

  -Patrick


-- 
Patrick L. Hartling			| Research Assistant, VRAC
pa...@13...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

Re: [ggt-devel] gmtl::makeInverse()

[Patrick H. <pa...@13...>]

Ben Scott wrote:
> You are right. makeInverse() shouldn't need Type2Type. The only reason I 
> can think of that it might be there would be to work around a VC7 
> compile error. However, I'm pretty sure that's not the case since I'm 
> not seeing that in the CVS log.
> 
> I give you the green light on removing the Type2Type. When you do 
> though, make sure you modify the src argument to pass by const reference 
> rather that const value. (I just noticed that error ...)

The pending change I have does exactly that.  ;)  There are a lot of 
other things like that lurking throughout the GMTL source.  I spotted 
many of them while working on the Python mappings.

  -Patrick

> Patrick Hartling wrote:
> 
>> Is there a reason that gmtl::makeInverse() (lines 1064-1070 of 
>> Generate.h) uses the Type2Type idiom?  Just from looking at it, it 
>> seems like there can be no ambiguity relating to overloading because 
>> the return type always matches the parameter type.  Am I missing 
>> something?
>>
>>  -Patrick
>>
>>
>> P.S. I ask because the Type2Type thing doesn't work at all in 
>> languages without generics (at least AFAICT), and the fewer places I 
>> have to write wrappers, the better.
>>
>>
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel


-- 
Patrick L. Hartling			| Research Assistant, VRAC
pa...@13...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

Re: [ggt-devel] gmtl::makeInverse()

[Ben S. <bs...@ia...>]

You are right. makeInverse() shouldn't need Type2Type. The only reason I 
can think of that it might be there would be to work around a VC7 
compile error. However, I'm pretty sure that's not the case since I'm 
not seeing that in the CVS log.

I give you the green light on removing the Type2Type. When you do 
though, make sure you modify the src argument to pass by const reference 
rather that const value. (I just noticed that error ...)

cheers,
-Ben

Patrick Hartling wrote:
> Is there a reason that gmtl::makeInverse() (lines 1064-1070 of 
> Generate.h) uses the Type2Type idiom?  Just from looking at it, it seems 
> like there can be no ambiguity relating to overloading because the 
> return type always matches the parameter type.  Am I missing something?
> 
>  -Patrick
> 
> 
> P.S. I ask because the Type2Type thing doesn't work at all in languages 
> without generics (at least AFAICT), and the fewer places I have to write 
> wrappers, the better.
> 
> 

Re: [ggt-devel] Python interface to GMTL

[Allen B. <al...@vr...>]

Patrick Hartling wrote:
> Allen Bierbaum wrote:
> 
>> Patrick Hartling wrote:
>>
>>> I have spent many hours today working on exposing GMTL classes and 
>>> functions for use with Python, and while I have made a ton of 
>>> progress, I have reached something of an impasse.  While it is 
>>> possible to instantiate and manipulate matrices, vectors, etc. in 
>>> Python, it is not possible at this moment to read any data from 
>>> them.  The GMTL interface is built up around C++ data access idioms, 
>>> and some of those (operator[] in particular) do not translate to 
>>> Python.  The biggest issue I face is that there is no way (at this 
>>> time) to map a C-style array to Python using Boost.Python.  Even if 
>>> there were a way to do that, Python doesn't have a data structure 
>>> with exactly the same semantics as a C-style array.  The only GMTL 
>>> class that is even close to having its data be readable is 
>>> gmtl::Matrix<>, and that's only because it overloads operator(), one 
>>> of the few class operators that can be overloaded in Python.  Of 
>>> course, I can't get the relevant Boost.Python code to compile, so the 
>>> point is moot.
>>
>>
>>
>> Why can't we use python's [] operator?  Is there something about 
>> Boost::Python that prevents this overload from taking place or is the 
>> problem related to slicing?
> 
> 
> I don't know how to overload that operator.  Pyste didn't do it 
> automatically, and I have been having trouble making sense of how 
> Boost.Python does operator overloading.  My suspicion is that Python 
> itself doesn't allow that operator to be overloaded, but I could be wrong.

the python methods are:

__getitem__ __setitem___ and __delitem__

We probably only need to define the first two of them.  There may also 
be some issues to take into account to support slicing, but we could 
ignore those in the first pass at the interface.

-Allen

> 
>  -Patrick
> 
>>> To get around this, I have thought of two options:
>>>
>>>    1. Write C++ wrapper classes around all classes that store their
>>>       data internally as an array.  Access to the data values would be
>>>       granted through some member function that would just call
>>>       obj.mData[X] or whatever.
>>>    2. Add a getter method (not an overloaded operator) to the GMTL
>>>       classes in question.  For a matrix, the getter would take two
>>>       arguments.  For a vector, it would take one.  In other words, the
>>>       argument count would be dependent upon the (conceptual) dimensions
>>>       of the internal array.  I am reluctant to follow the model of
>>>       gmtl::Quat<T>::get(), however, because I think Boost.Python has a
>>>       limit to the number of parameters a method/function can take.  (I
>>>       strongly suspect it is tied to boost::function internally.)
>>>
>>> Option 1 isn't very good because I would actually have to write 
>>> wrappers for *everything* in GMTL, not just the data types.  Since 
>>> the wrapper classes couldn't be passed to GMTL functions directly, 
>>> wrappers would have to be written around those.  It might be possible 
>>> for Boost.Python to do some behind-the-scenes magic to make this 
>>> simpler, but I'm not sure.
>>>
>>> OTOH, I doubt that Option 2 will be well received by the readers of 
>>> this mailing list.  In fact, I doubt that anyone using GMTL in C++ 
>>> would even want to use a getter method when vec[2] is so much more 
>>> pleasing to the eye (for a staunch C++ programmer).
>>>
>>> With all of this in mind, I'd like to solict suggestions--or at least 
>>> get some general discussion on the topic.  I do not want to make 
>>> unilateral decisions about how GMTL is accessed from Python. 
>>> Futhermore, it's entirely possible that I am missing something in 
>>> Boost.Python or in GMTL that would simplify my efforts.
>>>
>>>  -Patrick
>>>
>>>
>>
>>
> 
> 


-- 
-- Allen Bierbaum                         al...@vr...
-- PhD Candidate             txtmsg - 515...@us...
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu

Re: [ggt-devel] Python interface to GMTL

[Patrick H. <pa...@13...>]

Allen Bierbaum wrote:
> Patrick Hartling wrote:
> 
>> I have spent many hours today working on exposing GMTL classes and 
>> functions for use with Python, and while I have made a ton of 
>> progress, I have reached something of an impasse.  While it is 
>> possible to instantiate and manipulate matrices, vectors, etc. in 
>> Python, it is not possible at this moment to read any data from them.  
>> The GMTL interface is built up around C++ data access idioms, and some 
>> of those (operator[] in particular) do not translate to Python.  The 
>> biggest issue I face is that there is no way (at this time) to map a 
>> C-style array to Python using Boost.Python.  Even if there were a way 
>> to do that, Python doesn't have a data structure with exactly the same 
>> semantics as a C-style array.  The only GMTL class that is even close 
>> to having its data be readable is gmtl::Matrix<>, and that's only 
>> because it overloads operator(), one of the few class operators that 
>> can be overloaded in Python.  Of course, I can't get the relevant 
>> Boost.Python code to compile, so the point is moot.
> 
> 
> Why can't we use python's [] operator?  Is there something about 
> Boost::Python that prevents this overload from taking place or is the 
> problem related to slicing?

I don't know how to overload that operator.  Pyste didn't do it 
automatically, and I have been having trouble making sense of how 
Boost.Python does operator overloading.  My suspicion is that Python 
itself doesn't allow that operator to be overloaded, but I could be wrong.

  -Patrick

>> To get around this, I have thought of two options:
>>
>>    1. Write C++ wrapper classes around all classes that store their
>>       data internally as an array.  Access to the data values would be
>>       granted through some member function that would just call
>>       obj.mData[X] or whatever.
>>    2. Add a getter method (not an overloaded operator) to the GMTL
>>       classes in question.  For a matrix, the getter would take two
>>       arguments.  For a vector, it would take one.  In other words, the
>>       argument count would be dependent upon the (conceptual) dimensions
>>       of the internal array.  I am reluctant to follow the model of
>>       gmtl::Quat<T>::get(), however, because I think Boost.Python has a
>>       limit to the number of parameters a method/function can take.  (I
>>       strongly suspect it is tied to boost::function internally.)
>>
>> Option 1 isn't very good because I would actually have to write 
>> wrappers for *everything* in GMTL, not just the data types.  Since the 
>> wrapper classes couldn't be passed to GMTL functions directly, 
>> wrappers would have to be written around those.  It might be possible 
>> for Boost.Python to do some behind-the-scenes magic to make this 
>> simpler, but I'm not sure.
>>
>> OTOH, I doubt that Option 2 will be well received by the readers of 
>> this mailing list.  In fact, I doubt that anyone using GMTL in C++ 
>> would even want to use a getter method when vec[2] is so much more 
>> pleasing to the eye (for a staunch C++ programmer).
>>
>> With all of this in mind, I'd like to solict suggestions--or at least 
>> get some general discussion on the topic.  I do not want to make 
>> unilateral decisions about how GMTL is accessed from Python. 
>> Futhermore, it's entirely possible that I am missing something in 
>> Boost.Python or in GMTL that would simplify my efforts.
>>
>>  -Patrick
>>
>>
> 
> 


-- 
Patrick L. Hartling			| Research Assistant, VRAC
pa...@13...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

Re: [ggt-devel] Python interface to GMTL

[Allen B. <al...@vr...>]

Patrick Hartling wrote:
> I have spent many hours today working on exposing GMTL classes and 
> functions for use with Python, and while I have made a ton of progress, 
> I have reached something of an impasse.  While it is possible to 
> instantiate and manipulate matrices, vectors, etc. in Python, it is not 
> possible at this moment to read any data from them.  The GMTL interface 
> is built up around C++ data access idioms, and some of those (operator[] 
> in particular) do not translate to Python.  The biggest issue I face is 
> that there is no way (at this time) to map a C-style array to Python 
> using Boost.Python.  Even if there were a way to do that, Python doesn't 
> have a data structure with exactly the same semantics as a C-style 
> array.  The only GMTL class that is even close to having its data be 
> readable is gmtl::Matrix<>, and that's only because it overloads 
> operator(), one of the few class operators that can be overloaded in 
> Python.  Of course, I can't get the relevant Boost.Python code to 
> compile, so the point is moot.

Why can't we use python's [] operator?  Is there something about 
Boost::Python that prevents this overload from taking place or is the 
problem related to slicing?

-Allen

> 
> To get around this, I have thought of two options:
> 
>    1. Write C++ wrapper classes around all classes that store their
>       data internally as an array.  Access to the data values would be
>       granted through some member function that would just call
>       obj.mData[X] or whatever.
>    2. Add a getter method (not an overloaded operator) to the GMTL
>       classes in question.  For a matrix, the getter would take two
>       arguments.  For a vector, it would take one.  In other words, the
>       argument count would be dependent upon the (conceptual) dimensions
>       of the internal array.  I am reluctant to follow the model of
>       gmtl::Quat<T>::get(), however, because I think Boost.Python has a
>       limit to the number of parameters a method/function can take.  (I
>       strongly suspect it is tied to boost::function internally.)
> 
> Option 1 isn't very good because I would actually have to write wrappers 
> for *everything* in GMTL, not just the data types.  Since the wrapper 
> classes couldn't be passed to GMTL functions directly, wrappers would 
> have to be written around those.  It might be possible for Boost.Python 
> to do some behind-the-scenes magic to make this simpler, but I'm not sure.
> 
> OTOH, I doubt that Option 2 will be well received by the readers of this 
> mailing list.  In fact, I doubt that anyone using GMTL in C++ would even 
> want to use a getter method when vec[2] is so much more pleasing to the 
> eye (for a staunch C++ programmer).
> 
> With all of this in mind, I'd like to solict suggestions--or at least 
> get some general discussion on the topic.  I do not want to make 
> unilateral decisions about how GMTL is accessed from Python. Futhermore, 
> it's entirely possible that I am missing something in Boost.Python or in 
> GMTL that would simplify my efforts.
> 
>  -Patrick
> 
> 


-- 
-- Allen Bierbaum                         al...@vr...
-- PhD Candidate             txtmsg - 515...@us...
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu

[ggt-devel] Python interface to GMTL

[Patrick H. <pa...@vr...>]

I have spent many hours today working on exposing GMTL classes and 
functions for use with Python, and while I have made a ton of progress, 
I have reached something of an impasse.  While it is possible to 
instantiate and manipulate matrices, vectors, etc. in Python, it is not 
possible at this moment to read any data from them.  The GMTL interface 
is built up around C++ data access idioms, and some of those (operator[] 
in particular) do not translate to Python.  The biggest issue I face is 
that there is no way (at this time) to map a C-style array to Python 
using Boost.Python.  Even if there were a way to do that, Python doesn't 
have a data structure with exactly the same semantics as a C-style 
array.  The only GMTL class that is even close to having its data be 
readable is gmtl::Matrix<>, and that's only because it overloads 
operator(), one of the few class operators that can be overloaded in 
Python.  Of course, I can't get the relevant Boost.Python code to 
compile, so the point is moot.

To get around this, I have thought of two options:

    1. Write C++ wrapper classes around all classes that store their
       data internally as an array.  Access to the data values would be
       granted through some member function that would just call
       obj.mData[X] or whatever.
    2. Add a getter method (not an overloaded operator) to the GMTL
       classes in question.  For a matrix, the getter would take two
       arguments.  For a vector, it would take one.  In other words, the
       argument count would be dependent upon the (conceptual) dimensions
       of the internal array.  I am reluctant to follow the model of
       gmtl::Quat<T>::get(), however, because I think Boost.Python has a
       limit to the number of parameters a method/function can take.  (I
       strongly suspect it is tied to boost::function internally.)

Option 1 isn't very good because I would actually have to write wrappers 
for *everything* in GMTL, not just the data types.  Since the wrapper 
classes couldn't be passed to GMTL functions directly, wrappers would 
have to be written around those.  It might be possible for Boost.Python 
to do some behind-the-scenes magic to make this simpler, but I'm not sure.

OTOH, I doubt that Option 2 will be well received by the readers of this 
mailing list.  In fact, I doubt that anyone using GMTL in C++ would even 
want to use a getter method when vec[2] is so much more pleasing to the 
eye (for a staunch C++ programmer).

With all of this in mind, I'd like to solict suggestions--or at least 
get some general discussion on the topic.  I do not want to make 
unilateral decisions about how GMTL is accessed from Python. 
Futhermore, it's entirely possible that I am missing something in 
Boost.Python or in GMTL that would simplify my efforts.

  -Patrick


-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@vr...                | 2624 Howe Hall: 1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/

[ggt-devel] gmtl::makeInverse()

[Patrick H. <pa...@vr...>]

Is there a reason that gmtl::makeInverse() (lines 1064-1070 of 
Generate.h) uses the Type2Type idiom?  Just from looking at it, it seems 
like there can be no ambiguity relating to overloading because the 
return type always matches the parameter type.  Am I missing something?

  -Patrick


P.S. I ask because the Type2Type thing doesn't work at all in languages 
without generics (at least AFAICT), and the fewer places I have to write 
wrappers, the better.


-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@vr...                | 2624 Howe Hall: 1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/