Bit shifting limitations

[John Meacham]

Without a type generic way to translate between 'IntN', 'CardN', and
'BitSetN' then that will be quite awkward to work with.

Being able to perform logical shifts on unsigned numbers and
arithmetic shifts on signed numbers is just extremely useful. The
compiler is smart enough to transform div and mod power of two
operations into bit operations so in general when you are explicitly
using shiftR it is for their bit manipulation properties, not their
correspondence to mod/div/mul. IntN/WordN are already specified to be
2s complement representations so these operations are well defined.

In C you have to do awkward things like  'sign = -(int)((unsigned
int)((int)v) >> (sizeof(int) * CHAR_BIT - 1));' to force the correct
type of shift you want for a given arch. (right shift behavior is arch
specific in C).


   John

On Sun, Jul 13, 2014 at 1:55 PM, Henning Thielemann
<schlepptop at henning-thielemann.de> wrote:
> Am 13.07.2014 22:42, schrieb John Meacham:
>
>> On Sun, Jul 13, 2014 at 12:42 PM, Henning Thielemann
>> <schlepptop at henning-thielemann.de> wrote:
>>>
>>> So far, I'd say, that calling "asr" on Word and "lsr" on Int should be a
>>> type error.
>>
>>
>>
>> No, that would completely ruin the point of having them, the whole
>> idea is being able to perform specifically an arithmetic or logical
>> shift independent of the signedness of the underlying type.
>
>
>
> I'd prefer to distinguish between IntN, CardN (aka WordN) and BitSetN. IntN
> are signed integers, CardN are unsigned integers and BitSetN is a bit
> pattern without a numeric interpretation (flags, graphical patterns ...).
> IntN and CardN would be in a sub-class of Num that supports multiplication,
> division and modulo with powers of two, which can be efficiently implemented
> by shifts and bitwise Ands. BitSetN would support all kinds of logical and
> arithmetical shifts, shifts-through-carry, rotations, bit counts, bitwise
> logic and what know I.
>
> Bit manipulation of numbers as provided by the Bits class was certainly not
> a good idea and will not become better by extending in that direction.
>



-- 
John Meacham - http://notanumber.net/