oder at eleks.lviv.ua
Sat Oct 6 10:53:41 MST 2007
----- Original Message -----
Subject: Re: [ODE] 0.9-rc1
Btw, do you know that there is
// dDEBUGMSG ("vector has zero size"); ... this message is annoying
commented in dNormalize3?
People prefer shutting their eyes to incorectness of their algorithms to
fixing them. :(
Yeah, that's a pretty horrible thing to do.
You know, I would not even mind to do a dIASSERT(l > 0) in the normalization routines.
I say: catch them early, and catch them hard!
Maybe we can get away with the assert now, because you improved the accuracy of the normalization process?
I just corrected normalization in one place which is in collision_trimesh_trimesh.cpp (a new file, which is not even built by default) and, moreover, it did not use dNormalize3 before. So, it is quite unlikely ;) that it was the reason for commenting the debug message.
As for measures - I'm also the adherent of hard measures. If validation fails, you should fix your code, not remove validation. So, adding dIASSERT() there is the easist thing to do :), but we need to know if it was commented because of internal problems in ODE or because of problems for the applications that use it. If the reason were external applications - let's put the assert in :)). If the reason was in ODE, who will fix it? ;)
Also, I did not tell you, but I've added boolean result for dNormalize*() functions. Now, when these functions return boolean it is illegal to put the assert into them. The assert should be placed after the calls, where the unsuccessful outcome is not acceptable. Or, another option is renaming current dNormalize*() to something like dTryNormalize*() and adding a wrapper which would call function with boolean result and issue the assert afterwards. That wrapper could be then named dNormalize*() to retain the original functionality.
-- Yahoo ID: oleh_derevenko
-- ICQ: 36361783
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ODE