Python pass parameter as const *gr_complex?

GNU Radio
1

Hi list,

I am trying to use the gr::digital::constellation::decision_maker(.)
method from python, but I get an error message.
In order to reproduce call in python:

import gnuradio.digital
a = gnuradio.digital.constellation_qpsk()
b = complex(1+1j)
a.decision_maker(b)
=> TypeError […] argument 2 of type ‘gr_complex const*’
The C+±implementation is wrapped by SWIG, where the error occurs.

This might be a silly question, but what am I doing wrong?

Thanks for any help.

Best regards

Stephan Ludwig

Robert Bosch GmbH
Corporate Sector Research & Advance Engineering, Communication
Technology (CR/AEH4)
Renningen
70465 Stuttgart
GERMANY
www.bosch.comhttp://www.bosch.com

Tel. +49(711)811-8809
Fax +49(711)811-1052
Mobile +49(172)5630639
[email protected]mailto:[email protected]

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart,
HRB 14000;
Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors:
Dr. Volkmar Denner,
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr.
Dirk Hoheisel, Christoph Kbel,
Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller

2

On Wed, Jan 7, 2015 at 7:57 AM, Ludwig Stephan (CR/AEH4) <
[email protected]> wrote:

=> TypeError […] argument 2 of type ‘gr_complex const*’
The C+±implementation is wrapped by SWIG, where the error occurs.

This might be a silly question, but what am I doing wrong?

Thanks for any help.

Best regards

Stephan Ludwig

Hi Stephan,

You’re not doing anything wrong per se, but the block isn’t really meant
to
be used that way. SWIG needs to be told how to handle some types of
argument formats, and it hasn’t been told how to handle this one.

The post 3.7 way we’ve been handling SWIG is to just include the public
.h
file as the interface, so all methods are exported into SWIG. A class
like
this needs that method to be public for use as a contained object in the
block that calls it, but it’s not really meant for use outside like
this.
Not that it couldn’t be, but you’d have to work with SWIG to let it
understand how to call that function with the proper input type.

Tom

3

Thank you, Tom, for your enlightening answer. Please let me ask two
additional questions:

  1. If I understood your explanation correctly, as a consequence of this,
    one could not use the decision_maker method within a block, which is
    coded solely in python. Right?

  2. Isn’t “const gr_complex*” a type, which is used very often in the
    block I/O interfaces, and shouldn’t, thus, the GR configuration of SWIG
    already let it know how to translate python/complex to gr_complex?

Best regards

Stephan Ludwig

Robert Bosch GmbH
Corporate Sector Research & Advance Engineering, Communication
Technology (CR/AEH4)
Renningen
70465 Stuttgart
GERMANY

Tel. +49(711)811-8809
Fax +49(711)811-1052
Mobile +49(172)5630639
[email protected]

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart,
HRB 14000;
Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors:
Dr. Volkmar Denner,
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr.
Dirk Hoheisel, Christoph Kübel,
Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller
Von: [email protected] [mailto:[email protected]] Im Auftrag von
Tom R.
Gesendet: Dienstag, 20. Januar 2015 15:57
An: Ludwig Stephan (CR/AEH4)
Cc: [email protected]
Betreff: Re: [Discuss-gnuradio] Python pass parameter as const
*gr_complex?

On Wed, Jan 7, 2015 at 7:57 AM, Ludwig Stephan (CR/AEH4)
[email protected] wrote:
Hi list,

I am trying to use the gr::digital::constellation::decision_maker(.)
method from python, but I get an error message.
In order to reproduce call in python:

import gnuradio.digital
a = gnuradio.digital.constellation_qpsk()
b = complex(1+1j)
a.decision_maker(b)
=> TypeError […] argument 2 of type ‘gr_complex const*’
The C+±implementation is wrapped by SWIG, where the error occurs.

This might be a silly question, but what am I doing wrong?

Thanks for any help.

Best regards

Stephan Ludwig

Hi Stephan,

You’re not doing anything wrong per se, but the block isn’t really meant
to be used that way. SWIG needs to be told how to handle some types of
argument formats, and it hasn’t been told how to handle this one.

The post 3.7 way we’ve been handling SWIG is to just include the public
.h file as the interface, so all methods are exported into SWIG. A class
like this needs that method to be public for use as a contained object
in the block that calls it, but it’s not really meant for use outside
like this. Not that it couldn’t be, but you’d have to work with SWIG to
let it understand how to call that function with the proper input type.

Tom

4

On Wed, Jan 21, 2015 at 3:13 AM, Ludwig Stephan (CR/AEH4) <
[email protected]> wrote:

Thank you, Tom, for your enlightening answer. Please let me ask two
additional questions:

  1. If I understood your explanation correctly, as a consequence of this,
    one could not use the decision_maker method within a block, which is coded
    solely in python. Right?

