Damacy currently accepts integer source arrays but only exposes float32 and bfloat16 output. A uint16 read therefore requires conversion and, with float32 output, twice as many output bytes. Add signed and unsigned integer outputs so callers can preserve integer values and benchmark reads without an unnecessary output conversion. The CPU read study around #160 is one motivating use case.
Requested behavior:
- Support signed and unsigned 8-, 16-, 32-, and 64-bit output types on both CPU and GPU backends. Expose them through the C API and Python
BatchSpec, with short and full dtype names such as u16 / uint16 and i16 / int16.
- Preserve values exactly for same-type integer reads and lossless integer widening. These paths must not pass through float32: large 32- and 64-bit integers would lose precision. Extend source-type validation as needed for the corresponding integer identity reads.
- Define a consistent CPU/GPU conversion contract for signedness changes, narrowing, out-of-range values, and any supported float-to-integer casts, including rounding and NaN/infinity behavior. Explicitly reject unsupported conversions rather than leaving behavior to C/CUDA casts.
- Update output byte counts, buffer allocation, memory budgets, fill-value assembly, and Python/DLPack exports for each type's width and signedness. Retain the existing float32/bfloat16 behavior and enum values.
Validation should cover exact integer values and limits, including values above float32's exact-integer range; translated crops across chunks and shards; missing chunks with nonzero or negative fill values; and each defined conversion/error case. Check CPU-only builds, GPU results, Python consumer-visible dtypes, and output-buffer accounting. Add a uint16-to-uint16 benchmark comparison with the existing uint16-to-float32 path; its performance must be measured rather than inferred by rescaling the current byte rate.
Relevant implementation areas are src/damacy.h, src/damacy_config.c, src/executor/cpu_executor.c, src/assemble/assemble.cu, and python/damacy/_api.c.
Damacy currently accepts integer source arrays but only exposes
float32andbfloat16output. A uint16 read therefore requires conversion and, with float32 output, twice as many output bytes. Add signed and unsigned integer outputs so callers can preserve integer values and benchmark reads without an unnecessary output conversion. The CPU read study around #160 is one motivating use case.Requested behavior:
BatchSpec, with short and full dtype names such asu16/uint16andi16/int16.Validation should cover exact integer values and limits, including values above float32's exact-integer range; translated crops across chunks and shards; missing chunks with nonzero or negative fill values; and each defined conversion/error case. Check CPU-only builds, GPU results, Python consumer-visible dtypes, and output-buffer accounting. Add a uint16-to-uint16 benchmark comparison with the existing uint16-to-float32 path; its performance must be measured rather than inferred by rescaling the current byte rate.
Relevant implementation areas are
src/damacy.h,src/damacy_config.c,src/executor/cpu_executor.c,src/assemble/assemble.cu, andpython/damacy/_api.c.