Peter Lindstrom

@frobnitzem Thanks for filing this issue. We're aware of this; see discussion [here](https://github.com/LLNL/zfp/issues/201#issuecomment-1866151608) and more recently in #231. I'm trying to figure out the original intent and how to correct...

@JanLJL Thanks for your contribution. Let me begin by pointing out that we're in the midst of making significant changes to the CUDA (and HIP) implementation on the `staging` branch,...

I'm hoping to push some more recent work but am reluctant to do so until the code compiles and runs. Currently, the code is in a broken state, which is...

@jwake Thanks for your contribution. The parallel decoding implementation is currently wholly broken and will be rewritten over the coming months. We're currently re-engineering the block index representation and API,...

The purpose of the `stream_rseek` call is to update the `bitstream` state in host memory so that when you return from `zfp_decompress`, the stream is positioned correctly for the next...

@yurivict I think the `tests/python/test_utils.pyx` Cython file is the answer to your question. Most of our tests require CMake/CTest. Have you tried that? See also #227 in regards to more...

This looks like a valid complaint. Does the problem go away if you use `(uint64)blocks` and cast the return value to `size_t`? Per the [zfp installation instructions](https://zfp.readthedocs.io/en/release1.0.1/installation.html), support for 64-bit...

> Though I wonder if it would be possible to avoid the extended precision multiplication at all. zfp uses 64-bit integer arithmetic all over the place, especially in the innermost...

I don't see anything obvious in zfp that might cause such overrun. Just to be sure, you're calling `zfp_stream_set_accuracy()` with this "small" tolerance before calling `zfp_stream_maximum_size()` and then allocating a...

Another question: Do you observe the same issue when using the zfp CLI, i.e., without going through the Rust API? For example: `zfp -f -2 9900 16987 -a 0.0402 -i...