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

[Paul Boven]

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 llrintf().


https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/float_array_to_int.cc

So both the Float->Int and Float->Short cases will always use actual 
rounding, and the odd one out seems to be the Float->Char 'generic' case.


And with Volk you normally wouldn't even hit the 'generic' case, but the 
sse2 (and other cases) repeat the code from the 'generic' case to 
convert any remainders that won't suffice to start a new accelerated block.


Regards, Paul Boven.

On 10/06/2018 00:20, Paul Boven wrote:

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 show 
different behaviour for the Float->Int case, whereas a small test 
program does show different behaviour depending on what's in 
.volk/volk_config.


That mystery is easily solved, because the use of Volk is commented out 
in the float_to_int block:


https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/float_to_int_impl.cc 



// Disable the Volk for now. There is a problem for large 32-bit ints that
// are not properly represented by the precisions of a single float, which
// can cause wrapping from large, positive numbers to negative.
// In gri_float_to_int, the value is first promoted to a 64-bit
// value, clipped, then converted to a float.

Regards, Paul Boven.

On 06/09/2018 09:26 PM, Müller, Marcus (CEL) wrote:

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 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. X87 FPUs are darn mighty things.

This brings me to another aspect: As far as I can tell from this
height
is that VOLK code absolutely neglects to configure the FPU to a known
state. If the calling thread decides to do a

_MM_SET_ROUNDING_MODE(_MM_ROUND_TOWARD_ZERO);

before calling volk_32f_s32f_convert_8i, all the kernels behave like
the truncate-to-0 generic kernel. That can't be what we want, nor is
it
documented.

So, that's a bigger issue with VOLK: on one hand, we'd want to set
that
SIMD FPU control register (MXCSR) on every entry into a volk kernel
that uses rounding, under- or overflowing SIMD intrinsics to have
defined behaviour. Since we are nice programmers, we don't want to
have
surprising side effects, so we'd restore it to its original state on
exit... I see pipeline flush and performance bottleneck right there,
but it's IA64 calling convention to save and restore as callee.

Best regards,
Marcus
On Sat, 2018-06-09 at 20:18 +0200, Paul Boven wrote:

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 to 0.99]

The second was actually the behaviour I was expecting, and I was
pleasantly surprised when GnuRadio seemed to do the first - but
then
occasionally it doesn't.

I just did a quick test in python3, and there, the range of int(x)
for
zero runs [-0.99 : 0.99], so I'm expecting most
programming
languages to behave that way.

So, I guess a programmer would expect the behaviour as in the
third
case. Someone who is converting radio signals might want either
the
first or second case, as otherwise you end up with some
interesting
non-linearities.

The gnuplot helpfile states: " The `int(x)` function returns the
integer
part of its argument, truncated toward zero."

But gnuplot also provides functions like 'floor(x)' and ceil(x).

So the real question is still, do we want the behaviour of int(x),
or
the behaviour that an analog to digital converter would have?

Finally, I'd say we want the behaviour to be the same for Int,
Short
and
Char. So I ran a few more tests.

With Volk enabled, Float to Int, Short and Char treat [-0.5 :
0.49]
as zero, with the occasional glitch for Char.

volk_32f_s32f_convert_16i a_avx u_avx
volk_32f_s32f_convert_32i a_avx u_sse2

With these conversions for Int and Short also switched to 'generic
generic', I get the same results:

Short zero: [-0.5 : 0.49]
Int zero:   [-0.5 : 0.49

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

[Paul Boven]

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 show 
different behaviour for the Float->Int case, whereas a small test 
program does show different behaviour depending on what's in 
.volk/volk_config.


That mystery is easily solved, because the use of Volk is commented out 
in the float_to_int block:


https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/float_to_int_impl.cc

// Disable the Volk for now. There is a problem for large 32-bit ints that
// are not properly represented by the precisions of a single float, which
// can cause wrapping from large, positive numbers to negative.
// In gri_float_to_int, the value is first promoted to a 64-bit
// value, clipped, then converted to a float.

Regards, Paul Boven.

On 06/09/2018 09:26 PM, Müller, Marcus (CEL) wrote:

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 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. X87 FPUs are darn mighty things.

This brings me to another aspect: As far as I can tell from this
height
is that VOLK code absolutely neglects to configure the FPU to a known
state. If the calling thread decides to do a

_MM_SET_ROUNDING_MODE(_MM_ROUND_TOWARD_ZERO);

before calling volk_32f_s32f_convert_8i, all the kernels behave like
the truncate-to-0 generic kernel. That can't be what we want, nor is
it
documented.

So, that's a bigger issue with VOLK: on one hand, we'd want to set
that
SIMD FPU control register (MXCSR) on every entry into a volk kernel
that uses rounding, under- or overflowing SIMD intrinsics to have
defined behaviour. Since we are nice programmers, we don't want to
have
surprising side effects, so we'd restore it to its original state on
exit... I see pipeline flush and performance bottleneck right there,
but it's IA64 calling convention to save and restore as callee.

Best regards,
Marcus
On Sat, 2018-06-09 at 20:18 +0200, Paul Boven wrote:

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 to 0.99]

