![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Точность отображения на экране [D6, IB6.x]
ruslan_as © (2003-02-03 10:09:00)Работаю с InterBase. Тип поля Float. В набор данных ввожу 0,001
а отображает 0,001000002464 (15 знаков). А мне нужно отображать 0,001. (а если 0,01 то отображать 0,01, вообщем как есть).
Вопрос простой, а в книге не нашел решения.
Съэкономте время пожалуйта!
Sergey Masloff (2003-02-03 14:52:00) [1]Alexandr ©
>ну я же не сказал " не будет работать" Я сказал, что нужно учесть некоторые тонкости.
Я тоже проблемы не вижу :)
Ну тогда понятно ;-) У меня была единственная проблема в IBX в компоненте IBSQL при задании параметров AsFloat это не как обычно Double а Single. В то время как в IBQuery все "как обычно" - AsFloat это Double. И так как в документации про это я прочел после 3 дней плясок с бубном - так работает а так нет... то запомнилось надолго ;-)
Alexandr (2003-02-03 14:37:00) [2]ну я же не сказал " не будет работать" Я сказал, что нужно учесть некоторые тонкости.
Я тоже проблемы не вижу :)
Но вот челу не нравится
> Работаю с InterBase. Тип поля Float. В набор данных ввожу
> 0,001
> а отображает 0,001000002464 (15 знаков).
я и пытался объяснить, почему так.
Sergey Masloff (2003-02-03 14:07:00) [3]Alexandr ©
>1) проблема с округлением есть на самом деле. И она совершенно >естественна и связана с нем, что в компьютере как ни крути, а >точно ограничена. И ограничена не по десятичным цифрам, а по >двоичным.
Это прописные истины. Но проблемы по-прежнему не вижу.
>2) Сделать первичные ключи с плавающей точкой это оригинально...
Вы пропустили мое примечание "в силу объективных причин". И работать это будет (и работает) без проблем. Поверьте, я очень внимательно потестировал поведение IB прежде чем применить это решение в тиражируемой системе.
Alexandr (2003-02-03 13:47:00) [4]
> Просто у меня есть рабочий проект в котором (в силу объективных
> причин) все первичные ключи - с пл.точкой. Соответственно,
> при наличии проблем с хранением чисел я бы испытывал грандиозные
> проблемы с джойнами, форин кеями и пр. Так как проблем не
> наблюдается, то...
1) проблема с округлением есть на самом деле. И она совершенно естественна и связана с нем, что в компьютере как ни крути, а точно ограничена. И ограничена не по десятичным цифрам, а по двоичным.
2) Сделать первичные ключи с плавающей точкой это оригинально...
Но при определенных обстоятельствах действительно будет работать.
Sergey Masloff (2003-02-03 13:39:00) [5]Sergey13 ©
Сергей, а что за проблема с точностью хранения? А запарки в сравнении 755.68 и 755.68 были не при использовании компонентов IBX (в частности IBSQL?)
Просто у меня есть рабочий проект в котором (в силу объективных причин) все первичные ключи - с пл.точкой. Соответственно, при наличии проблем с хранением чисел я бы испытывал грандиозные проблемы с джойнами, форин кеями и пр. Так как проблем не наблюдается, то...
Johnmen (2003-02-03 11:59:00) [6]>ruslan_as ©
Если надо работать с полями с пл.точкой и при этом отображать фиксированное кол-во знаков после дес.разделителя, то см. псевдо тип NUMERIC
Sergey13 (2003-02-03 10:31:00) [7]2Романов Р.В. © (03.02.03 10:12)& passm © (03.02.03 10:13)
Это в данном случае не решение проблемы, а временный уход от нее.
2ruslan_as © (03.02.03 10:09)
Советую бороться не с отображением на экран, а с точностью хранения чисел в ИБ - там есть здоровая проблема с этим. Сам в субботу запарился сравнивая 755.68 и 755.68. Пока явно не округлил говорило что не равно.
Поможет тебе в этой борьбе UDF на сервере и/или своя функция в программе типа round(x,n), где N-количество знаков для округления.
passm (2003-02-03 10:13:00) [8]ruslan_as © (03.02.03 10:09)> TNumericField.DisplayFormat & TNumericField.EditFormat.
Романов Р.В. (2003-02-03 10:12:00) [9]TNumericField.DisplayFormat