Why does adding 0.1 and 0.2 miss an exact 0.3 report filter?

Prepare the report input

The fictional source supplies canonical integer tenths beside an approximate REAL display: one and two tenths. The report asks for exactly three tenths. Binary floating-point addition need not equal the binary value of literal 0.3; compare the canonical ticks.

Every record and report rule below is original and fictional. Reproduce the setup in a fresh SQLite test database; input previews include every table in this small fixture.

CREATE TABLE measures(id INTEGER PRIMARY KEY,batch TEXT NOT NULL,display_value REAL NOT NULL,tenths INTEGER NOT NULL); INSERT INTO measures VALUES(1,'A',0.1,1),(2,'A',0.2,2);

Compare misleading and corrected results

SELECT batch,SUM(tenths) AS tenths FROM measures GROUP BY batch HAVING SUM(display_value)=0.3 ORDER BY batch;

SELECT batch,SUM(tenths) AS tenths FROM measures GROUP BY batch HAVING SUM(tenths)=3 ORDER BY batch;

The REAL equality returns no rows; integer SUM(tenths)=3 returns batch A. This fix relies on the supplied exact tick field, not arbitrary rounding of unknown measurements.

Check a fresh boundary case

A zero reading with zero ticks preserves the exact total of three.

Recreate the original setup in another fresh database, then apply the change and corrected query below. For an empty result, the table displays a labelled empty-result marker rather than a data record.

INSERT INTO measures VALUES(3,'A',0.0,0);
SELECT batch,SUM(tenths) AS tenths FROM measures GROUP BY batch HAVING SUM(tenths)=3 ORDER BY batch;