The second was actually the behaviour I was expecting, and I was
pleasantly surprised when GnuRadio seemed to do the first - but
then
occasionally it doesn't.

I just did a quick test in python3, and there, the range of int(x)
for
zero runs [-0.99 : 0.99], so I'm expecting most
programming
languages to behave that way.

So, I guess a programmer would expect the behaviour as in the
third
case. Someone who is converting radio signals might want either
the
first or second case, as otherwise you end up with some
interesting
non-linearities.

The gnuplot helpfile states: " The `int(x)` function returns the
integer
part of its argument, truncated toward zero."

But gnuplot also provides functions like 'floor(x)' and ceil(x).

So the real question is still, do we want the behaviour of int(x),
or
the behaviour that an analog to digital converter would have?

Finally, I'd say we want the behaviour to be the same for Int,
Short
and
Char. So I ran a few more tests.

With Volk enabled, Float to Int, Short and Char treat [-0.5 :
0.49]
as zero, with the occasional glitch for Char.

volk_32f_s32f_convert_16i a_avx u_avx
volk_32f_s32f_convert_32i a_avx u_sse2

With these conversions for Int and Short also switched to 'generic
generic', I get the same results:

Short zero: [-0.5 : 0.49]
Int zero:   [-0.5 : 0.49]

So, assuming I carried out these tests correctly, the odd one out
seems
to be the generic case for float to char conversion.

Note that Volk in the 16 bit and 32 bit case uses a function
called
'rintf' in the conversions. From its manpage:

"(...) round  their argument  to  an integer value in floating-
point
format".

So I say this boils down to a bug in the 'generic' float to char
case.

This is not a fix to make lightly, because somebody is going to
have
their flowchart break because of this. Then again, in the current
situation the outcome depends on which optimizations your machine
happens to have available, so that's also quite bad.

Possibly there is also an optimization opportunity of never using
'generic' even at the block edge when acceleration is available by
choosing the right size of bloc

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

[CEL]

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 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. X87 FPUs are darn mighty things.
> 
> This brings me to another aspect: As far as I can tell from this
> height
> is that VOLK code absolutely neglects to configure the FPU to a known
> state. If the calling thread decides to do a   
> 
> _MM_SET_ROUNDING_MODE(_MM_ROUND_TOWARD_ZERO);
> 
> before calling volk_32f_s32f_convert_8i, all the kernels behave like
> the truncate-to-0 generic kernel. That can't be what we want, nor is
> it
> documented.
> 
> So, that's a bigger issue with VOLK: on one hand, we'd want to set
> that
> SIMD FPU control register (MXCSR) on every entry into a volk kernel
> that uses rounding, under- or overflowing SIMD intrinsics to have
> defined behaviour. Since we are nice programmers, we don't want to
> have
> surprising side effects, so we'd restore it to its original state on
> exit... I see pipeline flush and performance bottleneck right there,
> but it's IA64 calling convention to save and restore as callee. 
> 
> Best regards,
> Marcus
> On Sat, 2018-06-09 at 20:18 +0200, Paul Boven wrote:
> > 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 to 0.99]
> > 
> > The second was actually the behaviour I was expecting, and I was 
> > pleasantly surprised when GnuRadio seemed to do the first - but
> > then 
> > occasionally it doesn't.
> > 
> > I just did a quick test in python3, and there, the range of int(x)
> > for 
> > zero runs [-0.99 : 0.99], so I'm expecting most
> > programming 
> > languages to behave that way.
> > 
> > So, I guess a programmer would expect the behaviour as in the
> > third 
> > case. Someone who is converting radio signals might want either
> > the 
> > first or second case, as otherwise you end up with some
> > interesting 
> > non-linearities.
> > 
> > The gnuplot helpfile states: " The `int(x)` function returns the
> > integer 
> > part of its argument, truncated toward zero."
> > 
> > But gnuplot also provides functions like 'floor(x)' and ceil(x).
> > 
> > So the real question is still, do we want the behaviour of int(x),
> > or 
> > the behaviour that an analog to digital converter would have?
> > 
> > Finally, I'd say we want the behaviour to be the same for Int,
> > Short
> > and 
> > Char. So I ran a few more tests.
> > 
> > With Volk enabled, Float to Int, Short and Char treat [-0.5 :
> > 0.49] 
> > as zero, with the occasional glitch for Char.
> > 
> > volk_32f_s32f_convert_16i a_avx u_avx
> > volk_32f_s32f_convert_32i a_avx u_sse2
> > 
> > With these conversions for Int and Short also switched to 'generic 
> > generic', I get the same results:
> > 
> > Short zero: [-0.5 : 0.49]
> > Int zero:   [-0.5 : 0.49]
> > 
> > So, assuming I carried out these tests correctly, the odd one out
> > seems 
> > to be the generic case for float to char conversion.
> > 
> > Note that Volk in the 16 bit and 32 bit case uses a function
> > called 
> > 'rintf' in the conversions. From its manpage:
> > 
> > "(...) round  their argument  to  an integer value in floating-
> > point 
> > format".
> > 
> > So I say this boils down to a bug in the 'generic' float to char
> > case.
> > 
> > This is not a fix to make lightly, because somebody is going to
> > have 
> > their flowchart break because of this. Then again, in the current 
> > situation the outcome depends on which optimizations your machine 
> > happens to have available, so that's also quite bad.
> > 
> > Possibly there is also an optimization opportunity of never using 
> > 'generic' even at the block edge when acceleration is available by 
> > choosing the right size of blocks, but that's probably a small
> > gain.
> > 
> > Regards, Paul Boven.
> > 
> > 
> > 
> > On 06/09/2018 07:18 PM, Müller, Marcus (CEL) wrote:
> > > 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 val = (int8_t) -8.8f;
> > > 
> > > would always lead to -8.
> > > 
> > > Now, for 

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

