Re: [Discuss-gnuradio] Sample Type Conversions

[CEL]

Hi Peter,

>I have a rather dumb question, 

I'm a bit confused by that statement, because the rest of your email
doesn't contain a dumb question. Instead, you just ask clever
questions?!

So, yes, your suspicion is right:

> [if the floats span [-1,+1] inclusively]: Does this mean that I now
have to use 32,767 for the conversion back to shorts (which also means
that I can't represent -32,768 as the minimum value)?

well, your +1.0f would map to a value non-existant in the short range
if you didn't. So, yes, since integer ranges aren't symmetric to 0, if
your float range that you map to them is symmetric, you'll have to
choose whether you want truncate values or reduce amplitude.

> A more general question is how does the block compensate for overflow
(i.e., I'm assuming saturation is desired here instead of wrapping
around)? My best theory is that the block uses VOLK, which in turn uses
various SIMD instructions that perform saturating arithmetic (am I on
the right track here?).

Absolutely. The conversion blocks are implemented using VOLK kernels,
and as you noticed, CPUs have rounding modes supporting saturation
(yay!).

In fact, I think we have an outstanding bug, where the generic (non-
optimized) implementation of a float to something (or vice versa)
doesn't do exactly the same saturation or rounding as its optimized
counterparts. Have to look that one up.

Best regards,
Marcus


On Sat, 2018-08-18 at 11:58 -0600, Peter Witkowski wrote:
> Hello,
> I have a rather dumb question, and I'm surprised I haven't run into
> this previously.
> I want to convert back and forth between samples of floats and
> shorts. I noticed the following conventions for samples are used by
> various devices/blocks:
>  int16_t/short: samples span the entire range of the type (i.e.,
> -32,768 to +32,767)
>  float: samples span the range of -1.0 to +1.0
> The various conversion blocks (like short_to_float) take a “scale”
> parameter to do a multiplication or division by the scale to get the
> data within a specific range. I guess my question is, which scale is
> generally used?
> For example, if I have a stream of shorts that I want to convert to
> floats, it stands to reason that I should probably use 32,768 as the
> scale. This ensures that I get values between -1.0 and +1.0. The
> resulting stream of samples won't ever totally reach +1.0, but that's
> probably OK. Using 32,767 would mean that if my samples ever reach
> -32,768 (e.g., in the case of a 16-bit ADC) I would be outside the
> desired range for floats. If I want to convert back to my original
> set of samples, I should use 32,768 again.
> However, let's say that my converted stream had lots of math done on
> it (or alternatively, I'm just starting with a stream of floats) and
> now it can span the full range of -1.0 to +1.0. If I use my old scale
> of 32,768, I will overflow, since 1.0 * 32,768 = 32,768, which is
> outside the range of shorts. Does this mean that I now have to use
> 32,767 for the conversion back to shorts (which also means that I
> can't represent -32,768 as the minimum value)? A more general
> question is how does the block compensate for overflow (i.e., I'm
> assuming saturation is desired here instead of wrapping around)? My
> best theory is that the block uses VOLK, which in turn uses various
> SIMD instructions that perform saturating arithmetic (am I on the
> right track here?).
> Thanks in advance for the assistance.
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature