Re: bitshift of int8, int16, etc?

[David Bateman]

Daniel J Sebald wrote:
> 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.

Hey I know, I did write a fixed point type :-) ....

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

Do we need to know the overflow of each and every element, or just that
an overflow occurred? I'd thought more the second case and then just have

warning ("Octave:bitshift_overflow", "on")

to enable the warning if desired. The fact is that as matlab doesn't
implement this yet, whatever we choose to do will be wrong in any case
and need modifying in the long run. So simple is probably better..

D.



> 
> Dan
>