[CEL]

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. X87 FPUs are darn mighty things.

This brings me to another aspect: As far as I can tell from this height
is that VOLK code absolutely neglects to configure the FPU to a known
state. If the calling thread decides to do a   

_MM_SET_ROUNDING_MODE(_MM_ROUND_TOWARD_ZERO);

before calling volk_32f_s32f_convert_8i, all the kernels behave like
the truncate-to-0 generic kernel. That can't be what we want, nor is it
documented.

So, that's a bigger issue with VOLK: on one hand, we'd want to set that
SIMD FPU control register (MXCSR) on every entry into a volk kernel
that uses rounding, under- or overflowing SIMD intrinsics to have
defined behaviour. Since we are nice programmers, we don't want to have
surprising side effects, so we'd restore it to its original state on
exit... I see pipeline flush and performance bottleneck right there,
but it's IA64 calling convention to save and restore as callee. 

Best regards,
Marcus
On Sat, 2018-06-09 at 20:18 +0200, Paul Boven wrote:
> 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 to 0.99]
> 
> The second was actually the behaviour I was expecting, and I was 
> pleasantly surprised when GnuRadio seemed to do the first - but then 
> occasionally it doesn't.
> 
> I just did a quick test in python3, and there, the range of int(x)
> for 
> zero runs [-0.99 : 0.99], so I'm expecting most programming 
> languages to behave that way.
> 
> So, I guess a programmer would expect the behaviour as in the third 
> case. Someone who is converting radio signals might want either the 
> first or second case, as otherwise you end up with some interesting 
> non-linearities.
> 
> The gnuplot helpfile states: " The `int(x)` function returns the
> integer 
> part of its argument, truncated toward zero."
> 
> But gnuplot also provides functions like 'floor(x)' and ceil(x).
> 
> So the real question is still, do we want the behaviour of int(x),
> or 
> the behaviour that an analog to digital converter would have?
> 
> Finally, I'd say we want the behaviour to be the same for Int, Short
> and 
> Char. So I ran a few more tests.
> 
> With Volk enabled, Float to Int, Short and Char treat [-0.5 :
> 0.49] 
> as zero, with the occasional glitch for Char.
> 
> volk_32f_s32f_convert_16i a_avx u_avx
> volk_32f_s32f_convert_32i a_avx u_sse2
> 
> With these conversions for Int and Short also switched to 'generic 
> generic', I get the same results:
> 
> Short zero: [-0.5 : 0.49]
> Int zero:   [-0.5 : 0.49]
> 
> So, assuming I carried out these tests correctly, the odd one out
> seems 
> to be the generic case for float to char conversion.
> 
> Note that Volk in the 16 bit and 32 bit case uses a function called 
> 'rintf' in the conversions. From its manpage:
> 
> "(...) round  their argument  to  an integer value in floating-point 
> format".
> 
> So I say this boils down to a bug in the 'generic' float to char
> case.
> 
> This is not a fix to make lightly, because somebody is going to have 
> their flowchart break because of this. Then again, in the current 
> situation the outcome depends on which optimizations your machine 
> happens to have available, so that's also quite bad.
> 
> Possibly there is also an optimization opportunity of never using 
> 'generic' even at the block edge when acceleration is available by 
> choosing the right size of blocks, but that's probably a small gain.
> 
> Regards, Paul Boven.
> 
> 
> 
> On 06/09/2018 07:18 PM, Müller, Marcus (CEL) wrote:
> > 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 val = (int8_t) -8.8f;
> > 
> > would always lead to -8.
> > 
> > Now, for the conversion operations used in the SIMD kernels, it
> > depends
> > on specific flags being set in FPU-control registers (MXCSR, it
> > seems).
> > U. Noone set these to give identical results as the native C
> > conversion above, so if I set the tolerance in the kernel unit test
> > to
> > 0 instead of 1 (which it always should have been), I get a whole
> > lot of
> > failures. Great.
> > 
> > Normally, we'd stick with the what the generic version of a kernel
> > gives us.
> > 
> > I'd do that here, too. But: that would lead 

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

[Paul Boven]

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 to 0.99]

The second was actually the behaviour I was expecting, and I was 
pleasantly surprised when GnuRadio seemed to do the first - but then 
occasionally it doesn't.


I just did a quick test in python3, and there, the range of int(x) for 
zero runs [-0.99 : 0.99], so I'm expecting most programming 
languages to behave that way.


