… functions,

update the docstring of ivy.svd to mention the change of content of return when compute_uv is False,
update svd's torch backend to only compute the necessary second component to be more efficient and the relevant docstring in ivy.svd as well

…ple definition and behavior when compute_uv is false

…ple definition and behavior when compute_uv is false

…fixed the wrong shape and dtype of return. Now there are somehow numerial difference between return of groundtruth torch.svd and ivy.svd

…y of result instead of matching values

… skipping

… Can't call numpy() on Tensor that requires grad. Use tensor.detach().numpy() instead.

" happen

… instead of the normal tuple and apply the np.asarray(x) change over ivy.as_numpy in other tests, ensure the different return pattern (s,u,v tha u,s,v)from tensorflow and when comput_uv is false get handled in the tests. Now only dtype mismatches happens

…ps.svd

…timeError: Can't call numpy() on Tensor that requires grad. Use tensor.detach().numpy() instead." when the test function calls np.asarray to the returned value

…em is that the ground truth returns a ivy array with dtype the same as input, while the function returns a torch tensor with the torch version of that dtype.

…ubset_by_index parameter. tensorflow,torch and paddle backends are all failing due to significant value differences in only part of the reconstructed matrixes.

….svd produces significant difference with compute_uv=True (like flipped signs) in the reconstructed matrixes for all backends. I suspect that the decomposition of jax.lax.linalg.svd is different from other similiar functions

…ps.svd

…ps.svd

…ps.svd

…st_torch_svd, all tests passed

…ecompositions.py::test_numpy_svd, though seems like using ivy.astype to convert type does not work at all

….py::test_tensorflow_Svd, now the frontend somehow always return float64 nomatter input dtype

…lg.py::test_jax_svd

….py::test_tensorflow_Svd, though if input is complex number the results show large difference

…pack_ops.py::test_torch_svd so that complex number inputs are also tested, they are passing

…are also tested, they are all passing

…turn fixed dtypes depending on if input is complex,

…alue instead as the same as the input, but the documents shows that the S component will always be real, which is different from the groundtruth behavior shown in the, updated the jax svd tests to check for complex inputs

….svd fail for tensorflow backend due to significant and updated all relavent svd with more complex supported dtype

…ps.svd

…ps.svd

…ps.svd

…ps.svd