Description
The current rust interface to arrayfire uses stricter type enforcement than the underlying C interface, which is good for safety but also prevents using e.g. arrayfire::constant
to create an array of the same type as another array, because
1- ConstGenerator
is private
2- get_type
can't return a type (so it returns a DType
)
3- There is no way to use a DType
instead of a type on which HasAfEnum
is defined when such a thing is required (i.e. pretty much everywhere)
4- HasAfEnum
's get_af_dtype
does not use a ...self
parameter so it's not possible to define HasAfEnum
on a DType
wrapper.
I see two obvious possible solutions for this issue:
1- Implement HasAfEnum
for DType
and possibly make get_af_dtype
take a ...self
argument as a result
2- Expose helper functions zeros_like
and ones_like
(at least) which yield, respectively, an array of zeros with the same type and shape as the input (an array), or likewise for an array of ones. With these, it's possible to create arbitrary arrays with the same dimensions and type as another array.
However I don't know if limiting the solution to this would impact performance too much. I recall reading that arrayfire can optimize sequences of operations but I don't know if such a usecase is covered.