Re: Problem with the OOT forecast() method in Python

Hi George,

first a few words of caution. Python blocks are intended for quick tests
and incur a serious performance penalty. Thus, they are actually not
that well documented in terms of more advanced functionality. Given that
`forecast` is generally more of a performance optimization function,
this is not surprising.
It might be interesting to describe your issue in more detail. What are
you actually trying to do? Maybe the `forecast` method is not the thing
you actually need to implement.

Please refer to a default implementation for the Python `forecast` method:
https://github.com/gnuradio/gnuradio/blob/09930fdcc5c892eaff5754f6ef0203146bc1cca7/gnuradio-runtime/python/gnuradio/gr/gateway.py#L153

Also:
https://github.com/gnuradio/gnuradio/blob/09930fdcc5c892eaff5754f6ef0203146bc1cca7/gnuradio-runtime/python/gnuradio/gr/gateway.py#L336
This is another example how to implement the forecast method.

The implementations for sync, decimation, and interpolation blocks are
available and do not need to be implemented separately. This would only
be necessary for general blocks.

Cheers
Johannes

On 13.10.22 01:00, George Edwards wrote:
> Hi Jeff, thanks for bearing with me.
>
> When I retested the last approach just now upon receiving your email it
> works. Earlier, l forgot to take out some extraneous stuff in my code,
> which broke it. The code snippet I sent implies a one to one
> relationship between input and output. The forecaster does its job to
> ensure the number of input samples is at least the same size as the
> output, but in many instances the input is larger. This, however, will
> present a problem to the signal processing algorithm I have in mind
> which requires the post-pending samples (the size of my filter) to the
> end to the incoming data before upsampling. It seems the forecaster may
> be too loose in its input/output sample relationship and will mess up my
> algorithm.
>
> Anyway, if you have any thought on this and do not mind sharing I would
> appreciate it.
>
> Thank again for your assistance.
>
> George
>
> On Wed, Oct 12, 2022, 2:58 PM Jeff Long <willcode4@gmail.com
> <mailto:willcode4@gmail.com>> wrote:
>
> The last one looks correct, and would not have given the error you
> mention above. What happened?
>
> On Wed, Oct 12, 2022 at 4:49 PM George Edwards
> <gedwards.eng@gmail.com <mailto:gedwards.eng@gmail.com>> wrote:
>
> Hi Jeff, thank you very much for the response.
> I tries:
> ninput_items_required[0]=[noutput_items]
> ninput_items_required=[noutput_items]
> and
> return [noutput_items]
> None of these worked for me.
>
> Regards
> George
>
> On Wed, Oct 12, 2022, 8:07 AM Jeff Long <willcode4@gmail.com
> <mailto:willcode4@gmail.com>> wrote:
>
> For Python, the forecast() function should return a list,
> containing the number of items required for each input.
>
> On Wed, Oct 12, 2022 at 8:08 AM George Edwards
> <gedwards.eng@gmail.com <mailto:gedwards.eng@gmail.com>> wrote:
>
> Hello GNURadio Community,
>
> I am getting a TypeError when I fill in the code in the
> forecast() method in my Gnuradio OOT block design. I
> know, if I want to interpolate or decimate, I can simply
> pick the block type in the gr_modtool design menu,
> however, I would like to develop the capability to
> design my own. Here is how I fill in the forecast()
> method in Python to do either decimation or interpolation:
>
> ninput_items_required[0] = noutput_items*self.sps  # for
> decimation
> OR
> ninput_items_required[0] = noutput_items/self.sps  # for
> interpolation
>
> On running the flowgraph in GRC Console I see TypeError:
> 'int' object does not support item assignment.
>
> Will appreciate any suggestion to fix this problem.
>
> George
>