Re: [Discuss-gnuradio] volk float32->int8 kernel and thus float_to_char block round or floor, depending on VOLK machine

Hi again, I just realised an internal inconsistency in what I wrote, and had to dig a bit deeper still: In Volk, float to int has two behaviours, like described below. But the Float->Int block does not call the Volk routines. Instead, it calls float_array_to_int, which in turn calls

Re: [Discuss-gnuradio] volk float32->int8 kernel and thus float_to_char block round or floor, depending on VOLK machine

Hi again, Ugh, you're right. When looking at the Volk libraries, I find: Int: int() for generic, like rintf() with acceleration Short: always rintf() Char: int() for generic, like rintf() with acceleration but occasionally int(). The thing that puzzled me is that I cannot get GnuRadio to

Re: [Discuss-gnuradio] volk float32->int8 kernel and thus float_to_char block round or floor, depending on VOLK machine

Oh wait, it gets better: while the float->int16 does indeed use rintf, float->int32 doesn't… now we don't have a majority situation pro- rounding anymore… argh. On Sat, 2018-06-09 at 19:24 +, Müller, Marcus (CEL) wrote: > Hi Paul, > > I agree with everything you say. Float to char should

Re: [Discuss-gnuradio] volk float32->int8 kernel and thus float_to_char block round or floor, depending on VOLK machine

Hi Paul, I agree with everything you say. Float to char should behave *exactly* like float to int and short. Will fix it in that way. Will also have a truncating version, maybe. I've just added 3 lines of code to the current implementation to demonstrate it's trivial to change the rounding mode.

Re: [Discuss-gnuradio] volk float32->int8 kernel and thus float_to_char block round or floor, depending on VOLK machine

Hi Marcus, I would prefer that when going from float to int, every 'bin' should have equal size. So I can think of two ways to do that: 1) zero corresponds to [-0.5 : 0.4999] or 2) zero corresponds to [0.0 : 0.99] whereas the 'generic' optimization does 3) zero corresponds to [-1

[Discuss-gnuradio] volk float32->int8 kernel and thus float_to_char block round or floor, depending on VOLK machine (was: Re: Incorrect quantizations when converting from float to char)

Hi Paul, yes, this seems to be the case where the "naive" C implementation behaves differently from all the SIMD ones: As far as I know – but I'm desparately looking for any standards document that specifies that – doing a int8_t val = (int8_t) 8.8f; will always lead to 8, whereas int8_t

Re: [Discuss-gnuradio] Incorrect quantizations when converting from float to char

Hi Marcus, Just reran the test after editing volk_config, and the result is somewhat surprising: Every float in [-1:1] now converts to zero. Every float in [1:2] now converts to 1. Whereas it should be [-0.5:0.5] and [0.5:1.5]. It seems that most of the time, the u_sse2 converter is used,

Re: [Discuss-gnuradio] Incorrect quantizations when converting from float to char

I can reproduce these, but do the errors disappear for you if you replace "u_sse2 u_sse2" with "generic generic" on that line? Best regards, Marcus On Sat, 2018-06-09 at 18:04 +0200, Paul Boven wrote: > Hi Marcus, > > This machine did not yet have a volk_config when I ran these tests. > > I

Re: [Discuss-gnuradio] Incorrect quantizations when converting from float to char

Hi Marcus, This machine did not yet have a volk_config when I ran these tests. I have since run volk_profile and rebooted, and the Float->Char quantization bug still occurs. $ volk-config-info --machine avx2_64_mmx_orc $ grep volk_32f_s32f_convert_8i .volk/volk_config

Re: [Discuss-gnuradio] Incorrect quantizations when converting from float to char

If possible, please track progress on https://github.com/gnuradio/volk/issues/188 On Sat, 2018-06-09 at 15:30 +, Müller, Marcus (CEL) wrote: > Hi Paul, > > hm, OK, considering the actual conversion is done in VOLK, can you > tell > us > > * whether ~/.volk/volk_config exists (and if so, its

Re: [Discuss-gnuradio] Incorrect quantizations when converting from float to char

Hi Paul, hm, OK, considering the actual conversion is done in VOLK, can you tell us * whether ~/.volk/volk_config exists (and if so, its contents regarding volk_32f_s32f_convert_8i ) * what the output of `volk-config-info --machine` is? Thanks, Marcus On Sat, 2018-06-09 at 17:13 +0200, Paul

[Discuss-gnuradio] [GSoC18] gr-modtool overhaul: Blog Post for the week

Hello everyone, the blog post for the week 4 has been updated with the tasks for the upcoming week. Here is the link to the updated Github project. Thanks, Swapnil Negi Indian

Re: [Discuss-gnuradio] Bug in fmdet_cf_imp.cc

> From: Eugene Grayver > Subject: [Discuss-gnuradio] Bug in fmdet_cf_imp.cc > Date: Fri, 8 Jun 2018 18:48:56 + > > Hello, > > > > There is a bug in the FM demod. Unbelievably (almost), I reported a > bug in the same line a couple of years ago. At that time I also >

Re: [Discuss-gnuradio] Bug in fmdet_cf_imp.cc

Hello Eugene, Thanks! I.. uh. wat?! There's a lot of interesting things in the code of that block. d_8 being a constant with value 8 not being the largest surprise; I see that this should be a derivative-approximating filter, right, which inherently needs to have high-pass characteristics, and

Re: [Discuss-gnuradio] GNU Radio not installing: Build Failed

Hello Jason and Derek! What Derek wrote very much sums up what is going on in my head; I should probably write that down. So, knowing fully this is everything but an official announcement, 3.8 will need C++11. Just wanted to confirm that. On the way to 3.8, we'll thus need to "weed out" the

[Discuss-gnuradio] SDRA 2018 videos online

Dear list,  the recordings of this year's SDRA in Friedrichshafen are now available in our Youtube channel.  Alltogether we have 71 recordings from talks, mainly on SDR topics. We're proud to welcome our subscriber #1000, which shows that we're meeting a demand. Please also feel invited to