Re: [Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled

[Martin Braun]

On 03/11/2014 03:30 PM, David Halls wrote:
> Thanks Martin, this is clear and makes sense. I should have read the
> numpy data types more thoroughly and worked it out. Anyway...
> 
> My collaborators are writing their Wireless Network Coding bits in
> Python. Once I get this block working, I can combined it with the relay
> work I was doing and we will have a pretty exciting setup to report!! :)

That is very interesting to hear -- I hope you'll be publishing some
papers and code around network coding!

> I have one more problem though...
> 
> I have
> 
> "out_bA1 = output_items[0]
> 
> ...
> ...code
> ...
> 
> out_bA1[0:len(est_bA1m)] = est_bA1m"
> 
> where
> 
> out_bA1.shape = (1,)
> est_bA1m.shape = (3840,)
> 
> I get the error " output operand requires a reduction, but reduction is
> not enabled"
> 
> *Sometimes* I get
> 
> out_bA1.shape = (2,)
> est_bA1m.shape = (3840,)
> 
> and I get the error "operands could not be broadcast together with
> shapes (2) (3840)"
> 
> I wondered if the problem is with 'forecast' (which I have not changed
> since the template was created by gr_modtool) or having to
> set_output_multiple? The scheduling aspect of GNU radio seems complex.

This is a Python error, basically it's saying that the arrays have the
wrong shapes.

Note that in your example, out_bA1 has a limited size before you do any
assigning. Make sure you stay within valid index ranges.

If you want to do it very fool-proof (albeit ugly), try:

for i in range(len(out_bA1)):
    out_bA1[i] = # whatever
    if i (matches whatever condition):
        break

> If I use
> 
> " out_bA1 = est_bA1m"
> 
> Then it *runs* OK, but the output of the block i.e. output_items[0] is
> then no longer altered and 0's are output.

That's because you're rebinding out_bA1, and the original buffer is not
written to.

MB
> 
> Many thanks,
> 
> David
> 
> 
> -----Original Message-----
> From: address@hidden
> <mailto:address@hidden>
> [mailto:address@hidden
> On Behalf Of Martin Braun
> Sent: 11 March 2014 08:33
> To: address@hidden <mailto:address@hidden>
> Subject: Re: [Discuss-gnuradio] Python block, itemsize mismatch
> 
> On 03/11/2014 02:06 AM, David Halls wrote:
>> You're a genius! It works.
>>
>> Interestingly for a float it requires numpy.float32 or a similar error
>> occurs.
> 
> Yes, in GNU Radio we consistently use 32-bit floats. A complex value
> consists of two of these, hence the 64 bits.
> 
> Note that this is just for buffers. A lot of blocks use double
> internally (i.e. 64-bit float, or 128-bit complex) for accuracy reason.
> However, for signals, it's just a waste of bandwidth (most of time, SNR
> will trump quantization noise anyway).
> 
> M
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden <mailto:address@hidden>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ________________________________
> 
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read, copied
> and used only by the intended recipient. If you are not the intended
> recipient, please destroy this message, delete any copies held on your
> system and notify the sender immediately.
> 
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
> <http://www.toshiba.eu/research/trl>
> 
> 
> ------------------------------------------------------------------------
> This email has been scanned for email related threats and delivered
> safely by Mimecast.
> For more information please visit http://www.mimecast.com
> ------------------------------------------------------------------------