Huge arrays in gp/PARI

[Ilya Zakharevich <nospam-abuse@ilyaz.org>]

IIRC, initially, when the bit operations were added to PARI (maybe
even by myself), the purpose was to have cheap huge arrays.  However,
(the most important) one of the operations needed for this
   bitset_inplace(bitmap,offset,smallbitmap,{count=1})
did not make into the current version.  The (possible) semantic:

  Sets the bit at position offset to the value smallbitmap.  Moreover,
  if smallbitmap is an array, then its elements are used to set #smallbitmap
  bits in x (from lsb to msb).  (Negative smallbitmap (and elements of
  the small arrays) are treated as in other bit operations.  (offset
  is always scalar.)

  (Most probably, this was not “very” compatible with the memory model?
   Due to the presence of read-only and “shared” integers?)

However, a major change happened from that time: PARI got a new type
Vecsmall very similar to BigInt, but WHICH HAS MUTABLE ELEMENTS.
Moreover, I do not know of the cases when these GEN⸣s are read-only or
shared.

⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜  This leads to the following proposal:

  Make all bit operations works not only on integers, but also on
  Vecsmall⸣s.  (They should be considered as little-endian base=2^64
  [or 2^32] unsigned integers.)

With this enhancement, the operation bitset_inplace() described above
becomes compatible with the current memory model, with the following
restrictions:

  • Above, the argument bitmap should be replaced by ~bitmaparray.
  • offset+count is small enough to fit into this array.

⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜  Maybe also:

Likewise, one can proceed for other bit ops
    bitandinplace(~x,val,{offset=0},{count=1})
In particular,
    bitxorinplace(~x,-1,{offset=0},{count=1})
flips bits at positions offset ... offset+count-1.  (Like
bitneginplace() — if it were useful.)

Ilya