| FLOAT [сообщение #6288] |
Mon, 23 February 2026 08:46  |
bsa1959
Сообщений: 11
Зарегистрирован: December 2025
|
Junior Member |
|
|
Возникла проблема округления в процедуре FIREBIRD 5.
В таблице есть поле типа FLOAT. Имеет значения от 1.00 до 1.60 через 0.1.
Процедура возвращает нехорошие значения. Т.е. не соответствуют значениям посчитаным вручную.
Прошел под IBEXPERT в отладке.
Вместо 1.00 увидел 1.0139 для этого поля после чтения из таблицы...
Где я не прав?
Хотя по документации:
Тип данных FLOAT по умолчанию представляет собой 32-битный тип с плавающей запятой
одинарной точности с приблизительной точностью 7 десятичных знаков после десятичной
точки (24 двоичных знака). Числа типа FLOAT находятся в диапазоне от 1.175 x 10-38 до 3.402 x
1038.
[Обновления: Mon, 23 February 2026 08:54] Известить модератора |
|
|
|
|
|
| Re: FLOAT [сообщение #6292 является ответом на сообщение #6291] |
Mon, 23 February 2026 19:21  |
bsa1959
Сообщений: 11
Зарегистрирован: December 2025
|
Junior Member |
|
|
SD писал(а) Mon, 23 February 2026 15:22Ты путаешь точность отдельно взятого числа и точность серии расчётов пачки таких чисел.
Переходи на точные числа, раз у тебя шаг фиксированный.
Вы меня, наверное, не поняли....
я Записал в поле FLOAT 1.100
Почему я на чтении получаю этот результат?
Еще раз повторяю - на ЧТЕНИи. И через ibexpert....
[Обновления: Mon, 23 February 2026 19:23] Известить модератора |
|
|
|
|
|
| Re: FLOAT [сообщение #6294 является ответом на сообщение #6293] |
Tue, 24 February 2026 01:27 |
SD
Сообщений: 462
Зарегистрирован: August 2022
|
Senior Member |
|
|
Потому что это FLOAT. Он так устроен. Он так работает. Никогда не используй его.
Ну или жалуйся Хвастунову:
SQL> create table fl (f float);
SQL> insert into fl values(1.100);
SQL> select * from fl;
F
==============
1.1000000 [Обновления: Tue, 24 February 2026 01:30] Известить модератора |
|
|
|
|
|
| Re: FLOAT [сообщение #6296 является ответом на сообщение #6295] |
Tue, 24 February 2026 15:01 |
bsa1959
Сообщений: 11
Зарегистрирован: December 2025
|
Junior Member |
|
|
Влазит, конечно.
Но я склоняюсь к тому, что это ошибка самой БД.
И именно при select в процедуре, а может и функциях. Объявление принимающей переменной (например NUMERIC(15,3)) для поля FLOAT - ничего не меняет. Просто отсекаются лишние цифирьки. Ошибка составляет 1-2%. Это недопустимо.
И, наверняка, ее нужно исправлять...
[Обновления: Tue, 24 February 2026 15:24] Известить модератора |
|
|
|
|
|
| Re: FLOAT [сообщение #6298 является ответом на сообщение #6297] |
Tue, 24 February 2026 16:35 |
bsa1959
Сообщений: 11
Зарегистрирован: December 2025
|
Junior Member |
|
|
Если Вы прочитаете первое мое сообщение - я просил помощи...
А вместо помощи - хамство...
У меня select на таблицу с FLOAT возвращает такие-же красивые результаты...
А в процедуре - имею другой результат...
Буду пытаться сделать воспроизводимый пример. Оригинальный Select просто собирает данные с энного количества таблиц...
P.S. Select генериться в процедуре и выполняется через execute statement...
[Обновления: Tue, 24 February 2026 17:00] Известить модератора |
|
|
|
| Re: FLOAT [сообщение #6301 является ответом на сообщение #6298] |
Tue, 24 February 2026 19:50 |
sim_84
Сообщений: 358
Зарегистрирован: June 2022
|
Senior Member |
|
|
|
Процедура секретная? Без кода все эти утверждения о баге бла-бла-бла. Ну и numeric(15,3) в первом диалекте таки хранится как double precision, а не float. А если это не первый диалект, тогда вообще не понимаю ваше упорство с float. Уж если без чисел с плавающей запятой не обойтись, то используйте хотя бы double precision
|
|
|
|
SQLRU.net
Поиск
Помощь
Участники
Регистрация
Вход
Начало
