Peter Lindstrom

> But, this does appear to now handle array types. It is passing all tests on the pi with HDF5-1.14.5. Very cool. But how is zfp informed of the array...

> > Right, and presumably those would be the fastest varying dimensions. Thus, you can't just add extra outer dimensions to zfp_field. For example, an nx * ny array of...

> Appending vs. prepending can be a bit confusing since C and HDF5 use C order (rightmost dimension varies fastest) while zfp uses Fortran order (leftmost dimension varies fastest) to...

> Ok, so when a chunk arrives at the filter, if we use ZFP's striding feature...which sounds like a great thing to do by the way. Does it mean we...

We are indeed working on another release that will include variable-rate decompression, which includes fixed-precision mode. We are hoping to complete this work within the coming months.

It probably would make sense to add something like `__version__ = ZFP_VERSION_STRING` to zfpy. @Danielle-Asher I believe you were working on something along these lines a while back. With respect...

As discussed offline, (de)serialization indeed appears broken. A possible workaround for serialization of a concrete array `arr` of type `arr_type` (e.g., `zfp::array3`) is to use the derived type `arr_type::header` as...

There's no reason I'm aware of why zfp cannot be built with CUDA support on Windows. We unfortunately do not have a CUDA-capable Windows machine that would allow us to...

So the CMake warning is related to #232, which we will fix in the next release. Still, CUDA is found, so presumably that's not the cause. From NVIDIA docs, your...

I just noticed this CMake line: https://github.com/LLNL/zfp/blob/a46fa8b91bf2d69f4ffcf04af4f908383828ba79/src/CMakeLists.txt#L44-L46 What happens if you comment this out?