float32 representation of pi/2 is rejected by `Latitude`

Description

The closest float32 value to pi/2 is by accident slightly larger than pi/2:

In [5]: np.pi/2
Out[5]: 1.5707963267948966

In [6]: np.float32(np.pi/2)
Out[6]: 1.5707964

Astropy checks using float64 precision, rejecting “valid” alt values (e.g. float32 values read from files):

In [1]: from astropy.coordinates import Latitude

In [2]: import numpy as np

In [3]: lat = np.float32(np.pi/2)

In [4]: Latitude(lat, 'rad')
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In [4], line 1
----> 1 Latitude(lat, 'rad')

File ~/.local/lib/python3.10/site-packages/astropy/coordinates/angles.py:564, in Latitude.__new__(cls, angle, unit, **kwargs)
    562     raise TypeError("A Latitude angle cannot be created from a Longitude angle")
    563 self = super().__new__(cls, angle, unit=unit, **kwargs)
--> 564 self._validate_angles()
    565 return self

File ~/.local/lib/python3.10/site-packages/astropy/coordinates/angles.py:585, in Latitude._validate_angles(self, angles)
    582     invalid_angles = (np.any(angles.value < lower) or
    583                       np.any(angles.value > upper))
    584 if invalid_angles:
--> 585     raise ValueError('Latitude angle(s) must be within -90 deg <= angle <= 90 deg, '
    586                      'got {}'.format(angles.to(u.degree)))

ValueError: Latitude angle(s) must be within -90 deg <= angle <= 90 deg, got 90.00000250447816 deg

Expected behavior

Be lenient? E.g. only make the comparison up to float 32 precision?

Actual behavior

See error above

Steps to Reproduce

See snippet above.

System Details

Linux-5.15.65-1-MANJARO-x86_64-with-glibc2.36
Python 3.10.7 (main, Sep  6 2022, 21:22:27) [GCC 12.2.0]
Numpy 1.23.3
pyerfa 2.0.0.1
astropy 5.0.1
Scipy 1.9.1
Matplotlib 3.5.2

[maxnoe]

I’ll open a PR with unit test cases and then we can decide about the wanted behaviour for each of them

[maxnoe]

That wouldn’t solve the case where the value is read from a float32 into a float64, which can happen pretty fast due to the places where casting can happen. Better than nothing, but…