On Thu, Aug 14, 2014 at 9:25 AM, Daniele Nicolodi <[email protected]> wrote:
> On 14/08/2014 15:10, Tom Rondeau wrote: > > On Thu, Aug 14, 2014 at 5:15 AM, Daniele Nicolodi <[email protected] > > <mailto:[email protected]>> 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 > > I don't think that it's academic at all. We're dealing with processing noisy signals here, often coming at us very quickly. We work in the tradeoff space between speed and performance and try to balance them well. This isn't like Matlab with double-precision math. In this case, the complexity of the atan function is really high. Meanwhile, I just pulled up my old tests, and the maximum error between fast_atan2f and atan2f is 0.00194 radians. I'm curious what application you are using that's requiring that level of precision? And what noiseless environment you are in where you can make that determination? As for the documentation: yes, I'm always in favor of adding information to the documentation to make things more clear. Tom
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
