Re: bitshift of int8, int16, etc?

[David Bateman]

Daniel J Sebald wrote:
>>
>>
>> which to me seems to be the right behavior for an arithmetic shift
>> operator..
>
> Alright.  What I suggested was an implementation in which the sign
> bit did not participate in the bit shift either left or right.  To
> be technical, the
>
>> % ./temp -1 -1
>> -1
>
> is for two's complement behavior.  One's complement would round to
> zero if I understand some documentation on the web.  (Supposedly C
> doesn't call out a behavior for right shifting negative numbers,
> and leaves that up to the compiler to call out.)

Wouldn't ones-complement representation of "-1" right-shifted by 1 bit
turn into "64" for a logical shift and "-64" for an arithmetic shift?

The C standard doesn't define the behavior of the right shift of
negative numbers as it is supposed to work on architectures with both
ones and twos complement representation. However, aren't all integer
types on modern architectures are twos complements and so the right
shift operator should be similar. The only question is whether the
compiler chooses an arithmetic or logical shift for negative numbers.

I suppose the best to make sure that Octave is consistent across
compilers is to avoid the issue and operator always of positive numbers.
A means that would be consistent with Matlab's floating point version of
the bitshift operator would be to do something like

template <class T2>
octave_int<T>& operator >>= (const T2& x)
{
  if (ival < 0)
    ival = - (((-ival) >> x) & std::numeric_limits<T>::max());
  else
    ival = ival >> x;
  return *this;
}

template <class T2>
octave_int<T>& operator <<= (const T2& x)
{
  ival = ival << x;
  return *this;
}

This will cause a few compile warnings for the unsigned types though as
for the unsigned types (ival < 0) is always false.. It would however
enforce a strict two complements arithmetic shift operator regardless of
the compilers implementation of shifts of negative numbers.

>
> In any case, there probably should be a record kept of an overflow.
> These two are examples:
>
>> %. /temp 64 1
>> -128
>> % ./temp 127 1
>> -2
>
> Anyone working with those numbers who doesn't have access to info
> about overflow might be in a bind.
>

Ok, I'm unsure what's the best solution, but still think the case of
"bitshift(127,1)" should return -2.... In any case as Matlab doesn't
even define the shift operators for signed integer types, we are free to
do whatever behavior we want as long as we are consistent. I think my
proposal above is consistent with an arithmetic shift operator, that is
consistent with the behavior of Matlab for bitshift on negative floating
point values.. Can I make this change?

Regards
David

-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary