gpakosz / packedarray Goto Github PK

I only really know the symptoms of the (possible) bug, no idea about the cause. I'll keep my description high level so others know the gist of the issue, happy to answer additional questions.

I get different results from my program when I use PackedArray *f = PackedArray_create(1, len); vs PackedArray *f = PackedArray_create(2, len);. The only line of code modifying the array is PackedArray_set(f, offset, 1); and as such the number of bits should not matter.

Posting for the sake of others information. I attempted to use an array of mutexes to guard segments of a PackedArray to reduce the delay caused by threads waiting single-file to write to the PackedArray. This approach works fine with normal arrays. However with the PackedArray I was getting inconstant results.

This suggests that any invocation of the PackedArray_get / PackedArray_set should be guarded by a mutex, even if the individual index is guarded.

Hi @gpakosz ,

Greeting from me!

I am reading PackedArray's code, and come across the following statement:

packed |= *out & ~((uint32_t)(1ULL << ((((uint64_t)count * (uint64_t)PACKEDARRAY_IMPL_BITS_PER_ITEM + startBit - 1) % 32) + 1)) - 1);

Why not just use:

packed |= *out & ~((uint32_t)(1ULL << (((uint64_t)count * (uint64_t)PACKEDARRAY_IMPL_BITS_PER_ITEM + startBit) % 32)) - 1)

What is the difference between these two methods?

Thanks very much in advance!

Bets Regards
Nan Xiao

The documentation lists several macros which are supposed to customize the behaviour of the library. However, it doesn't specify what exactly this does. Would you be able to explain (and maybe include it)?

It seems there is a limit to use a uint32_t for the count parameter of the PackedArray_create() function. Do you foresee any major issues modifying the code downstream to allow for a uint64_t count so I can populate it with more than 2^32 elements?