Re: bitshift of int8, int16, etc?

[Daniel J Sebald]

David Bateman wrote:
> Daniel J Sebald wrote:
>
> > Does the proposed version limit the class value to the maximum
> > inherently?  E.g., say it is int8 type and bit shift is +1 and current
> > value is 127; Is ival = 127 << 1 equal to 254 but then treated as 126
> > in all uses of the int8 value?
>
> ival is of type T where T is the type used to instantiate the class.
> Therefore for octave_int8, T is of type int8_t. Try the C++ code sample

Oh, OK.  I wasn't aware of inttypes.h.  That's convenient.

> #include <iostream>
> #include <inttypes.h>
>
> int main (int argc, char **argv)
> {
>   int8_t a = atoi(argv[1]);
>   int shift = atoi(argv[2]);
>   int8_t b;
>   if (shift > 0)
>     b = (a << shift);
>   else
>     b = (a >> -shift);
>   std::cerr << static_cast<double>(b) << std::endl;
> }
>
> and compiling to "temp", I get the following
>
> % ./temp 63 1
> 126
> %. /temp 64 1
> -128
> % ./temp 127 1
> -2
> % ./temp 127 -1
> 63
> % ./temp -1 -1
> -1
>
> 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.)

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.

Dan