replace_scalar() should allow scalar value to be scalar type

[polarathene]

Out of curiousity is there a reason replace_scalar() restricts the scalar type to f64 and not allowing a user provided scalar type like constant_t() does? With constant_t() it's a little confusing why it asks for a DType and Scalar unless I've misunderstood how it works:

constant_t(Scalar::U8(42), dims, DType::U8 );
// vs typing regular constant, is there a difference?
constant::<u8>(42, dims);

Is there a reason for f64(thus limited to values of 2^53 accurately) that would prevent u64 being permitted? If not perhaps as a new method or when next breaking change update occurs, we could have something like:

pub fn replace_scalar(a: &mut Array, cond: &Array, b: Scalar)

[9prady9]

Regarding the signature of constant_t() - it provides the flexibility of creating an Array of type DType::F32 from an integer. If the scalar is of complex type, then the value of dtype is ignored and the returned Array will be of complex type. This is a bit complex behaviour and could use a more detailed explanation in the documentation - perhaps a table with input combinations and corresponding output type would help a lot for this function. I have updated the #52 with this docs update suggestion, thank you.

As far as why the scalar parameter to replace_scalar is f64 - it is limitation from upstream. ArrayFire C-API doesn't have version of replace_scalar that takes in u64. There isn't much that can be done at rust wrapper level to handle this limitation. You are welcome to raise an issue on ArrayFire repository for this feature.

Note: Please note that a lot of documentation is still a work in progress because of the very limited bandwidth we can allocate towards it, we are sorry for the inconvenience caused due to this.

[polarathene]

Note: Please note that a lot of documentation is still a work in progress because of the very limited bandwidth we can allocate towards it, we are sorry for the inconvenience caused due to this.

That's ok @9prady9 , I understand :) Thanks for pointing that out. If I have the time spare I will contribute to documentation or examples in future. I'll raise the issue with upstream. One feature they seem to have natively is assignment, they can apply an index to an array and then apply arithmetic and only those values are updated in the Array. For Rust wrapper, when we use index methods it extracts that into a new array without an easy way to merge it back into the original.

eg index 2nd and 4th columns from a 5 col array and multiply values.