[X] I searched in the issues and found nothing similar.
Version
version 1.3.3 (Build: ad95a7e)
Describe the bug and provide the minimal reproduce step
DROP DATABASE root.db0
CREATE DATABASE root.db0
CREATE TIMESERIES root.db0.t1 WITH datatype=FLOAT compressor=GZIP 'MAX_POINT_NUMBER'='6';
INSERT INTO root.db0(timestamp, t1) VALUES (1643027794590, 0.5522);
INSERT INTO root.db0(timestamp, t1) VALUES (1643027794600, 0.8044);
# query 1
select t1 from root.db0 where t1 <= 0.8044
# query 2
select t1 from root.db0 where cast(t1 as float) <= 0.8044
What did you expect to see?
Query 1 returned result set: 0.5522 and 0.8044
Query 2 returned result set: 0.5522 and 0.8044
What did you see instead?
Query 1 returned result set: 0.5522 and 0.8044
Query 2 returned result set: 0.5522
Anything else?
Dear IoTDB team, When using the CAST operator to convert a FLOAT value to FLOAT, the value theoretically should remain unchanged. However, the above test case indicates that a logical error causing precision loss occurs after the CAST conversion.
Search before asking
Version
version 1.3.3 (Build: ad95a7e)
Describe the bug and provide the minimal reproduce step
What did you expect to see?
Query 1 returned result set: 0.5522 and 0.8044
Query 2 returned result set: 0.5522 and 0.8044
What did you see instead?
Query 1 returned result set: 0.5522 and 0.8044
Query 2 returned result set: 0.5522
Anything else?
Dear IoTDB team, When using the CAST operator to convert a FLOAT value to FLOAT, the value theoretically should remain unchanged. However, the above test case indicates that a logical error causing precision loss occurs after the CAST conversion.
Are you willing to submit a PR?