DBGrid отображает не тот Float, что я ввел.

[pu4koff]

Книжки не пробовали читать? В них написано про погрешности вещественных чисел. Что нельзя тупо сравнивать их, а нужно при сравнении делать поправку на погрешность вещественного типа. При выводе на экран так же нужно делать поправку на необходимую точность. Не может в типе float храниться именно 12.3 по определению.
UDF - созданы не для костылей и округление - не есть костыль, а функция, которая напрямую не относится к СУБД и именно поэтому вынесена наружу.
Покажите хоть одну СУБД, которая в вещественном поле будет хранить именно введенное 12.3, а не какое-нибудь 12.3000001907349.
Если не умеете пользоваться вещественными числами, то не надо гнать про кривость рук людей, которые реализовывали их в ЭВМ.

[Yurk@]

данную проблему я обходил с помощью замены Float на Numeric(7,2) а работал с ним как с Float

[soleil@mmc]

Сообщение от pu4koff

Покажите хоть одну СУБД, которая в вещественном поле будет хранить именно введенное 12.3, а не какое-нибудь 12.3000001907349.

книжки читаю
пользуюсь ораклом и не имею танцев с бубнами вокруг ненужных мне чисел в вещественном поле
что я делаю не так?

Сообщение от pu4koff

Если не умеете пользоваться вещественными числами, то не надо гнать про кривость рук людей, которые реализовывали их в ЭВМ.

вот за такие пассажи и не любят программеров
потому что когда просят сделать чтобы работало как надо, то они начинают рассказывать про то как кто-то когда-то что-то там изобрел/настроил/придумал и что оно именно так и должно работать вместо того чтобы сделать как просят

речь как раз не про то что я не знаю как хранятся вещественные числа, а про то что есть тип данных, который декларирует возможность хранения чисел с определенной точностью, а на самом деле там бардак

[pu4koff]

Сообщение от soleil@mmc

книжки читаю

Тогда должны знать как устроен тип float и после запятой обычно точность идёт до 6-7 знаков. Берём пример автора и сравниваем числа:
12.3 и 12.3000001907349. Во втором числе убираем все неправильные числа, что в конце получились и имеем: 12.300000. Считаем и получаем точность в 6 знаков после запятой. Что не так?
Введите 100 миллионов и увидите 100 миллионов. Введите 100 миллионов один и увидите опять 100 миллионов.

Сообщение от soleil@mmc

пользуюсь ораклом и не имею танцев с бубнами вокруг ненужных мне чисел в вещественном поле
что я делаю не так?

Не знаю как там оракл их хранит, может как-то иначе, но: Вы эти числа используете потом в программе на Delphi, C++,..., т.е. переводите в вещественный формат данных языков программирования или только в оракле с ними работаете? Сколько знаков после запятой выводите? Уверены, что хранится именно 12.3, а не 12.3000001907349? Может на экран выводится 3 знака после запятой и проблем с вещественными числами не видно.

Сообщение от soleil@mmc

вот за такие пассажи и не любят программеров
потому что когда просят сделать чтобы работало как надо, то они начинают рассказывать про то как кто-то когда-то что-то там изобрел/настроил/придумал и что оно именно так и должно работать вместо того чтобы сделать как просят

Ну придумайте тип данных для хранения дробных чисел, чтобы он умещался в 4 байта, имел диапазон значений как у float'a и скорость вычислений была нормальной. Нужно просто выбирать типы данных с умом. Давайте еще деньги в float-полях хранить.
Вот инфа по вещественным числам в Interbase http://ibase.ru/devinfo/round.htm (полезная инфа не только для данной СУБД, но и в целом, т.к. float там такой же как в делфях, С++,...). Я ничего криминального не вижу.

Сообщение от soleil@mmc

речь как раз не про то что я не знаю как хранятся вещественные числа, а про то что есть тип данных, который декларирует возможность хранения чисел с определенной точностью, а на самом деле там бардак

И с какой же точностью числа по вашему должны быть в типе float?
Никто не почитывает, кстати, стандарт SQL? Какая там указана точность для типа FLOAT, если вообще указана?

[Stilet]

Да ладно, ребята, бросьте ссорится. Это не проблема, а мелочь, которую всегда можно округлить Она не стоит холливара.

[soleil@mmc]

2 pu4koff
смишно чесна слово

база данных должна работать независимо от того чем к ней коннектишься
отсюда вывод - введеное число с точностью до 2 знаков, например, я должен получить в запросе select * from table where id = :new.id независимо от того из-под какого гуи этот запрос сделан, а отсюда и следует, что в БД число должно храниться в том же виде что и введено

например, в ИБ/ФБ (речь про их жизнь еще без диалектов, чтобы удобно было сравнивать с тем же в парадоксах и иже с ними) тип numeric(15, 2) хоть и декларирует 2 знака после запятой, но на самом деле в базе все это хранится в виде double precision со всеми вытекающими бубнами с округлением

я могу понять, что нужно округлять числа после арифметических операций с ними - умножили/разделили - тогда добавятся лишние значащие, но зачем мне каждый раз беспокоиться об этом при просто хранении чисел?!

[Костя Мельников]

Edit1.text:=format('%.2f',[Таблица.FieldByName('Поле').AsFloat]);

Спасибо, помогло.

данную проблему я обходил с помощью замены Float на Numeric(7,2) а работал с ним как с Float

Обязательно попробую, Спасибо.

Еще вопрос, почему в DBGrid-е « 0,45 » отображается как « ,45 », а куда ноль делся, в базе он есть?

Спасибо, Всем кто откликнулся, жаль, что большую часть обсуждения я не понимаю, ну, что поделать, будем учиться.