On Wed, Sep 21, 2011 at 12:26 AM, Josh Blum
<address@hidden> wrote:
> 1:I need to ask that is there some way to make a block using Python
> Scientific Libraries e.g. scipy instead of writing in C++?
>
Yes, I think the best way is to make a hier block w/ message source,
message sink and a thread. The thread pops messages, performs the numpy
operation, then pushes messages.
There are some blocks in grc/grc_gnuradio/blks2 that work like this. You
can use them as an example.
As Josh said, you can definitely do it, but I wouldn't really recommend it. While I use scipy all the time, it's not a real performance powerhouse. So doing things this way will lose you a lot of speed. But if it's for testing and development purposes and that's what you're comfortable with, go for it.
> 2:There are many complex signal processing blocks e.g. Phase, Frequency
> and symbol Synchronization etc but i am unable to find
> basic programming operators e.g. > or < etc and implementation of basic
> math function e.g. exponential and hypergeometric is available in
> python "cmath" but exponential/hypergeometric is not in GRC.
>
Well, there is gr_max_xx for comparison which takes the max of all inputs.
I just recently made gr_transcendental to take care of various cmath
functions:
http://gnuradio.org/cgit/jblum.git/commit/?h=transcendental&id=deb78591edbfd3cbabfbdafdc30d12678165f20c
What blocks can you think of? Make a list and put it somewhere like a
wiki page or in the bug tracker so we dont forget. (login is guest:gnuradio)
Since we are currently splitting gnuradio-core into smaller components.
I am thinking about a gr-math component to handle the primitive math
operations. This would include standard math operator blocks, binary
operator blocks, transcendental functions in cmath, other misc, and
possibly a bunch of python based blocks that call into numpy functions
(just to cover everything, but w/ the ease of python).
Let's make sure to bring that up as part of the conversation during the next developers call. It sounds like the right thing to do. My only concern is that by starting to segment the code into this smaller modules, we make _too_ many modules that people start getting confused about. Still, math is math, and it probably makes sense to put them into their own domain.
Tom