bitwise XOR assignment fails on 1st dimension

[polarathene]

Not sure why this is failing, trying array_a ^= array_b both are U64 type elements, error "Size is incorrect"

Detailed error:

In function void assign(opencl::Array<T>&, const unsigned int&, const af_seq*, const opencl::Array<outType>&) [with Tout = long long unsigned int; Tin = long long unsigned int; af_seq = af_seq]
In file src/api/c/assign.cpp:36
Invalid dimension for argument 0
Expected: (outDs.ndims()>=(dim_t)ndims)

array_a:

[1 1 1 1]
       819 

array_b:

[1 1 1 1]
   1296111 

Example code:

let dims = Dim4::new(&[1, 1, 1, 1]);
let mut array_a = af::Array::new(&[819u64], dims);
let array_b = af::Array::new(&[1296111u64], dims);

array_a ^= array_b;

---

I think this is possibly related to the indexing bug @9prady9 recently fixed. If I increase row elements it fails, if I increase by column elements no crash. I guess I need to wait until the crate is updated?

[polarathene]

Just tried the devel branch with the bug fix that was committed and no luck.

[polarathene]

bixor() method works without crashing.

---

While looking into this operator, is it possible to support arithmetic against numbers(eg array_a *= 2)?

I noticed I can do array_a = array_a * 2 but some operators like shift fail array_a = array_b << 8 requiring the shiftl() method to use(I'm not sure if batched being true or false matters when supplying a number, does it make a difference?)

In addition to that, array_a += 42 vs array_a = array_a + 42, does the JIT compiler optimize for this, or will the GPU array allocate memory for a new array on the 2nd example instead of updating the values like the 1st example presumably does(does it?). If I'm right, it might be good to have a method to allow us to assign/update elements, this seems to happen easily on C++ but when we have to use a method that returns an Array if that's a newly allocated one on the GPU that can be a problem.

Indexing is a good example where on C++ you can apply an index to update select values getting the +=42 but on Rust indexing returns an array of those values as a new array(updating them does not update the original arrays values).

[9prady9]

@polarathene I found a much bigger issue with Indexerstruct and Indexer::set_index which is what I am working now, hence reopened the #138. The bit assign ^= uses indexing internally. So, you would see similar problems using it.

[9prady9]

As I said earlier, there is a know issue with indexing and I am currently looking into it. Closing this issue.

[polarathene]

This applies to all assign ops I think(just ran into it again with +=), though you probably already knew that :)

Doing a = a ^ b works, which I guess is what the method equivalents do. At least my lengthy equation can be slimmed back down a bit(really not nice to look at with method chains like this :P :

// Quite a few calculations like this one
a = bitxor(sub(&a, &add(&b, &c, true), true), &shiftr(&c, &x[0], true), true);
// vs 
a = (a-(b + c)) ^ (c >> &x[0]);
a = (&a-(&b + &c)) ^ &shiftr(&c, &x[0], true); // AF version

[9prady9]

@polarathene I have put in a fix for this in devel just now. Can you please test it on your end and let me know if everything is working fine. The borrow check will complain now if you are using temporarily allocated Arrays to call set_index. The ops such as += should also be fixed with this.