Permit "same_kind" casting for element-wise in-place operators

[antonwolfy]

The PR proposes to permit "same_kind" casting for element-wise in-place operators. The implementation leverages on dpctl changes added in scope of PR#1827.

It also adds callbacks to support in-place bit-wise operators (leverages on dpctl changes from RR#1447).

The PR removes a temporary workaround from dpnp.wrap which depends on the implemented changes.

• Have you provided a meaningful PR description?
• Have you added a test, reproducer or referred to issue with a reproducer?
• Have you tested your changes locally for CPU and GPU devices?
• Have you made sure that new changes do not introduce compiler warnings?
• Have you checked performance impact of proposed changes?
• If this PR is a work in progress, are you filing the PR as a draft?

[github-actions]

View rendered docs @ https://intelpython.github.io/dpnp/pull/2170/index.html

[AlexanderKalistratov]

Is this a good idea?
If I call dpnp.add(a, b, out=a) the code would follows some different path?
So we have two different code paths for inplace ops?

[antonwolfy]

This is how it was designed in dpctl. That PR is attempt to adopt to the API extension exposed by dpctl library.
Also dpnp.add._inplace_op path is much more simplier: some of the validation checks is not necessary there.

For sure, dpnp.add._inplace_op path can be subpart of dpnp.add(a, b, out=a) path in case when out refers to same memory as an input array, but I believe that has to be done by dpctl, not in dpnp.

[AlexanderKalistratov]

AFAIK array api doesn't support out parameter, so dpctl does not support it either. So it cannot be implemented inside dpctl.

I believe separating these two paths in dpnp is extremely bad idea. Which also requires more code changes than just making add._inplace_op as subpath of add.

[antonwolfy]

dpctl supports out keyword, but it's true that python array API doesn't.

[antonwolfy]

The reason why we have to separate the paths it is a deference in allowed type promotion in

1. dpt.add(a, b, out=a)
2. a += 2

dpctl requires "safe" type casting in the 1st use case, while for the 2nd one it permits "same_kind".
It can be illustrated below

a = dpt.ones(10, dtype='f4')
b = dpt.ones(10, dtype='f8')

a += b # it works

dpt.add(a, b, out=a)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[9], line 1
----> 1 dpt.add(a, b, out=a)

File /localdisk/work/antonvol/soft/miniforge3/envs/numpy_20/lib/python3.12/site-packages/dpctl/tensor/_elementwise_common.py:653, in BinaryElementwiseFunc.__call__(self, o1, o2, out, order)
    647     raise ValueError(
    648         "The shape of input and output arrays are inconsistent. "
    649         f"Expected output shape is {res_shape}, got {out.shape}"
    650     )
    652 if res_dt != out.dtype:
--> 653     raise ValueError(
    654         f"Output array of type {res_dt} is needed, "
    655         f"got {out.dtype}"
    656     )
    658 if (
    659     dpctl.utils.get_execution_queue((exec_q, out.sycl_queue))
    660     is None
    661 ):
    662     raise ExecutionPlacementError(
    663         "Input and output allocation queues are not compatible"
    664     )

ValueError: Output array of type float64 is needed, got float32

That way we can't leverage on dpt.add(a, b, out=a) behavior while implementing in-place operations in dpnp. It has more strict limitations then we need to.

[AlexanderKalistratov]

And what numpy do in this case?

[antonwolfy]

NumPy allows both use cases.