Is there a "bit shifting" operation in C for arrays?

Question

In C we can use a left bit shift to move each digit of a number's binary representation to the left by one space which is regarded to be O(1) time. For example, 0010 << 1 = 0100

Is there a similar function/operation in C that can do this for arrays in O(1) time? For example, [1, 2, 3, 4, 5] shifted by one space gives [2, 3, 4, 5, 0].

One way that came to my mind was by using memcpy() like this:

int arr1[] = {1, 2, 3, 4, 5};
memcpy(arr1, arr1+1, 4*sizeof(int));

for(int i=0 ; i<5 ; i++)
{
        printf("%d ", arr1[i]);
}

Output: 2, 3, 4, 5, 5

The only problem with this is that, I guess memcpy() isn't exactly O(1). I was hoping that might be some low-level function/method in C that can manipulate memory quickly to achieve this, but I haven't been able to find anything while googling so far.

Edit: On searching, I found out that bit shifting uses a special circuit which probably allows the shifting operation to be much faster than something like memcpy. This leads to my question of whether there is a way to represent the array as a string of bits and perform traditional bit shifting on that bit string?

Edit 2: I know what I'm trying to achieve cannot be done in literal O(1) time. I would be satisfied by any answers that suggest how I could improve the speed of shifting the array so that it somewhat seems like an O(1) operation (even though it actually isn't).

Answer 1

Is there a similar function/operation in C that can do this for arrays in O(1) time? For example, [1, 2, 3, 4, 5] shifted by one space gives [2, 3, 4, 5, 0].

No. But you can produce the same result by just storing an offset and using modulo accesses

struct array {
  int offset;
  int size;
  int elems[];
};

struct array* alloc_array(int size)
{
  struct array *a = malloc(sizeof(struct array) + sizeof(int)*size);
  a->offset = 0;
  a->size = size;
  return a;
}

/* Constant-time shift!
   Just use shiftleft with a negative distance to shift right */
void shiftleft(struct array *a, int distance)
{
  a->offset += distance;
}

/* Note we actually made each of our N element accesses slightly more expensive.
   However, that was already linear (ie, when you print all elements)
   so we still have the desired asymptotic complexity.
*/
int elem(struct array *a, int idx)
{
  return a->elems[(idx + a->offset) % a->size];
}

NB. This is totally un-tested, it's just a sketch so you get the idea. Also, I've assumed you actually want an element shift, since that's what you showed. If you want to shift an array N bits to the left, it's a little more involved.

---

I found out that bit shifting uses a special circuit

PS. This "special circuit" is one of the CPU's built-in operations which operates in constant time on a fixed-size register. The register size is baked into the CPU hardware. The size of a C int is chosen to match the CPU register size.

There is no way of performing a constant-time (per register) operation on N register-sized integers (for example) that doesn't take N times as long, so obviously it has linear complexity.

---

I know what I'm trying to achieve cannot be done in literal O(1) time.

Well, asymptotic complexity is only relevant if the number of elements varies. If you always operate on arrays of fixed size, even an operation that's linear with the number of elements is constant-time per array.

• Edit - please stop saying that

  bit-shifting in integers are considered O(1) time since they are so fast, even though they actually aren't O(1)

  1. I said it was constant time because it is, assuming a modern ALU with a barrel shifter

  2. if it wasn't constant-time, there is no value of "so fast" that would induce me to call it constant-time unless it always took the same number of clock cycles in practice (including reciprocal throughput). Since there's no practical way to measure when within a single clock cycle it completed, this is a distinction with no practical difference.

  Again, speed and asymptotic complexity are orthogonal. There is no sufficiently small coefficient for an O(N) operation to be considered O(1). There is of course a sufficiently small value of N, which I mentioned below (but you have declined to bound N in your question).

If you always operate on arrays of variable but bounded size, you can sort of make the same claim, although if your effective array size covers multiple orders of magnitude it won't be very persuasive.

I would be satisfied by any answers that suggest how I could improve the speed of shifting the array so that it somewhat seems like an O(1) operation (even though it actually isn't).

That makes literally no sense. Asymptotic complexity is not a measure of speed, and optimizing speed has no effect on asymptotic complexity.

Answer 2

As said in the comments, you should use memmove instead of memcpy as the source and destination overlap.

Another problem in your code is that you assume that there will be a "0" after your initialized array that you are free to use.

memmove and memcpy will probably need O(n) time, quicker would be a code something like this:

int arr1[] = {1, 2, 3, 4, 5, 0};
int *arr2 = &arr1[1];

for(int i=0 ; i<5 ; i++)
{
        printf("%d ", arr2[i]);
}

Answer 3

The cheap way is to not move large amounts of memory around, but just manipulate the index.

---

#include <stdio.h>

int main(void)
{
int arr1[] = {1, 2, 3, 4, 5};
int ii, jj;

for(ii=0 ; ii<5 ; ii++)
        {
        jj = (ii<4) ? ii+1 : ii;

        printf("%d ", arr1[jj] );
        }

printf("\n" );
return 0;
}