So, I guess a programmer would expect the behaviour as in the third 
case. Someone who is converting radio signals might want either the 
first or second case, as otherwise you end up with some interesting 
non-linearities.


The gnuplot helpfile states: " The `int(x)` function returns the integer 
part of its argument, truncated toward zero."


But gnuplot also provides functions like 'floor(x)' and ceil(x).

So the real question is still, do we want the behaviour of int(x), or 
the behaviour that an analog to digital converter would have?


Finally, I'd say we want the behaviour to be the same for Int, Short and 
Char. So I ran a few more tests.


With Volk enabled, Float to Int, Short and Char treat [-0.5 : 0.49] 
as zero, with the occasional glitch for Char.


volk_32f_s32f_convert_16i a_avx u_avx
volk_32f_s32f_convert_32i a_avx u_sse2

With these conversions for Int and Short also switched to 'generic 
generic', I get the same results:


Short zero: [-0.5 : 0.49]
Int zero:   [-0.5 : 0.49]

So, assuming I carried out these tests correctly, the odd one out seems 
to be the generic case for float to char conversion.


Note that Volk in the 16 bit and 32 bit case uses a function called 
'rintf' in the conversions. From its manpage:


"(...) round  their argument  to  an integer value in floating-point 
format".


So I say this boils down to a bug in the 'generic' float to char case.

This is not a fix to make lightly, because somebody is going to have 
their flowchart break because of this. Then again, in the current 
situation the outcome depends on which optimizations your machine 
happens to have available, so that's also quite bad.


Possibly there is also an optimization opportunity of never using 
'generic' even at the block edge when acceleration is available by 
choosing the right size of blocks, but that's probably a small gain.


Regards, Paul Boven.



On 06/09/2018 07:18 PM, Müller, Marcus (CEL) wrote:

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 val = (int8_t) -8.8f;

would always lead to -8.

Now, for the conversion operations used in the SIMD kernels, it depends
on specific flags being set in FPU-control registers (MXCSR, it seems).
U. Noone set these to give identical results as the native C
conversion above, so if I set the tolerance in the kernel unit test to
0 instead of 1 (which it always should have been), I get a whole lot of
failures. Great.

Normally, we'd stick with the what the generic version of a kernel
gives us.

I'd do that here, too. But: that would lead to a non-rounding
behaviour... I'm breaking someone's porcelain here, no matter what I
do.

Any ideas?

Best regards,
Marcus

On Sat, 2018-06-09 at 18:24 +0200, Paul Boven wrote:

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, but at
the
end of each multiple of 8192 bytes, a few are done with the
'generic'
converter - that would match perfectly with the observed behaviour.

It was also pointed out to me (on irc, unfortunately no longer in my
history) that it is strange that for some acceleration types, there
is a
cast to int16_t instead of int8_t at the end of the routine, e.g.:

https://github.com/gnuradio/volk/blob/master/kernels/volk/volk_32f_s3
2f_convert_8i.h#L200

I had not really looked into that before because having run the
volk_profile seemed to make no difference.

Regards, Paul Boven.

On 06/09/2018 06:08 PM, Müller, Marcus (CEL) wrote:

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 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_s32

[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)

[CEL]

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 val = (int8_t) -8.8f;

would always lead to -8.

Now, for the conversion operations used in the SIMD kernels, it depends
on specific flags being set in FPU-control registers (MXCSR, it seems).
U. Noone set these to give identical results as the native C
conversion above, so if I set the tolerance in the kernel unit test to
0 instead of 1 (which it always should have been), I get a whole lot of
failures. Great.

Normally, we'd stick with the what the generic version of a kernel
gives us.

I'd do that here, too. But: that would lead to a non-rounding
behaviour... I'm breaking someone's porcelain here, no matter what I
do.

Any ideas?

Best regards,
Marcus

