[MDEV-29794] select max(float) returns the wrong float Created: 2022-10-14  Updated: 2022-10-14  Resolved: 2022-10-14

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Insert
Affects Version/s: 10.3.4
Fix Version/s: N/A

Type: Bug Priority: Trivial
Reporter: C S Assignee: Unassigned
Resolution: Not a Bug Votes: 0
Labels: float, max()


 Description   

Selecting the max of a float value does something wonky with the precision of the value. I can't make sense of the below example.

{{MariaDB [imdb_small]> drop table example;
Query OK, 0 rows affected (0.006 sec)

MariaDB [imdb_small]> create table example (a float);
Query OK, 0 rows affected (0.009 sec)

MariaDB [imdb_small]> insert into example values (8.7);
Query OK, 1 row affected (0.002 sec)

MariaDB [imdb_small]> select max(a) from example;
-------------------

max(a)

-------------------

8.699999809265137

-------------------
1 row in set (0.000 sec)

MariaDB [imdb_small]> select a from example;
------

a

------

8.7

------
1 row in set (0.000 sec)

MariaDB [imdb_small]> select * from example where a = 8.7;
Empty set (0.000 sec)}}



 Comments   
Comment by C S [ 2022-10-14 ]

funny

MariaDB [imdb_small]> select * from example where a = 8.699999809265137;
------

a

------

8.7

------
1 row in set (0.001 sec)

Comment by Alice Sherepa [ 2022-10-14 ]

Please upgrade to the latest version of MariaDb, current for 10.3 is 10.3.36

Comment by C S [ 2022-10-14 ]

Is this a known bug?

Comment by Alice Sherepa [ 2022-10-14 ]

This is not specific for MariaDB, but floating-point accuracy (https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems, https://learn.microsoft.com/en-us/office/troubleshoot/access/floating-calculations-info, https://mariadb.com/kb/en/floating-point-accuracy/).
It is recommended if you wish to use accurate floating point storage to use the DECIMAL data type.
10.3.4 is a nearly 5years old version, so I would definitely recommend upgrading because a lot of bugs were fixed since that.

Generated at Thu Feb 08 10:11:20 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.