octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bitshift of int8, int16, etc?


From: David Bateman
Subject: bitshift of int8, int16, etc?
Date: Sun, 24 Jun 2007 23:23:24 +0200
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

Matlab doesn't define the bitshifts of int8, etc (at least not in
2007a), though Octave does. However, it appears that there is an error
in Octave's shift operations of signed integer types. For example consider

bitshift(int8(127),1)

Logically, this should give "-2", but rather gives "0".. Thinking about
the fix for this I asked myself, whether we should use logical or
arithmetic shifts. That is should we keep the sign bit of the integer
types. Looking at

bitshift (-10, -1)

and the fact that it gives "-5" in both Octave and matlab. Therefore it
appears that we should be doing arithmetic shifts for the signed integer
types for consistency. In fact looking at

bitshift (int8(-1),-1)

and the fact it gives "-1" in Octave means we do respect the arithmetic
shifts. Now the reason for the issue with

bitshift (int8(127), 1)

is that std::numeric_limits<int8_t>::max() is "127" and in
oct-inttypes.h the left shift operator is defined as

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

Shouldn't this just be defined as

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

as this would be more consistent? Is there any reason for the existing
definition?

Regards
David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]