On Sat, 2018-06-09 at 18:24 +0200, Paul Boven wrote:
> 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, but at
> the 
> end of each multiple of 8192 bytes, a few are done with the
> 'generic' 
> converter - that would match perfectly with the observed behaviour.
> 
> It was also pointed out to me (on irc, unfortunately no longer in my 
> history) that it is strange that for some acceleration types, there
> is a 
> cast to int16_t instead of int8_t at the end of the routine, e.g.:
> 
> https://github.com/gnuradio/volk/blob/master/kernels/volk/volk_32f_s3
> 2f_convert_8i.h#L200
> 
> I had not really looked into that before because having run the 
> volk_profile seemed to make no difference.
> 
> Regards, Paul Boven.
> 
> On 06/09/2018 06:08 PM, Müller, Marcus (CEL) wrote:
> > 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 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
> > > volk_32f_s32f_convert_8i u_sse2 u_sse2
> > > 
> > > Regards, Paul Boven.
> > > 
> > > On 06/09/2018 05:30 PM, 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 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 Boven wrote:
> > > > > Hi everyone,
> > > > > 
> > > > > I'm trying to perform 2 bit sampling of an RF signal. In one
> > > > > approach,
> > > > > I'm using a float->char block, and noticed that around zero,
> > > > > a
> > > > > number
> > > > > of
> > > > > float inputs become quantized in a bin that's one off from
> > > > > the
> > > > > correct
> > > > > value. The ones that are wrong are always off by one, with
> > > > > their
> > > > > quantization error always in the direction of zero.
> > > > > 
> > > > > The problem can be demonstrated with a really simple
> > > > > flowchart,
> > > > > using
> > > > > the following blocks:
> > > > > 
> > > > > * Noise Source (Noise Type: Gaussian, Amplitude: 1, Seed: 0,
> > > > > Output
> > > > > type: Float)
> > > > > * Throttle
> > > > > The throttle is then connected to two blocks:
> > > > > * A file-sink (Type Float) and a
> > > > > * 'Float to Char' block.
> > > > > * The float to char block is again connected to a File Sink,
> > > > > now
> > > > > of
> > > > > type
> > > > > Char.
> > > > > 
> > > > > As an example, I've plotted all the samples that quantized as
> > > > > zero.
> > > > > These should fall in the range [-0.5:0.5], but occasionally
> > > > > we
> > > > > also
> > > > > get
> > > > > hits that lie within [-1:1]. These mishaps are rare (about
> > > > > one in
> > > > > 2000).
> > > > > It also shows that they only occur at multiples of 8192
> > > > > samples,
> > > > > and
> > > > > zooming in reveals that they always happen shortly before the
> > > > > next
> > > > > multiple of 8192, not after.
> > > > > 
> > > > > For other values than 0, the same applies, but the
> > > > > misquantizations
> > > > > are
> > > > > only in one direction, ending up in a lower bin if the input
> > > > > is
> > > > > positive, or in a higher bin if the input is negative. 

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

[Paul Boven]

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, but at the 
end of each multiple of 8192 bytes, a few are done with the 'generic' 
converter - that would match perfectly with the observed behaviour.


It was also pointed out to me (on irc, unfortunately no longer in my 
history) that it is strange that for some acceleration types, there is a 
cast to int16_t instead of int8_t at the end of the routine, e.g.:


https://github.com/gnuradio/volk/blob/master/kernels/volk/volk_32f_s32f_convert_8i.h#L200

I had not really looked into that before because having run the 
volk_profile seemed to make no difference.


Regards, Paul Boven.

On 06/09/2018 06:08 PM, Müller, Marcus (CEL) wrote:

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 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
volk_32f_s32f_convert_8i u_sse2 u_sse2

Regards, Paul Boven.

On 06/09/2018 05:30 PM, 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 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 Boven wrote:

Hi everyone,

I'm trying to perform 2 bit sampling of an RF signal. In one
approach,
I'm using a float->char block, and noticed that around zero, a
number
of
float inputs become quantized in a bin that's one off from the
correct
value. The ones that are wrong are always off by one, with their
quantization error always in the direction of zero.

The problem can be demonstrated with a really simple flowchart,
using
the following blocks:

* Noise Source (Noise Type: Gaussian, Amplitude: 1, Seed: 0,
Output
type: Float)
* Throttle
The throttle is then connected to two blocks:
* A file-sink (Type Float) and a
* 'Float to Char' block.
* The float to char block is again connected to a File Sink, now
of
type
Char.

As an example, I've plotted all the samples that quantized as
zero.
These should fall in the range [-0.5:0.5], but occasionally we
also
get
hits that lie within [-1:1]. These mishaps are rare (about one in
2000).
It also shows that they only occur at multiples of 8192 samples,
and
zooming in reveals that they always happen shortly before the
next
multiple of 8192, not after.

For other values than 0, the same applies, but the
misquantizations
are
only in one direction, ending up in a lower bin if the input is
positive, or in a higher bin if the input is negative. Again, the
misquantizations only occur in half the bin: For a value of 1,
the
float
value should be in [0.5:1.5], but occasionally a value in [1.5:2]
also
ends up being quantized as 1.

This seems to me a bug that is somehow related to internal block
boundaries, but I'm not familiar enough with the internals of
GnuRadio
to figure out just what's going wrong.

The problem does NOT occur when converting to Short or Int.

This is using GnuRadio 3.7.11 (as packaged with Ubuntu 18.04).

Regards, Paul Boven.










___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[CEL]

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 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
> volk_32f_s32f_convert_8i u_sse2 u_sse2
> 
> Regards, Paul Boven.
> 
> On 06/09/2018 05:30 PM, 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 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 Boven wrote:
> > > Hi everyone,
> > > 
> > > I'm trying to perform 2 bit sampling of an RF signal. In one
> > > approach,
> > > I'm using a float->char block, and noticed that around zero, a
> > > number
> > > of
> > > float inputs become quantized in a bin that's one off from the
> > > correct
> > > value. The ones that are wrong are always off by one, with their
> > > quantization error always in the direction of zero.
> > > 
> > > The problem can be demonstrated with a really simple flowchart,
> > > using
> > > the following blocks:
> > > 
> > > * Noise Source (Noise Type: Gaussian, Amplitude: 1, Seed: 0,
> > > Output
> > > type: Float)
> > > * Throttle
> > > The throttle is then connected to two blocks:
> > > * A file-sink (Type Float) and a
> > > * 'Float to Char' block.
> > > * The float to char block is again connected to a File Sink, now
> > > of
> > > type
> > > Char.
> > > 
> > > As an example, I've plotted all the samples that quantized as
> > > zero.
> > > These should fall in the range [-0.5:0.5], but occasionally we
> > > also
> > > get
> > > hits that lie within [-1:1]. These mishaps are rare (about one in
> > > 2000).
> > > It also shows that they only occur at multiples of 8192 samples,
> > > and
> > > zooming in reveals that they always happen shortly before the
> > > next
> > > multiple of 8192, not after.
> > > 
> > > For other values than 0, the same applies, but the
> > > misquantizations
> > > are
> > > only in one direction, ending up in a lower bin if the input is
> > > positive, or in a higher bin if the input is negative. Again, the
> > > misquantizations only occur in half the bin: For a value of 1,
> > > the
> > > float
> > > value should be in [0.5:1.5], but occasionally a value in [1.5:2]
> > > also
> > > ends up being quantized as 1.
> > > 
> > > This seems to me a bug that is somehow related to internal block
> > > boundaries, but I'm not familiar enough with the internals of
> > > GnuRadio
> > > to figure out just what's going wrong.
> > > 
> > > The problem does NOT occur when converting to Short or Int.
> > > 
> > > This is using GnuRadio 3.7.11 (as packaged with Ubuntu 18.04).
> > > 
> > > Regards, Paul Boven.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Paul Boven]

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
volk_32f_s32f_convert_8i u_sse2 u_sse2

Regards, Paul Boven.

On 06/09/2018 05:30 PM, 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 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 Boven wrote:

Hi everyone,

I'm trying to perform 2 bit sampling of an RF signal. In one
approach,
I'm using a float->char block, and noticed that around zero, a number
of
float inputs become quantized in a bin that's one off from the
correct
value. The ones that are wrong are always off by one, with their
quantization error always in the direction of zero.

The problem can be demonstrated with a really simple flowchart,
using
the following blocks:

* Noise Source (Noise Type: Gaussian, Amplitude: 1, Seed: 0, Output
type: Float)
* Throttle
The throttle is then connected to two blocks:
* A file-sink (Type Float) and a
* 'Float to Char' block.
* The float to char block is again connected to a File Sink, now of
type
Char.

As an example, I've plotted all the samples that quantized as zero.
These should fall in the range [-0.5:0.5], but occasionally we also
get
hits that lie within [-1:1]. These mishaps are rare (about one in
2000).
It also shows that they only occur at multiples of 8192 samples, and
zooming in reveals that they always happen shortly before the next
multiple of 8192, not after.

For other values than 0, the same applies, but the misquantizations
are
only in one direction, ending up in a lower bin if the input is
positive, or in a higher bin if the input is negative. Again, the
misquantizations only occur in half the bin: For a value of 1, the
float
value should be in [0.5:1.5], but occasionally a value in [1.5:2]
also
ends up being quantized as 1.

This seems to me a bug that is somehow related to internal block
boundaries, but I'm not familiar enough with the internals of
GnuRadio
to figure out just what's going wrong.

The problem does NOT occur when converting to Short or Int.

This is using GnuRadio 3.7.11 (as packaged with Ubuntu 18.04).

Regards, Paul Boven.










___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[CEL]

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 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 Boven wrote:
> > Hi everyone,
> > 
> > I'm trying to perform 2 bit sampling of an RF signal. In one
> > approach, 
> > I'm using a float->char block, and noticed that around zero, a
> > number
> > of 
> > float inputs become quantized in a bin that's one off from the
> > correct 
> > value. The ones that are wrong are always off by one, with their 
> > quantization error always in the direction of zero.
> > 
> > The problem can be demonstrated with a really simple flowchart,
> > using 
> > the following blocks:
> > 
> > * Noise Source (Noise Type: Gaussian, Amplitude: 1, Seed: 0,
> > Output 
> > type: Float)
> > * Throttle
> > The throttle is then connected to two blocks:
> > * A file-sink (Type Float) and a
> > * 'Float to Char' block.
> > * The float to char block is again connected to a File Sink, now of
> > type 
> > Char.
> > 
> > As an example, I've plotted all the samples that quantized as
> > zero. 
> > These should fall in the range [-0.5:0.5], but occasionally we also
> > get 
> > hits that lie within [-1:1]. These mishaps are rare (about one in
> > 2000). 
> > It also shows that they only occur at multiples of 8192 samples,
> > and 
> > zooming in reveals that they always happen shortly before the next 
> > multiple of 8192, not after.
> > 
> > For other values than 0, the same applies, but the misquantizations
> > are 
> > only in one direction, ending up in a lower bin if the input is 
> > positive, or in a higher bin if the input is negative. Again, the 
> > misquantizations only occur in half the bin: For a value of 1, the
> > float 
> > value should be in [0.5:1.5], but occasionally a value in [1.5:2]
> > also 
> > ends up being quantized as 1.
> > 
> > This seems to me a bug that is somehow related to internal block 
> > boundaries, but I'm not familiar enough with the internals of
> > GnuRadio 
> > to figure out just what's going wrong.
> > 
> > The problem does NOT occur when converting to Short or Int.
> > 
> > This is using GnuRadio 3.7.11 (as packaged with Ubuntu 18.04).
> > 
> > Regards, Paul Boven.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[CEL]

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 Boven wrote:
> Hi everyone,
> 
> I'm trying to perform 2 bit sampling of an RF signal. In one
> approach, 
> I'm using a float->char block, and noticed that around zero, a number
> of 
> float inputs become quantized in a bin that's one off from the
> correct 
> value. The ones that are wrong are always off by one, with their 
> quantization error always in the direction of zero.
> 
> The problem can be demonstrated with a really simple flowchart,
> using 
> the following blocks:
> 
> * Noise Source (Noise Type: Gaussian, Amplitude: 1, Seed: 0, Output 
> type: Float)
> * Throttle
> The throttle is then connected to two blocks:
> * A file-sink (Type Float) and a
> * 'Float to Char' block.
> * The float to char block is again connected to a File Sink, now of
> type 
> Char.
> 
> As an example, I've plotted all the samples that quantized as zero. 
> These should fall in the range [-0.5:0.5], but occasionally we also
> get 
> hits that lie within [-1:1]. These mishaps are rare (about one in
> 2000). 
> It also shows that they only occur at multiples of 8192 samples, and 
> zooming in reveals that they always happen shortly before the next 
> multiple of 8192, not after.
> 
> For other values than 0, the same applies, but the misquantizations
> are 
> only in one direction, ending up in a lower bin if the input is 
> positive, or in a higher bin if the input is negative. Again, the 
> misquantizations only occur in half the bin: For a value of 1, the
> float 
> value should be in [0.5:1.5], but occasionally a value in [1.5:2]
> also 
> ends up being quantized as 1.
> 
> This seems to me a bug that is somehow related to internal block 
> boundaries, but I'm not familiar enough with the internals of
> GnuRadio 
> to figure out just what's going wrong.
> 
> The problem does NOT occur when converting to Short or Int.
> 
> This is using GnuRadio 3.7.11 (as packaged with Ubuntu 18.04).
> 
> Regards, Paul Boven.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[swapnil negi]

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 Institute of Technology Roorkee
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Paul Boven]

Hi everyone,

I'm trying to perform 2 bit sampling of an RF signal. In one approach, 
I'm using a float->char block, and noticed that around zero, a number of 
float inputs become quantized in a bin that's one off from the correct 
value. The ones that are wrong are always off by one, with their 
quantization error always in the direction of zero.


The problem can be demonstrated with a really simple flowchart, using 
the following blocks:


* Noise Source (Noise Type: Gaussian, Amplitude: 1, Seed: 0, Output 
type: Float)

* Throttle
The throttle is then connected to two blocks:
* A file-sink (Type Float) and a
* 'Float to Char' block.
* The float to char block is again connected to a File Sink, now of type 
Char.


As an example, I've plotted all the samples that quantized as zero. 
These should fall in the range [-0.5:0.5], but occasionally we also get 
hits that lie within [-1:1]. These mishaps are rare (about one in 2000). 
It also shows that they only occur at multiples of 8192 samples, and 
zooming in reveals that they always happen shortly before the next 
multiple of 8192, not after.


For other values than 0, the same applies, but the misquantizations are 
only in one direction, ending up in a lower bin if the input is 
positive, or in a higher bin if the input is negative. Again, the 
misquantizations only occur in half the bin: For a value of 1, the float 
value should be in [0.5:1.5], but occasionally a value in [1.5:2] also 
ends up being quantized as 1.


This seems to me a bug that is somehow related to internal block 
boundaries, but I'm not familiar enough with the internals of GnuRadio 
to figure out just what's going wrong.


The problem does NOT occur when converting to Short or Int.

This is using GnuRadio 3.7.11 (as packaged with Ubuntu 18.04).

Regards, Paul Boven.










___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Andy Walls]

> 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
> goofed (should have not retyped it).  The equation is STILL wrong!

Issues submitted to the mailing list will ultimately be forgotten. 
Issues submitted in GitHub shouldn't get lost.
https://github.com/gnuradio/gnuradio/issues
  
> 
> Sdot = d_scl * (-S0+d_8*S1-d_8*S2+S4);
> 
>  
> 
> Should be
> 
>  
> 
> Sdot = d_scl * (-S0+d_8*S1-d_8*S3+S4);
> 
>  
> 
>  
> 
>  
> 
> It is crazy that the basic FM demo works at all.

Well, all of these discrete derivatives are approximations.  Depending
on the input, the filter still might be close enough.

What's really crazy is that this block is implementing an FIR in that
"Sdot =" line and storing input sample history itself in some other
lines, in a C++ loop.  This block should be using volk SIMD
implementations for the FIR filtering and using the block's history
functionality to handle the history.

In fact, to get an even better derivative, instead of using the
existing taps, this block could use the MMSE interpolating
differentitator (with a mu fixed at 0.0) to get a better derivative and
use a volk implementation at the same time.

Regards,
Andy

> ___
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> 
> 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[CEL]

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
honestly, odd symmetry would be good, so yeah, without knowing what
exactly I'm looking at here, it seems this is the right thing to do.
Can you point me at the source for the Taylor series (it looks like
one) you're citing in your last email?

