Hi Nathan,
> I think it's more of a testament to how good Intel (and modern)
> processors are at branching.
wow!
> An adventurous soul is welcome to try putting that table lookup in to
> an avx2 protokernel with the new gather instructions.
I am adventurous, but that sounds like a hard beer, since
I think it's more of a testament to how good Intel (and modern) processors
are at branching.
An adventurous soul is welcome to try putting that table lookup in to an
avx2 protokernel with the new gather instructions. I'll reward with beer
next time I see the author. If you write a generic table
Hi all,
Thank you very much in advance.
I find the result of the block "complex to Arg" is same to the
result in matlab most of the time,while sometimes the results is different
from the result in matlab.
For example,
a=1.646236600879293e+03 +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Could you extend a test case for this block with Python? This might
reveal issues with the implementation more easily. Also, others might
benefit from it.
For your specific problem, I guess the GR block result is as close as
it gets for a
Hi Johannes, Hi xd,
complex_to_arg uses GNU Radio's fast_atan2f function, which is an
approximation [1].
Between the 255 values of the lookup table, it uses linear
interpolation, hence your 0.4 error factor.
As Johannes said, that's not really surprising for a look up table-based
approach.
I do
