Re: [Discuss-gnuradio] [VOLK] 16i_max_star_horizontal_16i non-saturating subtraction

[Douglas Geiger]

On Thu, Feb 6, 2014 at 6:19 AM, Tom Rondeau <address@hidden> wrote:

On Wed, Feb 5, 2014 at 4:04 PM, West, Nathan
<address@hidden> wrote:
> I was doing some work with this kernel and came across an odd result
> that I think is caused by a non-saturating add in the generic
> proto-kernel, that should also be relevant to the 16i_max_star_16i.
>
> I haven't looked too much in to the SSE versions, but the generic
> versions are doing a comparison by subtracting two values and
> comparing the result to 0. At least in the QA on armhf this is causing
> wrap-around so that the smaller of the two numbers is returned as the
> max.
>
> Since I'm pretty sure this is part of the max* operator defined by
> Viterbi in his "justification and implementation of a MAP decoder" I
> think this result is incorrect unless I'm misunderstanding part of the
> operator.
>
> Can somebody with a little more insight in to this kernel ping back if
> this is intended behavior? If not, is there some benefit to doing
> (x-y)>0 vs x>y as the comparison?
>
> Thanks,
> Nathan

Just from what you've said here, I would agree that (x-y)>0 is a bit
dangerous, and I don't see why we can't use x>y. Does it work for you
if you make that change?

Tom

I'll suggest that the generic kernel should be trusted to do the correct thing, or at least have the correct set of intentions, and that if you want to change the behavior of the generic kernel, that you are introducing a change that will break applications depending on this behavior.

I believe the use of casting the subtraction before the comparison (where: ((int16_t) (src0[i] - src0[i + 1]) > 0) ? src0[i] : src0[i+1]; is the full comparison) was intentional to ensure overflow subtraction vs. saturation subtraction.

--
Doug Geiger
address@hidden