Taking a step back, Sdot is really just the result of a FIR filter
applied to the input signal, isn't it? So, let's add that to the list
of things to actually use VOLK on to speed things up.

Best regards,
Marcus

On Fri, 2018-06-08 at 18:48 +, Eugene Grayver wrote:
> 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
> goofed (should have not retyped it).  The equation is STILL wrong!
>  
> Sdot = d_scl * (-S0+d_8*S1-d_8*S2+S4);
>  
> Should be
>  
> Sdot = d_scl * (-S0+d_8*S1-d_8*S3+S4);
>  
>  
> 
>  
> It is crazy that the basic FM demo works at all.
>  
>  
> ___
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> 
>  
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[CEL]

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 systems that we
still support. For example, I'm pretty sure Ubuntu 14.04 will fall off
the wagon. I know there's quite a few users on that, but that's why we
keep the maint-3.7 branch alive: If you're stuck on a 4 year old
desktop/convenience operating system¹, you might simply not need or
want the newest features (and API breakage) that in the meantime
appeared on the master branch. We still don't want to abandon you in
the dark, and thus we backport patches to maint-3.7.

That clearly says something about stability of dependencies on maint-
3.7: We simply won't add any new dependencies, be it a newer version of
a language standard, or an update of a library that we link to. That's
why it's called "maint-something", we do the maintenance, we don't add
new things that might break what you're already doing.

So what about stability of dependencies on the master branch?
The ugly truth is that, as long as we don't formally release anything,
we should be able to do whatever we like on master. It should compile
at every commit, but it's not the end of the world if at some point,
something obscure breaks on master that we didn't notice. It's
unreleased developer code.

Now, that's not really fair to say, though, because 3.7 has been around
forever, and we've got a lot of users who'd normally want to use a
released version building master, just because we haven't been
productive enough at releasing versions in the last years.
Thus, for the time being, we'll announce when we do something on master
that we expect things to break.
Going forward after the release: If you don't want the development
version's quirks (those including random dependency changes, API
changes, ABI changes, disappearing features, appearing features, and
surprise gerbils), I'd advise you to stick with a release and its
maint-MAJOR.MINOR branch.

I hope that answers the demand of users (stability and new features)
and developers (ability to improve and extend without having to care
about dependencies that are partially literally a decade old, looking
at Ubuntu 14.04 there) with an equilibrium that makes new features
appear, without breaking old functionality.

I think this is an issue only because we've been handling master and
maint differently. If you're used to the old GNU Radio dev model,
you'll find that "master" today works much more like "next" used to
work let's say mid-2016. "maint-3.7" is a new (old) concept, which we
hope will make the released versions even more reliable than they used
to be, whilst not stopping developers to just work on the main
development branch (that being master). (If you're still on "maint" and
wondering why nothing happened: that branch is dead.)

So, if you're on an old system, and you don't need the features that
are not in the 3.7, please do consider using maint-3.7 instead of
master. The moment we release 3.8, we'll also start a maint-3.8 branch.
That, by the way, doesn't mean we let maint-3.7 die anytime soon. As
far as feasible, patches to master (and maint-3.8) would continue to be
backported to maint-3.7.

Best regards,
Marcus


¹ CentOS 7 takes a bit of a special role in there, in my opinion, as it
tends to be a server system where you really have good reason not to
update; if it turns out that there's too many dependency problems with
GR 3.8 on it, we'll come up with a "golden way" of getting a working
subenvironment for maint-3.8 to build (even if in a reduced feature
set). If we can come back to you, Jason, there on how to decide what
priorities to set, and maybe for some real-world testing or even
solutions, that'd be valuable.
Basically, the same would apply to Ubuntu server, but I'll be honest
here: CentOS' "maintenance support time" simply puts Canonical to
shame, and Ubuntu LTS early phase of support is about as well-
maintained as CentOS late "maintenance support time", so, personally,
while I think it might be a valid choice for desktop systems that
really can stand an update every two years, I don't think I need to
support Canonical reselling the same desktop-oriented fork of debian as
a server platform. But, due to *excellent* maintenance work on Debian,
thanks to Mait, it's very likely you'll have an easy time getting
recent GNU Radio packages even for older Ubuntu releases.

On Fri, 2018-06-08 at 16:15 +0100, Derek Kozel wrote:
> Hi Jason,
> 
> Centos 7 is being specifically looked at for 3.8 as it will define
> the minimum version of most dependencies. We don't yet have a CentOS
> 7 regression test VM, but it is something to consider. We will be
> enforcing the C++11 requirement in CMake which I believe is
> sufficient to make all this work on Centos, but it would be great to
> get your eyes on

[Discuss-gnuradio] SDRA 2018 videos online

[Markus Heller]

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 subscribe. 

My special thanks go to Sebastian DL5WN and his videoteam who made the
production of this year's videos possible. The quality of this year's
recordings exceeded all our expectations and is absolutely
professional. 

I hope you enjoy the videos:

http://youtube.sdra.io

BR /vy73
markus
dl8rds

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio