fix(framework): refactoring as_ivy_dev and as_native_dev in all backends

[abdulasiraj]

will also close, #18247

[github-actions]

Thanks for contributing to Ivy! 😊👏
Here are some of the important points from our Contributing Guidelines 📝:
1. Feel free to ignore the run_tests (1), run_tests (2), … jobs, and only look at the display_test_results job. 👀 It contains the following two sections:
- Combined Test Results: This shows the results of all the ivy tests that ran on the PR. ✔️
- New Failures Introduced: This lists the tests that are passing on master, but fail on the PR Fork. Please try to make sure that there are no such tests. 💪
2. The lint / Check formatting / check-formatting tests check for the formatting of your code. 📜 If it fails, please check the exact error message in the logs and fix the same. ⚠️🔧
3. Finally, the test-docstrings / run-docstring-tests check for the changes made in docstrings of the functions. This may be skipped, as well. 📚
Happy coding! 🎉👨‍💻

[ivy-leaves]

If you are working on an open task, please edit the PR description to link to the issue you've created.

For more information, please check ToDo List Issues Guide.

Thank you 🤗

[vedpatwardhan]

Hey @abdulasiraj, thanks for looking into this task, I think we could just use as_native_dev inside as_ivy_dev to avoid duplicating the fallback logic.
Happy to know your thoughts 😄

[abdulasiraj]

Hey @abdulasiraj, thanks for looking into this task, I think we could just use as_native_dev inside as_ivy_dev to avoid duplicating the fallback logic.
Happy to know your thoughts 😄

Hey @vedpatwardhan,
Thanks for your comment. Actually, I tried this but as_ivy_dev and as_native_dev has a little bit different logic. Also, both return different devices. so, as_native_dev can't be used inside the as_ivy_dev.

[vedpatwardhan]

Thanks for clarifying @abdulasiraj
I think what we should do in that case is get the common logic between these 2 functions (as_ivy_dev and as_native_dev) as a private helper which both of these functions would make use of, happy to know what you think 😄

[abdulasiraj]

Thanks for clarifying @abdulasiraj I think what we should do in that case is get the common logic between these 2 functions (as_ivy_dev and as_native_dev) as a private helper which both of these functions would make use of, happy to know what you think 😄

Yep, It'll be a good solution. let me try!
Thanks!

[abdulasiraj]

Hi @vedpatwardhan,
I created the private functions where possible but It's not possible for most of the time!

[vedpatwardhan]

Hi @vedpatwardhan, I created the private functions where possible but It's not possible for most of the time!

Actually in your PR, in the backends/jax/device.py for e.g., except for the ivy.Device calls in as_ivy_dev, rest of the code is the same as that in as_native_dev. We could avoid this code duplication through a single helper that executes this common functionality 😄

[sladyn98]

The creation of ivy.Device object is repeated multiple times. This can be minimized.

[abdulasiraj]

Hi @vedpatwardhan,

It's possible to add helper for torch and jax but for paddle it's not yet possible cuz paddle missing some functions. I've raised issue on paddlepaddle repo.
PaddlePaddle/Paddle#55977

[vedpatwardhan]

Hey @abdulasiraj, thanks for adding the helper for the jax and torch backends and also creating the issue on the paddle repo, just a few more suggestions,

1. dev_helper should be private, i.e. _dev_helper.
2. Probably we can reduce the duplication further, if you see the dev_helper for jax and torch, there isn't a lot of difference except for using jax.devices for jax and torch.device for torch. So we could in fact, move the _dev_helper to functional/ivy/device.py which accepts a native_device_fn argument and then we'll import this helper into our backend devices.py and pass the correct native_device_fn for torch and jax.
3. Could you please also bring your branch up to date with main? There were quite a few issues with the testing pipeline before, which have been fixed now, so updating your branch to be up to date with main should reduce the number of failures in the CI.

Happy to know what you think, thanks @abdulasiraj 😄

[ivy-seed]

This PR has been labelled as stale because it has been inactive for more than 7 days. If you would like to continue working on this PR, then please add another comment or this PR will be closed in 7 days.

[vedpatwardhan]

Hey @abdulasiraj, are you creating a different PR for this issue?

[github-actions]

PR Compliance Checks

Thank you for your Pull Request! We have run several checks on this pull request in order to make sure it's suitable for merging into this project. The results are listed in the following section.

Issue Reference

In order to be considered for merging, the pull request description must refer to a specific issue number. This is described in our contributing guide and our PR template.
This check is looking for a phrase similar to: "Fixes #XYZ" or "Resolves #XYZ" where XYZ is the issue number that this PR is meant to address.

[abdulasiraj]

Hey @abdulasiraj, are you creating a different PR for this issue?

Hey @vedpatwardhan,
I was working on some other important tasks on testing side and bot marked this PR as staled so I consider this to close. Due you think we should work on this or do you have someone on framework to work on this?. let me know your thoughts.
Thanks :)

[vedpatwardhan]

Hey @abdulasiraj, are you creating a different PR for this issue?

Hey @vedpatwardhan, I was working on some other important tasks on testing side and bot marked this PR as staled so I consider this to close. Due you think we should work on this or do you have someone on framework to work on this?. let me know your thoughts. Thanks :)

Got it! If you're busy with something else, @RickSanchezStoic could you please look into getting this over the line? I think we're done for the most part just a final few changes remaining. Thanks 😄

[abdulasiraj]

I'll create new PR for this

[github-actions]

Thank you for this PR, here is the CI results:

---

Failed tests:

This PR introduces the following new failing tests:
ivy_tests/test_ivy/test_functional/test_experimental/test_core/test_elementwise.py::test_diff,paddle
ivy_tests/test_ivy/test_frontends/test_tensorflow/test_math.py::test_tensorflow_scalar_mul,numpy
ivy_tests/test_ivy/test_frontends/test_tensorflow/test_math.py::test_tensorflow_scalar_mul,jax
ivy_tests/test_ivy/test_frontends/test_tensorflow/test_math.py::test_tensorflow_scalar_mul,tensorflow
ivy_tests/test_ivy/test_frontends/test_tensorflow/test_math.py::test_tensorflow_scalar_mul,torch
ivy_tests/test_ivy/test_functional/test_experimental/test_core/test_manipulation.py::test_partial_vec_to_tensor,paddle

[github-actions]

Thank you for this PR, here is the CI results:

---

Failed tests:

This PR introduces the following new failing tests:
ivy_tests/test_ivy/test_functional/test_experimental/test_core/test_elementwise.py::test_diff,paddle
ivy_tests/test_ivy/test_frontends/test_tensorflow/test_math.py::test_tensorflow_scalar_mul,numpy
ivy_tests/test_ivy/test_frontends/test_tensorflow/test_math.py::test_tensorflow_scalar_mul,jax
ivy_tests/test_ivy/test_frontends/test_tensorflow/test_math.py::test_tensorflow_scalar_mul,tensorflow
ivy_tests/test_ivy/test_frontends/test_tensorflow/test_math.py::test_tensorflow_scalar_mul,torch