Re: bitshift of int8, int16, etc?

[Daniel J Sebald]

David Bateman wrote:

> This is the standard behavior of an arithmetic shift.. See
>
> http://en.wikipedia.org/wiki/Arithmetic_shift

I looked at that reference yesterday.  OK, good then.


> Ok, saturation might make sense. My preference was or an arithmetic
> shift as a shift operator that had a clear and documented functionality.

DSP chips often have a control register with a bit to change such behavior, 
i.e. wrap or saturate.


> If we got with a saturation we are defining our own operator (which is
> fine of course). Ok, I'd be happy with saturation, but I don't see an
> efficient implmentation.
>
>
> > The lack of overflow information concerns me a bit.  Should or shouldn't
> > that be worked into the code?
>
>
> As with << and >> in C, its up to the user. I suppose we could set a
> warning that is normally off, that would flag an overflow.
>
> In any case, what would you propose as a patch

Well, how would one set up syntax to access that info?

[result, overflow] = bitshift (A, K, N, control)

The idea is to avoid the user having to use a somewhat clumsy programming 
technique of needing to know the values before the operation to understand what 
happened to them, i.e., unwind what was done, e.g.

A_after = bitshift (A, K, N, control);
if (sign(A_after) != sign(A_before))
 saturate or something etc...;
endif

and even that may not be right because I suppose a number could wrap around the 
range twice and end up being the same sign as it went in.

The "overflow" and "control" values would be optional.  Or could toss the 
"control" argument and implement different variations (if ever someone wants them) as a different 
function name, e.g., bitshiftwithsaturate().

I don't know, just brainstorming.  I'll defer to John on the worthiness of any 
of these alternatives.  It's just that it seems to me the purpose of these 
other integer types might be for simulating the behavior of imbedded algorithms 
which often do have these alternate behaviors.

Dan