|Subject:||Re: [Discuss-gnuradio] blocks.complex_to_arg() implementation|
|Date:||Thu, 14 Aug 2014 11:31:15 -0400|
On 14/08/2014 15:10, Tom Rondeau wrote:
> On Thu, Aug 14, 2014 at 5:15 AM, Daniele Nicolodi <address@hidden
> <mailto:address@hidden>> wrote:I was trying to stress that the speed vs correctness tradeoff should be
> 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).
> > 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.
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 :)
|[Prev in Thread]||Current Thread||[Next in Thread]|