Correct.

  1. Isn’t “const gr_complex*” a type, which is used very often in the block
    I/O interfaces, and shouldn’t, thus, the GR configuration of SWIG already
    let it know how to translate python/complex to gr_complex?

No. That type is almost never used. What is often used is “const
std::vector<gr_complex>”. But again, this class was designed to be
called
from within a block’s work function, so the data structure would have
already been a “const gr_complex*” (casting the input_items argument).

Tom

5

Hi Tom,

thank you for clarification. The problem arose, when I wanted to use the
method from within a pythonblock’s work function. But I understood,
that this is not possible (a.t.m.), and I will write a C++ clock, which
should perform better anyways :wink:

Best regards

Stephan Ludwig

Robert Bosch GmbH
Corporate Sector Research & Advance Engineering, Communication
Technology (CR/AEH4)
Renningen
70465 Stuttgart
GERMANY
www.bosch.comhttp://www.bosch.com

Tel. +49(711)811-8809
Fax +49(711)811-1052
Mobile +49(172)5630639
[email protected]mailto:[email protected]

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart,
HRB 14000;
Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors:
Dr. Volkmar Denner,
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr.
Dirk Hoheisel, Christoph Kübel,
Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller
Von: [email protected] [mailto:[email protected]] Im Auftrag von
Tom R.
Gesendet: Mittwoch, 21. Januar 2015 14:50
An: Ludwig Stephan (CR/AEH4)
Cc: [email protected]
Betreff: Re: [Discuss-gnuradio] Python pass parameter as const
*gr_complex?

On Wed, Jan 21, 2015 at 3:13 AM, Ludwig Stephan (CR/AEH4)
<[email protected]mailto:[email protected]>
wrote:
Thank you, Tom, for your enlightening answer. Please let me ask two
additional questions:

  1. If I understood your explanation correctly, as a consequence of this,
    one could not use the decision_maker method within a block, which is
    coded solely in python. Right?

Correct.

  1. Isn’t “const gr_complex*” a type, which is used very often in the
    block I/O interfaces, and shouldn’t, thus, the GR configuration of SWIG
    already let it know how to translate python/complex to gr_complex?

No. That type is almost never used. What is often used is “const
std::vector<gr_complex>”. But again, this class was designed to be
called from within a block’s work function, so the data structure would
have already been a “const gr_complex*” (casting the input_items
argument).

Tom

Best regards

Stephan Ludwig

Robert Bosch GmbH
Corporate Sector Research & Advance Engineering, Communication
Technology (CR/AEH4)
Renningen
70465 Stuttgart
GERMANY
www.bosch.comhttp://www.bosch.com

Tel. +49(711)811-8809tel:%2B49(711)811-8809
Fax +49(711)811-1052tel:%2B49(711)811-1052
Mobile +49(172)5630639tel:%2B49(172)5630639
[email protected]mailto:[email protected]

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart,
HRB 14000;
Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors:
Dr. Volkmar Denner,
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr.
Dirk Hoheisel, Christoph Kübel,
Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller
Von: [email protected]mailto:[email protected]
[mailto:[email protected]mailto:[email protected]] Im Auftrag
von Tom R.
Gesendet: Dienstag, 20. Januar 2015 15:57
An: Ludwig Stephan (CR/AEH4)
Cc: [email protected]mailto:[email protected]
Betreff: Re: [Discuss-gnuradio] Python pass parameter as const
*gr_complex?

On Wed, Jan 7, 2015 at 7:57 AM, Ludwig Stephan (CR/AEH4)
<[email protected]mailto:[email protected]>
wrote:
Hi list,

I am trying to use the gr::digital::constellation::decision_maker(.)
method from python, but I get an error message.
In order to reproduce call in python:

import gnuradio.digital
a = gnuradio.digital.constellation_qpsk()
b = complex(1+1j)
a.decision_maker(b)
=> TypeError […] argument 2 of type ‘gr_complex const*’
The C+±implementation is wrapped by SWIG, where the error occurs.

This might be a silly question, but what am I doing wrong?

Thanks for any help.

Best regards

Stephan Ludwig

Hi Stephan,

You’re not doing anything wrong per se, but the block isn’t really meant
to be used that way. SWIG needs to be told how to handle some types of
argument formats, and it hasn’t been told how to handle this one.

The post 3.7 way we’ve been handling SWIG is to just include the public
.h file as the interface, so all methods are exported into SWIG. A class
like this needs that method to be public for use as a contained object
in the block that calls it, but it’s not really meant for use outside
like this. Not that it couldn’t be, but you’d have to work with SWIG to
let it understand how to call that function with the proper input type.

Tom