Bug #107402 value has changed when 1e-16 is input of GIS expr

Description:
Gis expr st_latitude may cause precision problem.

How to repeat:
mysql> select st_latitude(st_geomfromtext('point(1e-16 1e-16)', 4326));
+----------------------------------------------------------+
| st_latitude(st_geomfromtext('point(1e-16 1e-16)', 4326)) |
+----------------------------------------------------------+
|                                    9.999999999999999e-17 |
+----------------------------------------------------------+

Actually it is 1e-16 right?

Hi Mr. Li,

Thank you for your bug report.

We have managed to repeat your test case with 8.0.29.

This report is now a verified bug.

Hi Wenbo Li,

I don't think it's a bug. See the following test case:

mysql> select st_x(st_geomfromtext('point(1e-16 1e-16)', 4326));
+---------------------------------------------------+
| st_x(st_geomfromtext('point(1e-16 1e-16)', 4326)) |
+---------------------------------------------------+
|                             9.999999999999999e-17 |
+---------------------------------------------------+

mysql> select st_x(st_geomfromtext('point(1e-16 1e-16)', 0));
+------------------------------------------------+
| st_x(st_geomfromtext('point(1e-16 1e-16)', 0)) |
+------------------------------------------------+
|                                          1e-16 |
+------------------------------------------------+
1 row in set (8.81 sec)

For your case, I think that the precision loss is due to the normalized transformation based on reference coordinate system(4326), which angular unit is 0.017453292519943278.

I think there is still a precision issue here, the value still changes after normalized translation. will this problem be dealt with in later version of mysql?

Yes, you are right.

double x = ...;
double x1 = x * 0.017453292519943278;
double x2 = x1 / 0.017453292519943278;

then, x2 != x.

It is impossible to avoid the precision issue.

Actually, there is a way to avoid this problem.

The reason why mysql need to transform lat/long to radian is that boost only accept radian as the geography input in my opinion. In st_latitude(st_x), is the procedure that transform lat/long to radian redundant?