Currently, we support the data types int8, int32, int64, float32, float64, complex64 and complex128.
Many matrices that occur regularly have low quantization (int8 often), but are relatively large. This requires jumping to int32 then, which itself would extend to float64 when combined with a single float32 number, or matrix along the path. Often observed: A Fourier transform would then default go to double for a not-so-obvious reason (low dimensionality, float32 input). If we had an int16 smaller int8 matrices could be processed using an accumulator that could promote to float32.
Long story short, there are some advantages:
type promotion produces more compact memory representations with lesser expensive operations
less memory, faster execution for data sets that are medium-sized but not that much that int32 would be required
On the downside there are (1) more type combinations to be tested. But I would think we could get rid of a lot of tests anyway by thinking sharply about them and (2) compile time of core/cmath could rise slightly (also as there are more combinations then). But that shouldn't be too hard.
Generally speaking, I'm in favour of this and would expect large benefits for common signal processing applications involving quantized data and models, e.g. evaluation of measurement data.
Currently, we support the data types int8, int32, int64, float32, float64, complex64 and complex128.
Many matrices that occur regularly have low quantization (int8 often), but are relatively large. This requires jumping to int32 then, which itself would extend to float64 when combined with a single float32 number, or matrix along the path. Often observed: A Fourier transform would then default go to double for a not-so-obvious reason (low dimensionality, float32 input). If we had an int16 smaller int8 matrices could be processed using an accumulator that could promote to float32.
Long story short, there are some advantages:
On the downside there are (1) more type combinations to be tested. But I would think we could get rid of a lot of tests anyway by thinking sharply about them and (2) compile time of core/cmath could rise slightly (also as there are more combinations then). But that shouldn't be too hard.
Generally speaking, I'm in favour of this and would expect large benefits for common signal processing applications involving quantized data and models, e.g. evaluation of measurement data.