Eigenvectors from `tf.linalg.eig` differ drastically compared to NumPy and other frameworks
@sachinprasadhs,
I was able to reproduce the issue on tensorflow v2.12 and nightly. Kindly find the gist of it [here](https://colab.research.google.com/gist/tilakrayal/96674a9bf99783bd35591caa12500f44/untitled1143.ipynb). i am looking the implementation hope will be able to find about it
 **``` tf.linalg.eig ```**
is implemented with the help of **``` from tensorflow.python.ops import gen_linalg_ops```** but i am unable to find the implemetation of **```  gen_linalg_ops```** so someone can help me here > **`tf.linalg.eig`** is implemented with the help of **` from tensorflow.python.ops import gen_linalg_ops`** but i am unable to find the implemetation of **` gen_linalg_ops`** so someone can help me here

Anything with `gen_` in front is an auto-generated wrapper around C++ code.  In this case, the `Eig" op.  The implementation is [here]( https://github.com/tensorflow/tensorflow/blob/efcc8ded70356d66755f1b00b7f4efc69d5db44d/tensorflow/core/kernels/linalg/eig_op_impl.h#L35), but it just uses the Eigen math library to compute eigenvectors.

As for why they are different: if they are all correct (i.e. TF's result is different but still satisfies the eigenvalue equations) it might just be because it uses a different algorithm.  Other libraries might all use the same, or even the same underlying implementation.  Eigenvectors are unique up to choice of sign in the case of unique eigenvalues, but if you have a repeated eigenvalue, then the corresponding vectors form subspaces, so there are infinitely many that bases that are valid.

 so, tensorflow is  just providing the different basis of the eigenvectors in this case Verified that TF's results are equally correct.  Didn't notice earlier we were talking about complex eigenvectors, in which case eigenvectors are unique up to multiplying by any complex constant - which is what we're seeing here. Are you satisfied with the resolution of your issue?
<a href="https://docs.google.com/forms/d/e/1FAIpQLSfaP12TRhd9xSxjXZjcZFNXPGk4kc1-qMdv3gc6bEP90vY1ew/viewform?entry.85265664=Yes&entry.2137816233=https://github.com/tensorflow/tensorflow/issues/60590">Yes</a>
<a href="https://docs.google.com/forms/d/e/1FAIpQLSfaP12TRhd9xSxjXZjcZFNXPGk4kc1-qMdv3gc6bEP90vY1ew/viewform?entry.85265664=No&entry.2137816233=https://github.com/tensorflow/tensorflow/issues/60590">No</a>

<details><summary>Click to expand!</summary> 
 
 ### Issue Type

Bug

### Have you reproduced the bug with TF nightly?

Yes

### Source

source

### Tensorflow Version

tf 2.11.1

### Custom Code

Yes

### OS Platform and Distribution

Linux Ubuntu 20.04.6 LTS Github Codespaces

### Mobile device

_No response_

### Python version

3.10.4

### Bazel version

_No response_

### GCC/Compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current Behaviour?

The `tf.linalg.eig` function seems to return eigenvectors that vastly deviate from NumPy and other popular frameworks like PaddlePaddle and PyTorch, even though the eigenvalues returned are practically identical. All the rest of the frameworks also return identical eigenvectors within a tolerance of `1e-5` at the very least. What might be the reason behind this?

Framework versions:
`numpy==1.24.2`
`paddlepaddle==2.4.2`
`torch==2.0.0+cu117`

### Standalone code to reproduce the issue

```shell
import torch
import paddle
import numpy as np
import tensorflow as tf

x = np.array([[1.+1.j, 1.+1.j], [1.+1.j, 1.+2.j]], dtype="complex64")

eigenvalues_np, eigenvectors_np = np.linalg.eig(x)
eigenvalues_tf, eigenvectors_tf = tf.linalg.eig(tf.constant(x))
eigenvalues_paddle, eigenvectors_paddle = paddle.linalg.eig(paddle.to_tensor(x))
eigenvalues_torch, eigenvectors_torch = torch.linalg.eig(torch.tensor(x))

print(eigenvectors_np)  # [[0.79041606+0.j, 0.5943483-0.14829884j], [-0.5943483+0.14829884j,  0.79041606+0.j]]
print(eigenvectors_tf.numpy())  # [[-0.790416 +0.j, 0.4592307 +0.40540066j], [0.59434843-0.14829884j, 0.44829237+0.65099263j]]
print(eigenvectors_paddle.numpy())  # [[0.790416 +0.j, 0.5943484 -0.14829883j], [-0.5943483 +0.1482988j, 0.79041606+0.j]]
print(eigenvectors_torch.numpy())  # [[0.7904161 +0.j, 0.5943483 -0.1482988j], [-0.5943483 +0.14829884j,  0.79041606+0.j]]

print(np.allclose(eigenvalues_np, eigenvalues_tf.numpy(), atol=1e-5))  # True
print(np.allclose(eigenvalues_np, eigenvalues_paddle.numpy(), atol=1e-5))  # True
print(np.allclose(eigenvalues_np, eigenvalues_torch.numpy(), atol=1e-5))  # True

print(np.allclose(eigenvectors_np, eigenvectors_tf.numpy(), atol=1e-5))  # False
print(np.allclose(eigenvectors_np, eigenvectors_paddle.numpy(), atol=1e-5))  # True
print(np.allclose(eigenvectors_np, eigenvectors_torch.numpy(), atol=1e-5))  # True
```


### Relevant log output

```shell
[[ 0.79041606+0.j          0.5943483 -0.14829884j]
 [-0.5943483 +0.14829884j  0.79041606+0.j        ]]
[[-0.790416  +0.j          0.4592307 +0.40540066j]
 [ 0.59434843-0.14829884j  0.44829237+0.65099263j]]
[[ 0.790416  +0.j          0.5943484 -0.14829883j]
 [-0.5943483 +0.1482988j   0.79041606+0.j        ]]
[[ 0.7904161 +0.j          0.5943483 -0.1482988j ]
 [-0.5943483 +0.14829884j  0.79041606+0.j        ]]
True
True
True
False
True
True
```
</details>