On 14/08/2014 15:10, Tom Rondeau wrote: > On Thu, Aug 14, 2014 at 5:15 AM, Daniele Nicolodi <dani...@grinta.net > <mailto:dani...@grinta.net>> wrote: > > On 13/08/2014 16:37, Tom Rondeau wrote: > > The version we have in there is much (MUCH) faster than the libm atan2 > > function. So yes, we trade off a bit of error for a massive > > computational gain. The error is very small from what I recall, expect > > in a few instances (near 0 or near pi/2 or something like that). > Having > > a graph of the error somewhere would be helpful. > > I think it depends on the point of view, for me it is a bit of > computational gain for a massive error :) > > You say "massive error", but I've plotted the error between the fast > atan and the libm atan function before and have not noticed any error to > be "massive". On the other hand, the "bit" of computational gain is, > indeed, quite a lot.
I was trying to stress that the speed vs correctness tradeoff should be evaluated case by case on the base of the requirements and limitations and that the results of this evaluation may be quite different depending on the situation. Indeed in my current project I'm using both the fast atan and the libm atan to compute different hings in the same flow-graph (for a PLL loop the linear approximation for small angles is perfectly fine, not so much for other measurements). I may have completely wrong expectations, but I'm used to mathematical functions that, if not specified, return results exact within the precision of the number representation used. Any optimization trading precision for speed should be documented. I think we agree on that. The remaining discussion is purely academic :) Cheers, Daniele _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
