Fixed adapting tolerance value according to data type in manifold MDS

[urvang96]

#### Reference Issues
Fixes #11159 .
check_symmetric: adapt tolerance to data type

#### What does this implement/fix? Explain your changes.
In manifold MDS set the tolerance values for the check_symmetric function as per the data type of input.

#### Any other comments?
Added a test.

[amueller]

Why these values? Why not dtype.eps? And input validation should probably not be this far down the stack.

[urvang96]

@Celelibi suggested using these values, so I tried using these values.

[amueller]

I think using the build-in eps or some factor of that would probably be more principled?

[urvang96]

Okay! I will try using eps rather than hard coding these values.

[jnothman]

Tests are still failing. Let us know if you need help.

[urvang96]

@jnothman I am facing two issues in this PR.

1. When I am using eps values it gives a tol value of 1.9E-7 for float32, but check_symmetric function gives error in that case. I tried different values and I think (eps*100) that is 1.9E-5 will solve the issue.

2. When I am giving a float16 input to fit_transform function, the dissimilarity matrix given after Euclidean distance calculation is float64. So I am not able to cover float16 test case.

[jnothman]

Yes, don't worry about float16 for now.​ I would've expected eps may be too small, but I've not looked into the context.

[jnothman]

Indeed, 1e-5 might make sense for float32 if 1e-10 is used for float64. But I suspect that what we're actually seeing here is a bug in euclidean_distances when working with float32, not merely an issue with the tol of check_symmetric. Really, we need to fix #9354 before we can work on this PR with euclidean distance as a test case. ​

[Celelibi]

Indeed, 1e-5 might make sense for float32 if 1e-10 is used for float64.

In my tests, 1e-5 might be too large with float32 in some cases with the current implementation of euclidean_distances. Here is a test-case showing an error greater than 2e-4.

>>> a = np.array([[0.1015854999423027, 0.9949246048927307], [0.1018471047282219, 0.9947648644447327]], dtype=np.float32)
>>> euclidean_distances(a)
array([[0.        , 0.00024414],
       [0.        , 0.        ]], dtype=float32)

[jnothman]

yes, let's put this on hold as i suspect the issue is not here but in euclidean_distances which was naively adapted to 32bit for the latest release

[amueller]

Fixed by #13554, I think. We can reopen if the issue persists.