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 t
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. X
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 behav
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
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(
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
