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          \/  __    \/
                                                   \__     
                                            \_\