Что не так?

Как уже ответили - надо учитывать погрешность. Примерно так


если конкретные величины, то так (чтобы индекс работал)


или хранить в INT, например умножив на 100, INT можно проверять на равенство.

Тут можешь почитать откуда погрешность берется

EugeneFrolСпасибо большое за помощь. В MSSQL у меня таких проблем не возникало.
Там какой тип использовался? Если там использовать float, то будут те же проблемы.

EugeneFrolК вашим предложениям я добавил еще свое:
SELECT * FROM Paint WHERE round(x2,2) = 55.5 AND round(y1,2) = 92.19;
или даже
SELECT * FROM Paint WHERE trim(x2)='55.5' AND trim(y2)='92.19';
И получил, что хотел.
Это нездоровое решение, т.к. при выборке не будет использован индекс, т.е. будет перебор всей таблицы.

EugeneFrolЯ рассуждал так: Если в полях все данных хранятся в текстовом виде, то при преобразовании в Double одно и тоже тестовое должно преобразоваться в одно и тоже значение Double и соответственно арифметически сравниваться на УРА.
А тут получается при каждом неявном преобразовании получаем разные Double. Вам не кажется это несколько странным?!
Никто не гарантирует что преобразование строка->число всегда происходит одним и тем же способом.

у double точность 15 десятичных разрядов. Если при конвертации в строку брать только 15, то строчное представление будет одинаково. Но в реале есть разница в 16-м разряде поэтому при сравнении в исходном виде эти числа не равны.
Выполни запрос

EugeneFrolЕсли я правильно понимаю при создании индексов можно использовать сложные индексные выражения с использованием core function, а так же указывать в SELECT использование конкретного индекса.
Не знаю, третий день в sqlite копаюсь, может и можно, план выполнения запроса надо смотреть, если задействует индекс, то можно.
EugeneFrolЕсли заставить SELECT сравнивать не арифметически, а побайтно trim(x2)='55.5'?
Тоже плохое решение?
Работать будет, но будет делать слишком много ненужных действий для конвертации число->строка. В БД число, а сравниваем строки.

Чем тебе мой вариант не нравится 21561153 x1 between 55.49999 and 55.50001 ? Т.е. получить интервал с учетом погрешности и проверять попадание в интервал.
Букав побольше, но ненужных действий минимум и индекс задействует при наличии индекса.

PS В БД никогда double не использовал по причине из-за которой у тебя сейчас проблемы, тут заменил бы на INT со сдвигом запятой, т.е. если надо два знака после запятой, то хранить x*100.

EugeneFrolDima TНикто не гарантирует что преобразование строка->число всегда происходит одним и тем же способом.


А если не преобразовывать? А сравнивать строки?
Где ты строку возьмешь если в БД лежит число?

Хранить в БД в виде строки тоже сомнительный вариант, сравнить конкретное значение сможешь, но невозможно сделать выборку диапазона.

EugeneFrolМне нужно:
SELECT * FROM Paint WHERE X1 = X2 AND Y1 = Y2
Результат 0 записей.
Беру, например
SELECT * FROM Paint WHERE X1 || 'x' || Y1 = X2 || 'x' || Y2;
Результат все записи, где X1 = X2 AND Y1 = Y2.

Если SQLite хранит в таблице REAL значения в строковом виде ему не придется в этом случае преобразовывать туда-обратно?
Или я ошибаюсь? НИКТО НИЧЕГО НЕ ГАРАНТИРУЕТ
Чукча писатель?
Я же уже несколько раз написал: в БД хранится REAL, т.к. ты указал при создании таблицы X1 REAL.
Если ты пишешь x1 = 55.5 то 55.5 преобразуется в тип REAL и дальше сравнение с ним, т.е. сравниваются два значения REAL.

По некоторым причинам в REAL невозможно точно сохранить, гарантия только 15 десятичных знаков, т.е. 55.5 на самом деле может быть как 55.50000000000001 так и 55.49999999999999. Соответственно если БД первое, а 55.5 преобразовалось во второе, то они не равны при сравнении как REAL.

Но при преобразовании в строку учитываются только первые 15 разрядов и оба варианта преобразуются в строку '55.5', поэтому когда ты сравниваешь как строки, то все правильно работает.
X1 || 'x' || Y1 на выходе строка. trim(x1) тоже строка.

Понял?

EugeneFrolМне нужно:
SELECT * FROM Paint WHERE X1 = X2 AND Y1 = Y2
Есть стандартная практика сравнения двух значений double: ABS(X1 - X2) < Epsilon, где Epsilon допустимая погрешность. Уже писал про это 21561153

Alibek B.Dima Tгарантия только 15 десятичных знаков
Нет такой гарантии.
Для некоторых значений возможны изменения и в более высоких разрядах.
Гарантия есть, т.к. мантисса 52 бита, следовательно вмещает 2^52 значений, что больше чем 10^15.
Другое дело что при вычислениях погрешность накапливается и в итоге может исказить 15-й разряд.