fix: ivy.linalg.matrix_norm() for paddle backend

[Kacper-W-Kozdon]

PR Description

• Type-casting to the dtype argument through the @infer_dtype decorator and ivy.astype(x, dtype).as_native().
• Added dtype argument to array and container methods.
• Added type-casting to float32 for the out argument passed down to torch backend- out argument has to be of the same type as the return of torch.linalg.matrix_norm() (float32).
• Test coverage for all valid dtypes.

Current issues:

• Gradient tests for paddle have problems with max() and min() functions (I will write just for max()) due to different implementations between backends (look up paddle.max() vs paddle.amax() or torch.max() vs torch.amax()). Tensorflow, numpy, torch and jax pass all the tests alike.

Related Issue

Continuation of the issue #28314 and PR #28323

Closes #28314

Checklist

• Did you add a function?
• Did you add the tests?
• Did you run your tests and are your tests passing?
• Did pre-commit not fail on any check?
• Did you follow the steps we provided?

Socials

[Kacper-W-Kozdon]

Hey @vedpatwardhan , new observation (which might be a coincidence but might also point to the issue with paddle backend)- whenever ivy.linalg.matrix_norm() for ord in [-float("inf"), -2, -1, 1, 2, float("inf")] returns rubbish gradients when the backend uses amax, it returns the correct results with max; and the other way around is true (and happens) as well- when max returns wrong results, amax returns the correct ones. I have zero clue what is wrong with paddle but it's not the fault of ivy's implementation of gradients or anything else- I have been checking it with raw paddle to compare the results to ivy's ones on the side as a sanity check. My suggestion would be either opening an issue directly in the paddle github or modifying how amax is handled in the ivy backend. The fact that when the gradient of amax returns rubbish results, max works, suggests, that the problem occurs when there are no multiples in the outputs of max.

EDIT:
If you wish, I can prepare a jupyter notebook with an explanation, because it seems that the results might be salvageable. In fact, maybe even without touching gradients, but that would require noticable changes in the paddle backend, either directly in the min()/max() functions or just in the matrix_norm().

[vedpatwardhan]

Hey @vedpatwardhan , new observation (which might be a coincidence but might also point to the issue with paddle backend)- whenever ivy.linalg.matrix_norm() for ord in [-float("inf"), -2, -1, 1, 2, float("inf")] returns rubbish gradients when the backend uses amax, it returns the correct results with max; and the other way around is true (and happens) as well- when max returns wrong results, amax returns the correct ones. I have zero clue what is wrong with paddle but it's not the fault of ivy's implementation of gradients or anything else- I have been checking it with raw paddle to compare the results to ivy's ones on the side as a sanity check. My suggestion would be either opening an issue directly in the paddle github or modifying how amax is handled in the ivy backend. The fact that when the gradient of amax returns rubbish results, max works, suggests, that the problem occurs when there are no multiples in the outputs of max.

EDIT: If you wish, I can prepare a jupyter notebook with an explanation, because it seems that the results might be salvageable. In fact, maybe even without touching gradients, but that would require noticable changes in the paddle backend, either directly in the min()/max() functions or just in the matrix_norm().

I'd say let's create a minimal example of the incorrect gradients and create an issue on the paddle repo regarding this, but probably what we'll get as the reply is that inf is the problem. Thanks for the efforts so far @Kacper-W-Kozdon 😄

[Kacper-W-Kozdon]

Hey @vedpatwardhan , I implemented the workaround, it works- with --num-examples=500 all of the tests passed (including gradient tests) 😄 Could you double-check it? Especially in the paddle backend, statistical.py::min and statistical.py::max

[vedpatwardhan]

Hey @Kacper-W-Kozdon, seems like there's a few other test failures that have arised as a result of these changes (e.g. this), could you please take a look at this and other failures that are pointed in the workflow if any of them are related? Thanks 😄

[Kacper-W-Kozdon]

Hey @Kacper-W-Kozdon, seems like there's a few other test failures that have arised as a result of these changes (e.g. this), could you please take a look at this and other failures that are pointed in the workflow if any of them are related? Thanks 😄

Oh! My bad, thanks for checking that thoroughly- the changes to min() and max() caused problems in other functions because I did not consider NoneType input for the axis argument 👍should be fixed now but we'll see what the workflow shows.

[vedpatwardhan]

lgtm, there don't seem to be any additional failures introduced. Feel free to merge the PR @Ishticode, thanks @Kacper-W-Kozdon 😄