SQLite Forum

ORDER BY not working for a specific DB/table
Login
Truly fascinating.  I've done some fiddling and here are my findings:
```
SQLite version 3.32.0 2020-05-22 19:31:42
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> create table mypar(x,y);
sqlite> insert into mypar VALUES (round(30.1233198123987303101203,1), round(30.817232123312));
sqlite> .dump
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE mypar(x,y);
INSERT INTO mypar VALUES(30.10000000000000142,30.999999999999999999);
COMMIT;
```
```
SQLite version 3.32.0 2020-05-22 19:31:42
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> create table mypar(x,y);
sqlite> insert into mypar VALUES (round(30.1233198123987303101203,1), round(30.817232123312));
sqlite> .dump
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE mypar(x,y);
INSERT INTO mypar VALUES(30.100000000000001421,31.0);
COMMIT;
```
```
SQLite version 3.32.0 2020-05-22 19:31:42
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> create table mypar(x,y);
sqlite> insert into mypar VALUES (round(30.1233198123987303101203,1), round(30.817232123312));
sqlite> .dump
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE mypar(x,y);
INSERT INTO mypar VALUES(30.100000000000002309,31.000000000000000888);
COMMIT;
```

These are all compiled and run from the same codebase using the same MinGW GCC 9.1.0 x64 compiler on the same Windows 10 for Workstations on the same Xeon processor, the only difference between them is the definition of a `long double (LONGDOUBLE_TYPE)` -- and I had also modified the codebase slightly to ensure that all uses of `long double` used the define `LONGDOUBLE_TYPE`.

In the first case, a `LONGDOUBLE_TYPE` is `long double`, or an 80-bit IEEE extended precision float.  
In the second case, a `LONGDOUBLE_TYPE` is `__float128`, or an 128-bit IEEE float.  
In the third case, a `LONGDOUBLE_TYPE` is `double`, or a standard 64-bit float.

So, the conclusion that I reached is that with the current code, 80-bit extended precision floats do not contain enough bits to produce 100% accurate "exactly rounded" results, and that MSVC seems to not implement extended precision at all and does all computations in 64-bit floating point.