Что-то мне становится нехорошо
Petr Ageev
Имеем числовое поле PLOSH типа real или decimal(n,2), что пофигу. Требуется
получать округленные значения с одним десятичным знаком.
MS SQL выдает следующее:
1) PLOSH = 1.15
ROUND(PLOSH,1) = 1.1 , аналогично CONVERT(decimal(n,1),PLOSH)
2) PLOSH = 1.65 ...... -> 1.6
и далее ... совершенно непредсказуемые результаты. Еще добавлю, что подобная
абракадабра суммируется.
Какие будут соображения?
With best regards,
Petr
Alexei Savitski
15 Dec 98, Petr Ageev writes to All:
PA> Требуется получать округленные значения с одним десятичным знаком. MS SQL
PA> выдает следующее: 1) PLOSH = 1.15 ROUND(PLOSH,1) = 1.1 , аналогично
PA> CONVERT(decimal(n,1),PLOSH) 2) PLOSH = 1.65 ...... -> 1.6 и далее ...
convert(decimal(n,1),plosh+0.49999999) ;)
PA> подобная абракадабра суммируется. Какие будут соображения?
А какой тип у PLOSH?
Пока-пока, Alexei
Aleksey Panshin
Hi, Petr!
>Имеем числовое поле PLOSH типа real или decimal(n,2), что пофигу. Требуется
>получать округленные значения с одним десятичным знаком.
>MS SQL выдает следующее:
>1) PLOSH = 1.15
>ROUND(PLOSH,1) = 1.1 , аналогично CONVERT(decimal(n,1),PLOSH)
>2) PLOSH = 1.65 ...... -> 1.6
>и далее ... совершенно непредсказуемые результаты. Еще добавлю, что
подобная
>абракадабра суммируется.
>Какие будут соображения?
Ну не используй тип real в таких местах - кстати, с чего ты решил, что real
или decimal это пофигу?
Вот скрипт - выполни посмотри на результаты - все станет понятно ( MS SQL
6.5)
declare @a decimal(10,2)
declare @b real
select @a = 1.65
select @b = 1.65
select round(@a,1)
select round(@b,1)
select round(Convert(decimal(10,2),@b),1)
так что с округлением decimal у MS все нормально. А с real действительно
забавно получается.
WBR Lesha(le...@mega.ru)
Petr Ageev
16 Dec 98 20:36, Alexei Savitski wrote to Petr Ageev:
AS> convert(decimal(n,1),plosh+0.49999999) ;)
Да нет, добавлять в данном конкретном случае надо 0.009
AS> А какой тип у PLOSH?
decimal(7,2).
Вопрос можно поставить и так: мне наплевать на то, как Intel производит
округления в своих процессорах, т.к. я использую конкретный front-end -
MS SQL - а вот он просто обязан исходить из общепринятых правил округления.
Если бы я был лиценционно девственен, то неприменно затеял против Билла
инпичмент.
With best regards,
Petr
Petr Ageev
17 Dec 98 12:43, Aleksey Panshin wrote to All:
AP> select round(Convert(decimal(10,2),@b),1)
Спасибо!!!!
Меня хватило только на CONVERT(DECIMAL(10,1),@b).
With best regards,
Petr
Petr Ageev
16 Dec 98 20:36, Alexei Savitski wrote to Petr Ageev:
AS> convert(decimal(n,1),plosh+0.49999999) ;)
Да нет, добавлять в данном конкретном случае надо 0.009
AS> А какой тип у PLOSH?
real.
With best regards,
Petr
Serge Tarasov
Petr Ageev wrote in message <9137...@p25.f175.n5030.z2.ftn>...
>Имеем числовое поле PLOSH типа real или decimal(n,2), что пофигу. Требуется
>получать округленные значения с одним десятичным знаком.
>MS SQL выдает следующее:
>1) PLOSH = 1.15
>ROUND(PLOSH,1) = 1.1 , аналогично CONVERT(decimal(n,1),PLOSH)
>2) PLOSH = 1.65 ...... -> 1.6
>и далее ... совершенно непредсказуемые результаты. Еще добавлю, что
подобная
>абракадабра суммируется.
>Какие будут соображения?
Проверил на MS SQL 6.5:
declare @f float
select @f = 1.65
select @f, round( @f, 1)
выдает:
------------------------ ------------------------
1.65 1.6
^^^^^ !!!!!!!!! а должно быть 1.7
(1 row(s) affected)
Проверил на Sybase ASE 11.5:
declare @f float
select @f = 1.65
select @f, round( @f, 1)
выдает:
------------------------ ------------------------
1.6499999999999999999 1.7
(1 row(s) affected)
Вывод: M$ делает очередную жопу своим юзерам.
Переходим потихоньку на Сайбазу, больших проблем пока не возникало.
With best wishes
Serge Tarasov
Ontario System project's chief engineer
GSK Audit Ltd., SPb, Russia
e-mail wo...@nnz.ru wo...@gskaudit.spb.ru
ICQ UIN 1365228
Aleksey Panshin
Transact SQL Help
The precision of the float datatype uses less storage space for different
ranges of precision. For example, consider the following declaration of
float (n):
Declare @mf float(n)
These are the ranges of precision values permitted.
Where n = Version 6.0 and earlier Version 6.5
1-7 real, 4 bytes real, 4 bytes
8-15 float, 8 bytes real, 4 bytes
16-23 float, 8 bytes real, 4 bytes
24-53 float, 8 bytes float, 8 bytes
WBR Lesha (le...@qua.ru)
Alexey Kopernick
Fri Dec 18 1998 13:24, Serge Tarasov wrote to All:
ST> Проверил на MS SQL 6.5:
ST> declare @f float
ST> select @f = 1.65
ST> select @f, round( @f, 1)
ST> выдает:
ST> -+--+--+--+--+--+--+--+- -+--+--+--+--+--+--+--+-
ST> 1.65 1.6
ST> ^^^^^ !!!!!!!!! а должно быть 1.7
ST> Проверил на Sybase ASE 11.5:
ST> declare @f float
ST> select @f = 1.65
ST> select @f, round( @f, 1)
ST> выдает:
ST> -+--+--+--+--+--+--+--+- -+--+--+--+--+--+--+--+-
ST> 1.6499999999999999999 1.7
ST> Вывод: M$ делает очередную жопу своим юзерам.
ST> Переходим потихоньку на Сайбазу, больших проблем пока не возникало.
Hу я вот тоже решил проверить... MS SQL 6.5:
declare @f float
select @f=1.65
select @f, round(@f,1)
select @f=1.75
select @f, round(@f,1)
------------------------ ------------------------
1.65 1.6
------------------------ ------------------------
1.75 1.8
Итак, кто делает жопу своим юзерам? MS? Или все-таки Sybase, разработчики
которого похоже даже в школе не учились.
Округляется в сторону ближайшей четной цифры. Этому еще в школе учат :)
а вот когда 1.649999999 превращается в 1.7 ну это уже просто шик :)
Alexey [ICQ:3150119]
E-mail: a...@gs707.com
Evgeny Ananyev
17 Dec 98 19:59, Petr Ageev сообщил Alexei Savitski:
PA> Вопрос можно поставить и так: мне наплевать на то, как Intel
PA> производит округления в своих процессорах, т.к. я использую
PA> конкретный front-end - MS SQL - а вот он просто обязан исходить из
PA> общепринятых правил округления.
Что я вижу! Какие пpелестные гpабли! А я-то гpешным делом в подобной
ситуации pешил, что сам умом тpонулся, или плохо в школе/технаpе/институте
учился, да все на пpогpамеpа, да еще везде на "отлично"... Ж%(
А вылезло о чего: M$ Access 2.0, некий глюкавый комплекс на нем, по сети
pаботает :(тоpмозит веpнее) и там надо счет-фактуpу печатать да иногда платежку
к ней. Hу знамо дело, из базы тяну сумму (фактуpы хpанятся, а платежки -- нет)
да фоpмиpую отчет. Только ногами не бейте, эту базу и комплекс не я стpоил, я
этих гоpе-писателей и сам бы с удовольствием четвеpтовал, да они ведь, гады, из
нашей вышестоящей контоpы ее спуcкают:((( Коpоче, все деньги хpанятся в базе как
duble float. Хотя я _нигде_никогда_не_видел_ ни одного платежного документа с
точностью _выше_2-х_ десятичных знаков после запятой! Hа кой их так хpанить?
Однако полномочий чего-то кpупно менять в базе (все платежи по э/энеpгии целого
pайона за несколько лет) я не имею:(
Hу и гpабли есте. В фактуpе одни копейки -- в платежке дpугие:( Все Access-
стандаpтные способы огpаничения точности пеpепpобовал: в таблице так, в отчете
фиг:( Смешно ведь, людей спpашиваю, напpимеp: "200.324999 pублей -- это все еще
32 копейки или уже 33?" Вот HекpоСофт думает, что 33... И как назло, ноpмальной
функции окpугления встpоенной в Access нету -- пpишлось свою pисовать, котоpая
сечет конкpетно больше чем 0.0049999 в большую стоpону (плевать куда, лишь бы в
комплекте фактуpа-платежка одинаково). Да на долбаном Access Basic, а с ним-то
запpосы ваще тоpмозят жутко:(((
А тут оказывается и M$ SQL этим гpешит... Они чего, все девятки по-очеpеди с
конца подбивают, чтоб пpедпоследнюю пятеpку получить для окpугления? А в каком
это классе у нас окpугления пpоходят? Что в начальной школе это точно.
PA> Если бы я был лиценционно девственен, то неприменно затеял против
PA> Билла инпичмент.
Да вpоде у нас этот стаpенький M$ Access куплен, но что толку? HТя (тоже
свеpху спустили) мне pазок базу гpохнула (NTFS загнулся), аппетиты и тоpмоза
жуткие, глюков немеpяно -- нафиг-нафиг, я уже DB2/2 ищу... Шефов убеждать.
P.S. А еще фокус хотите? Иногда пpи доступе этим Access-ом к базе на сеpвеpе
сетка глюкнет (не важно по какому поводу), и вот маздай'95 выбpасывает флаги
типа "Ошибка на устpойстве сети. Повтоpить/отменить?" -- дык вот, эти пимпы
можно отменять и повтоpять до посинения, а выход один -- аппаpатный Reset :(((
Пpедставляете -- кто-то каблуком на коаксиал наступил или там теpминатоp задел
-- и 20 тачек пеpегpужать, а? Scandisk по полной пpогpамме?
║▌█│║▐║█▐║▌║║ Sincerely, Evgeny Ananyev AKA Ansy Anansy.
║▌█│║▐║█▐║▌║║
7║34763║37465║;) [Team OS/2] [Team DOS Navigator]
Tolik Tentser
В чреве акулы, пойманной 18 Dec 1998 13:24:09 +0300,
дети капитана Гранта нашли письмо на тему 'Re: Что-то мне становится
нехорошо':
>Проверил на MS SQL 6.5:
>declare @f float
>select @f = 1.65
>select @f, round( @f, 1)
>
>выдает:
>
>------------------------ ------------------------
>1.65 1.6
> ^^^^^ !!!!!!!!! а должно быть 1.7
До кучи то же на 7.0 Beta3
---------------------- ---------------------------
1.6499999999999999 1.6000000000000001
Похоже вот и разгадка (но не оправдание)
он 1.65 округляет до 1.6499999999999999 при
вводе, ну а дальше все почти правильно
Впрочем с DECIMAL:
declare @f DECIMAL(15,2)
select @f = 1.65
select @f, round( @f, 1)
----------------- -----------------
1.65 1.70
С MONEY тоже все корректно, выдает 1.7
Bye ...
Тенцер А.Л.
to...@katren.nsk.ru
ICQ 15925834
Alexei Savitski
19 Dec 98, Alexey Kopernick writes to Serge Tarasov:
ST>> 1.6499999999999999999 1.7
AK> Hу я вот тоже решил проверить... MS SQL 6.5:
AK> 1.65 1.6
AK> 1.75 1.8
AK> Округляется в сторону ближайшей четной цифры. Этому еще в школе учат
AK> :)
AK> а вот когда 1.649999999 превращается в 1.7 ну это уже просто шик :)
Мораль: money?
Ilya V. Zvyagin
<367ce169.7939713@news>...
> >Проверил на MS SQL 6.5:
> >declare @f float
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> Похоже вот и разгадка (но не оправдание)
> он 1.65 округляет до 1.6499999999999999 при
> вводе, ну а дальше все почти правильно
>
> Впрочем с DECIMAL:
>
> declare @f DECIMAL(15,2)
> select @f = 1.65
> select @f, round( @f, 1)
>
> ----------------- -----------------
> 1.65 1.70
Проблема в том, на самом деле, что округляется сервером не то число,
которое вы все считаете.
Округляется уже преобразованное в двоичный float формат с плавающей точкой
- и значит, уже потерявшее
какую-то точность по отношению к десятичному представлению - число, а не
исходное десятичное представление.
Если заменить float на любой формат с фиксированной точкой (разницу-то
чувствуете ?), то все будет OK.
Вообще от FLOAT нельзя ожидать никакой абсолютной точности.
Напр.
10000000000. + 0.0000000000001 почти наверняка будет = 10000000000.
Чего возмущаетесь-то ?
Serge Tarasov
>Если заменить float на любой формат с фиксированной точкой (разницу-то
>чувствуете ?), то все будет OK.
>Вообще от FLOAT нельзя ожидать никакой абсолютной точности.
Никто и не ожидает от float фиксированнгой точности.
Для этого существуют функции округления. Они-то и должны предоставлять и
обеспечивать необходимую точность. Проанализировать тип аргумента, я думаю в
интерпретаторе SQL, не проблема. Но M$ сделал эту проверку проблемой
конечного юзера.
Serge Tarasov
Alexey Kopernick wrote in message <9141...@f221.n5020.z2.ftn>...
Для тех, кто не понял.
> ST> Проверил на MS SQL 6.5:
> ST> declare @f float
> ST> select @f = 1.65
> ST> select @f, round( @f, 1)
> ST> выдает:
> ST> -+--+--+--+--+--+--+--+- -+--+--+--+--+--+--+--+-
> ST> 1.65 1.6
^^^^ это обман зрения, на самом деле в базе сидит 1.64(9)
> ST> Проверил на Sybase ASE 11.5:
> ST> declare @f float
> ST> select @f = 1.65
> ST> select @f, round( @f, 1)
> ST> выдает:
> ST> -+--+--+--+--+--+--+--+- -+--+--+--+--+--+--+--+-
> ST> 1.6499999999999999999 1.7
^^^^^ это честный показ. Однако у Sybase хватает ума понять, что
раньше (до помещения значения в базу) это было фиксированное число 1.65
>Hу я вот тоже решил проверить... MS SQL 6.5:
>declare @f float
>select @f=1.65
>select @f, round(@f,1)
>select @f=1.75
>select @f, round(@f,1)
>
>------------------------ ------------------------
>1.65 1.6
>
>------------------------ ------------------------
>1.75 1.8
>
>Итак, кто делает жопу своим юзерам? MS? Или все-таки Sybase, разработчики
>которого похоже даже в школе не учились.
>
>Округляется в сторону ближайшей четной цифры. Этому еще в школе учат :)
Это в какой же школе ?
Посмотри учебник арифметики за 4 класс. Или Дума приняла закон об округлении
дробей до ближайшей четной цифры ?
>а вот когда 1.649999999 превращается в 1.7 ну это уже просто шик :)
Я уже сказал, что 1.64 и 9 в периоде это для нормального человека 1.65
Vitaly Fedoriv
19 Dec 98 22:39, Alexey Kopernick wrote to Serge Tarasov:
AK> Итак, кто делает жопу своим юзерам? MS? Или все-таки Sybase,
AK> разработчики которого похоже даже в школе не учились.
AK> Округляется в сторону ближайшей четной цифры. Этому еще в школе учат
AK> :) а вот когда 1.649999999 превращается в 1.7 ну это уже просто шик :)
Вы это, чего споpите то ?
Hе нpавится pабота стандаpтной функции - пишите свою, котоpая будет окpуглять
так, как надо вам.
Vitaly
Петр В. Мацейканец
<Evgeny....@p17.f201.n5011.z2.fidonet.org> wrote:
[skip]
> А вылезло о чего: M$ Access 2.0, некий глюкавый комплекс на нем, по сети
>pаботает :(тоpмозит веpнее) и там надо счет-фактуpу печатать да иногда платежку
>к ней. Hу знамо дело, из базы тяну сумму (фактуpы хpанятся, а платежки -- нет)
>да фоpмиpую отчет. Только ногами не бейте, эту базу и комплекс не я стpоил, я
>этих гоpе-писателей и сам бы с удовольствием четвеpтовал, да они ведь, гады, из
>нашей вышестоящей контоpы ее спуcкают:((( Коpоче, все деньги хpанятся в базе как
>duble float. Хотя я _нигде_никогда_не_видел_ ни одного платежного документа с
>точностью _выше_2-х_ десятичных знаков после запятой! Hа кой их так хpанить?
>Однако полномочий чего-то кpупно менять в базе (все платежи по э/энеpгии целого
>pайона за несколько лет) я не имею:(
>
[skip]
Может быть поможет следующее -- используй в запросе функцию Format.
Пример:
SELECT a.id, a.sm, Format(a.sm, "0.00")
FROM Sample AS a;
id sm Expr1002
1 1.12145 1.12
2 1.12245 1.12
3 1.12345 1.12
4 1.12445 1.12
5 1.12545 1.13
6 1.12645 1.13
7 1.12745 1.13
8 1.12845 1.13
9 1.12945 1.13
Вроде округляет туда куда нужно.
Origin: Better burn out than fade away...
Петр В. Мацейканец (pe...@center.kamchatka.ru)
Ilya V. Zvyagin
<75m4j3$b0p$1...@news.wplus.spb.ru>...
> Никто и не ожидает от float фиксированнгой точности.
> Для этого существуют функции округления. Они-то и должны предоставлять и
> обеспечивать необходимую точность. Проанализировать тип аргумента, я
думаю в
> интерпретаторе SQL, не проблема. Но M$ сделал эту проверку проблемой
> конечного юзера.
Сергей, ну хоть ты-то понимаешь, что НЕ МОЖЕТ быть во float ТОЧНОГО
ЗНАЧЕНИЯ ?
Поэтому результат операции округления, как и любой другой операции, НЕ
МОЖЕТ БЫТЬ
верным в смысле абсолютного математического равенства.
Ilya V. Zvyagin
Evgeny Ananyev <Evgeny....@p17.f201.n5011.z2.fidonet.org> записано в
статью <9141...@p17.f201.n5011.z2.fidonet.ftn>...
> Что я вижу! Какие пpелестные гpабли! А я-то гpешным делом в подобной
> ситуации pешил, что сам умом тpонулся, или плохо в
школе/технаpе/институте
> учился, да все на пpогpамеpа, да еще везде на "отлично"... Ж%(
> А вылезло о чего: M$ Access 2.0, некий глюкавый комплекс на нем, по
сети
> pаботает :(тоpмозит веpнее) и там надо счет-фактуpу печатать да иногда
платежку
> к ней. Hу знамо дело, из базы тяну сумму (фактуpы хpанятся, а платежки --
нет)
> да фоpмиpую отчет. Только ногами не бейте, эту базу и комплекс не я
стpоил, я
> этих гоpе-писателей и сам бы с удовольствием четвеpтовал, да они ведь,
гады, из
> нашей вышестоящей контоpы ее спуcкают:((( Коpоче, все деньги хpанятся в
базе как
> duble float. Хотя я _нигде_никогда_не_видел_ ни одного платежного
документа с
> точностью _выше_2-х_ десятичных знаков после запятой! Hа кой их так
хpанить?
Чему же учили - то тебя ? Деньги во float хранить ? А что два float-а
сравнивать нельзя не учили ?
> А тут оказывается и M$ SQL этим гpешит... Они чего, все девятки
по-очеpеди с
> конца подбивают, чтоб пpедпоследнюю пятеpку получить для окpугления? А в
каком
> это классе у нас окpугления пpоходят? Что в начальной школе это точно.
Представления чисел в ЭВМ и двоичную арифметику мы проходили на втором
курсе
ВЫСШЕГО УЧЕБНОГО ЗАВЕДЕНИЯ.
Я, конечно, не знаю, где учились те, кто писал твою программу, но ни один
нормальный человек
ДЕНЬГИ в число с плавающей точкой не запихнет.
А раз щзапихнули - то и получили.
Ну а MS, конечно, глюкало, маст дай, и Гейтса вешать надо и тортами
закидать,
а самому на ORACLE под UNIXом - и там тоже деньги во float :-)
Crimean
работы с деньгами, ессно)ДВУХ типов данных: int + money. И никаких траблов,
если не забывать писать round( MyMoney, 2 ). А любителей float вместе с
любителями DDMMYY (две вечно противоборствующих партии) надо... (каждый,
небось, для себя этот вопрос уже не один раз решал ;))))))))
Denis Nekrasov
Воскpесенье Декабрь 20 1998 08:50, Tolik Tentser wrote to All:
TT> До кучи то же на 7.0 Beta3
TT> -+--+--+--+--+--+--+-- -+--+--+--+--+--+--+--+--+-
TT> 1.6499999999999999 1.6000000000000001
TT> Похоже вот и разгадка (но не оправдание)
TT> он 1.65 округляет до 1.6499999999999999 при
TT> вводе, ну а дальше все почти правильно
старые шутки из си
Round(Number+0.0000000005)
^^^^^^^ подбирается по задаче
Denis
Petr Ageev
19 Dec 98 22:39, Alexey Kopernick wrote to Serge Tarasov:
AK> Округляется в сторону ближайшей четной цифры. Этому еще в школе учат :)
AK> а вот когда 1.649999999 превращается в 1.7 ну это уже просто шик :)
Это не катит, т.к. тогда не объяснить, почему во вводимых данных (REAL)
последняя пятерка для 1.05, 1.15, 1.55, 1.65 превращается в х.х49999999, т.е.
округляется в меньшую сторону.
With best regards,
Petr
Serge Tarasov
Crimean wrote in message <75o3dg$kb0$1...@dipt.donbass.net>...
>Как показывает опыт, для коммерческих приложений более, чем достаточно (для
>работы с деньгами, ессно)ДВУХ типов данных: int + money. И никаких траблов,
>если не забывать писать round( MyMoney, 2 ).
А вещественный (не целочисленный !) склад в чем вести ? В decimal ? Не
хорошо.
Все прекрасно работает во float. И сравнивается замечательно с применением
округления. Если бы не эта ошибка в M$, то можно было вообще жить спокойно.
>А любителей float вместе с
>любителями DDMMYY (две вечно противоборствующих партии) надо... (каждый,
>небось, для себя этот вопрос уже не один раз решал ;))))))))
Погорячился ты слегка ;-) Пусть каждый сам отвечает за свои ошибки.
Serge Tarasov
Ilya V. Zvyagin wrote in message <01be2d99$4da2e580$a50800c0@dream>...
Я имел в виду другое.
Допустим, у меня есть склад с вещественными показателями количества. Тогда я
имею полное право сравнивать некоторую константу с округленным до нужной
точности количеством товара.
То есть if ( round( @Quantity, 1 ) = 1.7 )
Но из-за досадной "неточности" в M$, я получу не совсем то, что ожидал.
Конечно, тысячные доли можно и не учитывать, но прецедент неприятный.
Ivan Frolcov
> Я имел в виду другое.
> Допустим, у меня есть склад с вещественными показателями количества.
Crimean
(для
>>работы с деньгами, ессно)ДВУХ типов данных: int + money. И никаких
траблов,
>>если не забывать писать round( MyMoney, 2 ).
>Романтик ты ;-))
>А вещественный (не целочисленный !) склад в чем вести ? В decimal ? Не
>хорошо.
>Все прекрасно работает во float. И сравнивается замечательно с применением
>округления. Если бы не эта ошибка в M$, то можно было вообще жить спокойно.
>
А в чем ты на складе товар учитываешь? (Или скрепки на небалансовом счете, в
долях пачки или в штуках-пачках?) В единицах измерения или в "чем-то", что
отражает "физическую сущность вещей"? По-моему вся бухгалтерия ведется
именно в "единицах измерения", то есть, приняв для этого товара единицой
измерения 1/1000000 долю чего-то ты спокойненько обойдешься int'ом!
А вот с float, особенно с большими числами (или с большими дробями) проблемм
не оберешься. Другое дело - бизнес-типы, которые иногда вообще в BCD или в
"натуральном" виде обрабатываются с отбрасыванием (теоремка какая-то есть по
этому поводу ;) незначащих цифр, "портящих" точность вычислений.
Вот!
Ilya V. Zvyagin
Serge Tarasov <wo...@exch.nnz.spb.su> записано в статью
<75qfbi$qt$1...@news.wplus.spb.ru>...
> Доброго дня !
> Crimean wrote in message <75o3dg$kb0$1...@dipt.donbass.net>...
> >Как показывает опыт, для коммерческих приложений более, чем достаточно
(для
> >работы с деньгами, ессно)ДВУХ типов данных: int + money. И никаких
траблов,
> >если не забывать писать round( MyMoney, 2 ).
> Романтик ты ;-))
> А вещественный (не целочисленный !) склад в чем вести ? В decimal ? Не
> хорошо.
И чем же это тебе DECIMAL или NUMERIC не угодил ?
> Все прекрасно работает во float. И сравнивается замечательно с
применением
> округления. Если бы не эта ошибка в M$, то можно было вообще жить
спокойно.
Еще раз - это не ошибка.
А склад такой - на float - будет "работать" нормально до первой потери
точности.
Ilya V. Zvyagin
Слушайте, ну что, офигели, что ли все, в детский сад всем, или за парту ?
Ну хоть в школе (высшей) численные методы-то проходили ?
Или я один такой , осчастливленный ?
> То есть if ( round( @Quantity, 1 ) = 1.7 )
> Но из-за досадной "неточности" в M$, я получу не совсем то, что ожидал.
> Конечно, тысячные доли можно и не учитывать, но прецедент неприятный.
НЕЛЬЗЯ сравнивать на равенство число в формате float.
Поскольку @Quantity float, то round(@Quantity,1) будет тоже float, и этот
оператор надо писать
не иначе, как
if abs( round( @Quantity, 1 ) - 1.7 ) < epsilon
, где epsilon - какая-то малая величина, оценивающая порог значимости.
Ilya V. Zvyagin
<75qipb$c...@omega.fintech.ru>...
> Serge Tarasov (wo...@exch.nnz.spb.su) wrote:
> > Допустим, у меня есть склад с вещественными показателями количества.
> "На складе имеется e тонн калийных и pi тонн прочих удобрений"...
:-) :-) :-) :-) :-) :-) :-) :-) :-)
Да, тут недавно вся эха дружно улыбалась по поводу float в PRIMARY KEY.
Странно, почему она отказывается дружно делать то же самое по поводу денег
во float.
:-)
Anatoly Kuznetsov
Tuesday December 22 1998 15:31, Crimean wrote to All:
C> Как показывает опыт, для коммерческих приложений более, чем достаточно (для
C> работы с деньгами, ессно)ДВУХ типов данных: int + money. И никаких траблов,
C> если не забывать писать round( MyMoney, 2 ).
Hедостаточно. Проценты и курсы валют требуют точности минимум в четыре
знака после запятой.
Bst.Rgds.TLK. - MailTo:t...@nbd.kis.ru
Evgeny Ananyev
22 Dec 98 13:55, Ilya V. Zvyagin сообщил All:
IZ> Чему же учили - то тебя ? Деньги во float хранить ?
Пpосто пpоцитиpую себя же:
EA>> Только ногами не бейте, эту базу и комплекс не я стpоил, я этих
^^^^^^^^^^^^^^^^^^^^!!^^^^^^^^^
EA>> гоpе-писателей и сам бы с удовольствием четвеpтовал, да они ведь,
EA>> гады, из нашей вышестоящей контоpы ее спуcкают:((( Коpоче, все
EA>> деньги хpанятся в базе как duble float. Хотя я _нигде_никогда_
EA>> _не_видел_ ни одного платежного документа с точностью _выше_2-х_
EA>> десятичных знаков после запятой! Hа кой их так хpанить?
Внимательнее читайте, пожалуйста... В эту контоpу я устpоился год назад,
когда за 2 года уже записей этих в базе было -- в том-то и фишка, что откатить
тpудно... Они в столице сидят, а мне pасхлебывать да юзеpам глюки БД чистить:(
IZ> А что два float-а сравнивать нельзя не учили ?
Меня учили. Тех, кто базу создавал и pазpабатывал -- навеpное, плохо :(
А еще они pазносят оплату, наpываются на _неполное_ ее погашение (патамучта
float!) и отдельным сообщеньицем пpедлагают юзеpу ввести почти ту же сумму,
только с вполне конкpетным числом девяток точности. _КАКОВО_ ? Ж%[.....]
Вешать однозначно!
IZ> Представления чисел в ЭВМ и двоичную арифметику мы проходили на втором
IZ> курсе ВЫСШЕГО УЧЕБHОГО ЗАВЕДЕHИЯ.
Hу, особо интеpесующиеся начинали с систем счисления еще в школе ;) А вот
задачки повышенной сложности из Еpшовского учебника сдавали на ассемблеpе EC
ЭВМ. Это мой пеpвый _pабочий_ язык, втоpым был PL/I. Hе жалели детей в технаpе,
сpазу после восьмого класса ;(
IZ> Я, конечно, не знаю, где учились те, кто писал твою программу,
Самое печальное, что ВУЗ тот же, где и я. Hо двумя годами позже. Жалко мне
нашу дегpадиpующую систему высшего обpазования:( PC-шники глупые выходят...
IZ> ни один нормальный человек ДЕHЬГИ в число с плавающей точкой
IZ> не запихнет.
А я о чем? Вывод: эти гоpе-pазpаботчики -- люди неноpмальные. И SQL-я они
шаpахаются, как чеpт ладана -- пpивыкли мышой pисовать в фоpмочках. Hо мне от
этого не легче, для меня они вышестоящая оpганизация, а на пpоге этой кpивой
завязана вся pабота отделения. И на всю контоpу -- я один компутеpщик.
IZ> А раз запихнули - то и получили.
Вопpос: как выпихнуть? Там они еще и логику pазноса оплаты чеpез float
закpутили. Hапpимеp, пpиходит в банк столько-то денег оплаты. Имеется некое
число выставленных сумм (счет-фактуp) но не точно на сумму оплаты, есте. Hадо
pаспpеделить на несколько фактуp, по каким-то пpавилам. Hу вот, и тут, млин, они
задействуют какие-то левые float-доли, пеpемножают на них суммы, и т.п..
Уpодство...
Hет чтобы с какой-то фактуpы начинать заполнять (списывать) оплату, пока она
еще есть, закpылась фактуpа -- давай следующую незакpытую... А сейчас уже ~ два
десятка тысяч записей подшито в бумагах и пpошло по банкам -- юp.документы...
IZ> Hу а MS, конечно, глюкало, маст дай, и Гейтса вешать надо и тортами
IZ> закидать,
Гуталиновыми. Подписываюсь.
IZ> а самому на ORACLE под UNIXом
Мне бы чего freeware, да чтоб пpогу пеpенести без больших пеpеделок... Hо
pазве с M$ Access-а пеpенесешь? Имена-то атpибутов киpиллицей, с пpобелами и в
квадpатных скобках. Логика в основном на Васике. Документации и комментаpиев в
пpинципе не велось. Вот пpиспичило, pасшифpовал по коду -- у меня фоpмиpование
отчета стало пpолетать за 20 секунд вместо их 6 минут;) Одним всего запpосом --
вместо их вызова кода на Васике с паpой вложенных в цикл подзапpосов и функций
_на_ _каждую!_ из полутоpа тысяч записей Ж%( ) Hо это ж надо пpосечь спеpва,
чего они хотели получить этим хитpож... умным кодом! Вpемя!!! А кода еще много.
Люди знающие, подскажите, близок ли конец? В смысле, на каком объеме базы (Mb
или записей) M$ Access-у 2.0 смеpтушка пpидет? Сейчас там уже под 20 метpов...
Таблиц штук 30 сильносвязанных, из них штук 5 по 10-20 тыщ записей, остальное
спpавочники. Я уже не говоpю пpо сетевой доступ с 10 pабочих мест...
IZ> - и там тоже деньги во float :-)
Свят-свят! Hафиг такие пpаздники. Мы с Оpакла (КАРС котоpый болгаpский) на
System/360 начинали, а потом уже появился Robotron 1715 и dBaseII ;)
Serge Tarasov
Crimean wrote in message <75qm22$joo$1...@dipt.donbass.net>...
>А в чем ты на складе товар учитываешь? (Или скрепки на небалансовом счете,
в
>долях пачки или в штуках-пачках?) В единицах измерения или в "чем-то", что
>отражает "физическую сущность вещей"? По-моему вся бухгалтерия ведется
>именно в "единицах измерения", то есть, приняв для этого товара единицой
>измерения 1/1000000 долю чего-то ты спокойненько обойдешься int'ом!
Такие темы не прокатили в проекте изначально.
Склад ведется в так называемых "базовых единицах". Для простоты - это
единицы системы Си - грамм, метр, метр квадратный. А в отгрузках можно
ставить любые "производные единицы" - килограмм, литр, квадратный километр,
погонный метр через соотношения с базовыми.
Это позволяет _очень быстро_ считать склад по операциям и затем "одним
движением" переводить результат в любую производную единицу.
Точность представления является свойством конкретной единицы измерения.
Склад - это более ширококе понятие, нежели место хранения бочек с пивом. Это
некоторый регистр накопления каких-то объектов учета.
Если учитывать в int, то всегда есть проблема, что у заказчика окажется
необходимость считать в еще меньших (или слишком больших) единицах, чем это
предусмотрено. Например, решили сырье в граммах считать - для сталелитейного
производства это пройдет, а для химлаборатории нет. Там в милиграммах надо.
А то и в микро. А int у нас содержит всего-то 2147483647 милиграмм или 2147
килограмма. Маловато 2 тонны для цеха будет.
По тем же причинам не катит decimal - заранее неизвестна необходимая
точность хранения для разных складов. А резервировать 20 знаков после
запятой нехорошо, тем более, что всего их 38.
>А вот с float, особенно с большими числами (или с большими дробями)
проблемм
>не оберешься.
Ну не было проблем. Пока по крайней мере. Пока - это уже второй год пошел.
Serge Tarasov
Ilya V. Zvyagin wrote in message <01be2e8d$a343f980$a50800c0@dream>...
>И чем же это тебе DECIMAL или NUMERIC не угодил ?
проектирование.
>> Все прекрасно работает во float. И сравнивается замечательно с
>применением
>> округления. Если бы не эта ошибка в M$, то можно было вообще жить
>спокойно.
>Еще раз - это не ошибка.
>А склад такой - на float - будет "работать" нормально до первой потери
>точности.
Для этого-то и существует округление. Чтобы точность поиметь в нужных для
данного вычисления пределах.
Serge Tarasov
Ilya V. Zvyagin wrote in message <01be2e9d$91d82f80$a50800c0@dream>...
>Слушайте, ну что, офигели, что ли все, в детский сад всем, или за парту ?
>Ну хоть в школе (высшей) численные методы-то проходили ?
>Или я один такой , осчастливленный ?
>> То есть if ( round( @Quantity, 1 ) = 1.7 )
>> Но из-за досадной "неточности" в M$, я получу не совсем то, что ожидал.
>> Конечно, тысячные доли можно и не учитывать, но прецедент неприятный.
>
>НЕЛЬЗЯ сравнивать на равенство число в формате float.
>
>Поскольку @Quantity float, то round(@Quantity,1) будет тоже float, и этот
>оператор надо писать
>не иначе, как
>
>if abs( round( @Quantity, 1 ) - 1.7 ) < epsilon
>
>, где epsilon - какая-то малая величина, оценивающая порог значимости.
>
Зачем приплетать численные методы к простым вычислениям абсолютных
погрешностей (алгебра 6-й класс) ?
Я изменю условия задачи. Уберем round, который у M$ возвращает тот же тип,
что и тип аргумента.
declare @f float
select @f = 1.65
select @f, convert( numeric( 10, 1 ), @f )
(1 row(s) affected)
------------------------ --------------
1.65 1.6
^^^ - а это что за херомантия ? и тип у него
numeric( 10, 1 )
Serge Tarasov
Ivan Frolcov wrote in message <75qipb$c...@omega.fintech.ru>...
>"На складе имеется e тонн калийных и pi тонн прочих удобрений"...
Вообще-то e и pi во float храняться до определенной степени точности.
Поэтому вполне может возникнуть ситуация, когда количество "удобрений" на
"складе" совпадет до последнего хранимого знака с этими числами.
;-))
Vadim Rumyantsev
В сpеду, 23 декабpя 1998 20:58:31, Ilya V. Zvyagin писал to All:
IZ> Да, тут недавно вся эха дружно улыбалась по поводу float в PRIMARY
IZ> KEY.
Да-да, и чему же это она улыбалась, интересно послушать? Я как-то пропустил это
обсуждение, а между тем у нас в текущем проекте основная масса информации
сосредоточена как раз в таблице, primary key которой включает поле типа double
(это измерительная информация, зависимость от измеренного/вычисленного времени,
около 10Г вещественных чисел в год). Мы что-то делаем не так?..
Sincerely,
Vadim.
Crimean
>единицы системы Си - грамм, метр, метр квадратный. А в отгрузках можно
>ставить любые "производные единицы" - килограмм, литр, квадратный километр,
>погонный метр через соотношения с базовыми.
>Это позволяет _очень быстро_ считать склад по операциям и затем "одним
>движением" переводить результат в любую производную единицу.
>Точность представления является свойством конкретной единицы измерения.
>Склад - это более ширококе понятие, нежели место хранения бочек с пивом.
Это
>некоторый регистр накопления каких-то объектов учета.
>Если учитывать в int, то всегда есть проблема, что у заказчика окажется
>необходимость считать в еще меньших (или слишком больших) единицах, чем это
>предусмотрено. Например, решили сырье в граммах считать - для
сталелитейного
>производства это пройдет, а для химлаборатории нет. Там в милиграммах надо.
>А то и в микро. А int у нас содержит всего-то 2147483647 милиграмм или 2147
>килограмма. Маловато 2 тонны для цеха будет.
>По тем же причинам не катит decimal - заранее неизвестна необходимая
>точность хранения для разных складов. А резервировать 20 знаков после
>запятой нехорошо, тем более, что всего их 38.
>
одном (известном всем ;) месте, а количество "отгруженных единиц" - в
накладной. Тогда все честно и с точки зрения НФ (нормальных форм) тоже
правильно.
По поводу микрограммов: если получатель 100 тонн берет, вряд ли в накладной
в микрограммах указано будет, даже если получатель - химлаборатория, как же
тогда "расходы от грызунов будующих периодов"?
ИП! (исключительно пошутить)
Обанкротится такой склад быстро очень, если на "усушку" и "утряску" не
закладываться при отгрузке. Все равно ведь точно
3,178,243,168,253,415.86512543 микрограмм не отгрузишь, даже если заказчик
ТОЧНО за это количество и заплатил; ему все равно 20 мешков дадут, да еще и
+- 1 мешок (поправка на погрузку-разгрузку) :)))
Ivan Frolcov
> А то и в микро. А int у нас содержит всего-то 2147483647 милиграмм или 2147
> килограмма. Маловато 2 тонны для цеха будет.
> По тем же причинам не катит decimal - заранее неизвестна необходимая
> точность хранения для разных складов. А резервировать 20 знаков после
> запятой нехорошо, тем более, что всего их 38.
Масса Земли равна примерно 6E27 грамм, так что 38-разрядный decimal
позволит вам оперировать с массой Земли с точностью до микрограмма.
Неужели мало? Чем же вы там занимаетесь? Учитываете движение нейтрино
в скоплениях галактик?
Aleksey Panshin
>declare @f float
>select @f = 1.65
>select @f, convert( numeric( 10, 1 ), @f )
>
>(1 row(s) affected)
>
>
>------------------------ --------------
>1.65 1.6
> ^^^ - а это что за херомантия ? и тип у него
>numeric( 10, 1 )
>
select @f, Round(convert( numeric( 10, 2 ), @f ),1)
рекомендации лучших эскьюэлеводов :)
WBR Lesha (le...@mega.ru)
Tolik Tentser
В чреве акулы, пойманной 24 Dec 1998 14:06:07 +0300,
дети капитана Гранта нашли письмо на тему 'Re: Что-то мне становится
нехорошо':
>declare @f float
>select @f = 1.65
>select @f, convert( numeric( 10, 1 ), @f )
>
>(1 row(s) affected)
>
>
>------------------------ --------------
>1.65 1.6
> ^^^ - а это что за херомантия ? и тип у него
>numeric( 10, 1 )
Еще раз объясняю. @f, как он есть float точно 1.65 не равен
(и вообще в пределе float ничему точно не равен)
Теперь представь, что в нем
1,6499999999
Тогда округление до второго знака даст 1,65,
а до первого 1,6, что ты и наблюдаешь на экране.
Bye ...
Тенцер А.Л.
to...@katren.nsk.ru
ICQ 15925834
Tolik Tentser
В чреве акулы, пойманной Wed, 23 Dec 98 19:12:47 +0300,
дети капитана Гранта нашли письмо на тему 'Что-то мне становится
нехорошо':
> Люди знающие, подскажите, близок ли конец? В смысле, на каком объеме базы (Mb
>или записей) M$ Access-у 2.0 смеpтушка пpидет? Сейчас там уже под 20 метpов...
>Таблиц штук 30 сильносвязанных, из них штук 5 по 10-20 тыщ записей, остальное
>спpавочники. Я уже не говоpю пpо сетевой доступ с 10 pабочих мест...
>
Где-то уже близко. :-)
Но, в хорошей сети может еще столько же потянуть, если
ввода интенсивного нет.
А не пробовал все это импортировать в MS SQL ?
В принципе он Access`а неплохо понимает, включая даже русские имена
полей.
Serge Tarasov
Crimean wrote in message <75ta6q$kcb$1...@dipt.donbass.net>...
>Вопрос не в этом. Вопрос в том, чтобы хранить единицы с коэффициентами в
>одном (известном всем ;) месте, а количество "отгруженных единиц" - в
>накладной. Тогда все честно и с точки зрения НФ (нормальных форм) тоже
>правильно.
количество по первичным документам. Втройне хреново, когда такой рассчет
будет вестись с перемножением соотношений единиц и распознаванием типов
документов. Первичные документы в общем случае не годятся для оперативной
аналитики.
Уточню, со складом работают не накладные, а СОБЫТИЯ ПЕРЕМЕЩЕНИЯ ОБЪЕКТОВ
УЧЕТА (ОУ). Самих первичных документов может быть сколько угодно: накладные,
внутренние перемещения, акты списания, акты инвентаризации - они все
генерируют операции или, другими словами, проводки. Вот и попробуй
рассчитать количество некоего ОУ на складе на некоторую дату по документам.
А операций с ним было, скажем тысяч 500.
>По поводу микрограммов: если получатель 100 тонн берет, вряд ли в накладной
>в микрограммах указано будет, даже если получатель - химлаборатория, как же
>тогда "расходы от грызунов будующих периодов"?
И цеха и химлаборатория ведут учет в одной системе. Делать склады отдельно
под "тонны" и "граммы" - Сизифов труд.
Vitaly Fedoriv
23 Dec 98 19:12, Evgeny Ananyev wrote to Ilya V. Zvyagin:
IZ>> а самому на ORACLE под UNIXом
EA> Мне бы чего freeware, да чтоб пpогу пеpенести без больших
EA> пеpеделок... Hо pазве с M$ Access-а пеpенесешь? Имена-то атpибутов
^^^^^^^^^^^^^^^^^^^^
EA> киpиллицей, с пpобелами и в квадpатных скобках. Логика в основном на
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
EA> Васике. Документации и комментаpиев в пpинципе не велось. Вот
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
EA> пpиспичило, pасшифpовал по коду -- у меня фоpмиpование отчета стало
EA> пpолетать за 20 секунд вместо их 6 минут;) Одним всего запpосом --
EA> вместо их вызова кода на Васике с паpой вложенных в цикл подзапpосов и
EA> функций _на_ _каждую!_ из полутоpа тысяч записей Ж%( ) Hо это ж надо
EA> пpосечь спеpва, чего они хотели получить этим хитpож... умным кодом!
EA> Вpемя!!! А кода еще много.
Йо. Чего-то мне тоже нехоpошо. :(
Это ж ... В общем, нет слов (веpнее есть, но все нецензуpные).
EA> Люди знающие, подскажите, близок ли конец? В смысле, на каком объеме
EA> базы (Mb или записей) M$ Access-у 2.0 смеpтушка пpидет? Сейчас там уже
EA> под 20 метpов... Таблиц штук 30 сильносвязанных, из них штук 5 по
EA> 10-20 тыщ записей, остальное спpавочники. Я уже не говоpю пpо сетевой
EA> доступ с 10 pабочих мест...
Де нет, по обьему базы вpоде теpпимо (в смысле, еще не помpет).
Пpавда, помнится у MS Access 2.0 вpоде были какие-то пpоблемы с pаботой под NT
и с 2000 годом (интеpесны pекомендации M$ - "пеpейдите на MS Access 97" :)).
Vitaly
Anatoly Kuznetsov
Wednesday December 23 1998 13:07, Serge Tarasov wrote to All:
>> Как показывает опыт, для коммерческих приложений более, чем достаточно
>> (для работы с деньгами, ессно)ДВУХ типов данных: int + money. И никаких
>> траблов, если не забывать писать round( MyMoney, 2 ).
ST> Романтик ты ;-))
ST> А вещественный (не целочисленный !) склад в чем вести ? В decimal ? Hе
ST> хорошо.
Почему не хорошо ? Можно ведь в кач ед. изм и милиграмм выбрать если надо.
У меня склад в децималах живет.
Вот если склад будет не только вещественный, но и комплексный, тады дааа,
децималом не обойтись :-)
Bst.Rgds.TLK. - MailTo:t...@nbd.kis.ru
Ilya V. Zvyagin
Evgeny Ananyev <Evgeny....@p17.f201.n5011.z2.fidonet.org> записано в
статью <9144...@p17.f201.n5011.z2.fidonet.ftn>...
> Пpосто пpоцитиpую себя же:
> EA>> Только ногами не бейте, эту базу и комплекс не я стpоил, я этих
Я это помню. И специально приписку вставлял. Но ...
> IZ> А что два float-а сравнивать нельзя не учили ?
> Меня учили. Тех, кто базу создавал и pазpабатывал -- навеpное, плохо
:(
Так что ж ты пишешь, что мол в сервере ошибка ?
Или это не ты был ?
> А еще они pазносят оплату, наpываются на _неполное_ ее погашение
(патамучта
> float!) и отдельным сообщеньицем пpедлагают юзеpу ввести почти ту же
сумму,
> только с вполне конкpетным числом девяток точности. _КАКОВО_ ? Ж%[.....]
Хоррррошоооо !!!
> А я о чем? Вывод: эти гоpе-pазpаботчики -- люди неноpмальные. И SQL-я
они
> шаpахаются, как чеpт ладана -- пpивыкли мышой pисовать в фоpмочках. Hо
мне от
> этого не легче, для меня они вышестоящая оpганизация, а на пpоге этой
кpивой
> завязана вся pабота отделения. И на всю контоpу -- я один компутеpщик.
PRIVATELY : Беги оттуда, если есть куда.
> Вопpос: как выпихнуть? Там они еще и логику pазноса оплаты чеpез
float
> закpутили. Hапpимеp, пpиходит в банк столько-то денег оплаты. Имеется
некое
> число выставленных сумм (счет-фактуp) но не точно на сумму оплаты, есте.
Hадо
> pаспpеделить на несколько фактуp, по каким-то пpавилам. Hу вот, и тут,
млин, они
> задействуют какие-то левые float-доли, пеpемножают на них суммы, и т.п..
> Уpодство...
Не , это может быть вполне нормально. Но все же личше бы держать просто
балланс с
контрагентом и по FIFO покрывать фактуры.
> IZ> Hу а MS, конечно, глюкало, маст дай, и Гейтса вешать надо и тортами
> IZ> закидать,
> Гуталиновыми. Подписываюсь.
Э, это типа шутка была, что мол неча на зеркало пенять.
> Мне бы чего freeware, да чтоб пpогу пеpенести без больших
пеpеделок... Hо
> pазве с M$ Access-а пеpенесешь? Имена-то атpибутов киpиллицей, с
пpобелами и в
> квадpатных скобках. Логика в основном на Васике. Документации и
комментаpиев в
Это ФИГНЯ. Любой SQL сервер (уж MSSQL/Sybase то точно) поддерживают русские
названия
любых объектов. Только обычно это ни на фиг не надо.
> пpинципе не велось. Вот пpиспичило, pасшифpовал по коду -- у меня
фоpмиpование
> отчета стало пpолетать за 20 секунд вместо их 6 минут;) Одним всего
запpосом --
> вместо их вызова кода на Васике с паpой вложенных в цикл подзапpосов и
функций
> _на_ _каждую!_ из полутоpа тысяч записей Ж%( ) Hо это ж надо пpосечь
спеpва,
> чего они хотели получить этим хитpож... умным кодом! Вpемя!!! А кода еще
много.
Да, ACCESS - дрянь, если хоть что-то большее кроме получил-послал на нем
напишешь.
Ilya V. Zvyagin
Vadim Rumyantsev <Vadim.Ru...@f301.n5030.z2.fidonet.org> записано в
статью <9145...@f301.n5030.z2.ftn>...
> IZ> Да, тут недавно вся эха дружно улыбалась по поводу float в PRIMARY
> IZ> KEY.
> Да-да, и чему же это она улыбалась, интересно послушать? Я как-то
пропустил это
> обсуждение, а между тем у нас в текущем проекте основная масса информации
> сосредоточена как раз в таблице, primary key которой включает поле типа
double
> (это измерительная информация, зависимость от измеренного/вычисленного
времени,
> около 10Г вещественных чисел в год). Мы что-то делаем не так?..
Так у вас что, данные не пропадают периодически ?
Ну так будут.
Блин. Нельзя сравнивать два float на равенство. PK служит для идентификации
КАЖДОЙ записи.
Т.е. select ... from my_table where PK = <ЗНАЧЕНИЕ PK>
Следовательно, в PK не должно быть никаких float. Хотя , конечно, может,
если вам не нужно каждую запись идентифицировать.
Vadim Rumyantsev
В пятницу, 25 декабpя 1998 19:32:28, Ilya V. Zvyagin писал to All:
IZ> Так у вас что, данные не пропадают периодически ? Hу так будут.
В смысле?
IZ> Блин. Hельзя сравнивать два float на равенство.
Вообще-то можно, если они получены одним и тем же способом. Сами по себе битики
никуда не деваются.
IZ> PK служит для идентификации КАЖДОЙ записи. Т.е. select ... from
IZ> my_table where PK = <ЗHАЧЕHИЕ PK>
Hу да. И в чём ты видишь здесь проблемы? Естественно, эти значения при
сравнении на равенство нельзя вычислять или даже просто записывать в десятичном
виде.
IZ> Следовательно, в PK не должно быть никаких float.
Соответственно, вывод неверен.
IZ> Хотя , конечно, может, если вам не нужно каждую запись
IZ> идентифицировать.
Это второй момент. По отдельности -- не нужно, конечно, поскольку одна точка не
имеет смысла для статистической обработки. Выбираются всегда интервалы.
Sincerely,
Vadim.
Phillip Delgiado
| В письме от Thu Dec 24 1998 13:53 на тему Re: Что-то мне становится нехорошо
| Serge Tarasov писал All:
ST> точность хранения для разных складов. А резервировать 20 знаков
ST> после запятой нехорошо, тем более, что всего их 38.
Есть стаpый добpый подход - хpанить отдельно количество знаков для конкpетной
записи. А остальное - максимальный decimal без знаков после запятой.
И все получится. Пpимеpно так, как мне помнится, сделано в Фоpте.
See later! Phil
... Эта доpога ведет в никуда, но зато по ней можно идти вечно.
Serge Tarasov
Anatoly Kuznetsov wrote in message <9145...@p1.f75.n5015.z2.ftn>...
> ST> А вещественный (не целочисленный !) склад в чем вести ? В decimal ? Hе
> ST> хорошо.
>
> Почему не хорошо ? Можно ведь в кач ед. изм и милиграмм выбрать если
надо.
>У меня склад в децималах живет.
запятой может понадобиться, поэтому float - более естественный в таком
случае. На то и название у него "число с ПЛАВАЮЩЕЙ запятой".
Например, если базовая единица - кубический метр. Тогда для хранения запасов
в цистернах хватит и трех знаков. А если еще и в пробирках и ампулах, то
надо 9 знаков. Аналогично, неизвестено сколько надо перед запятой знаков
поиметь.
Но в принципе и децималы прокатят, если забиться на максимум с обеих сторон.
> Вот если склад будет не только вещественный, но и комплексный, тады
дааа,
>децималом не обойтись :-)
О-ооо ! Вот это кайфовая штука ! Я подумаю, а может и правда такой склад
имеет практическое значение ;-))
Serge Tarasov
Ivan Frolcov wrote in message <75tfn2$j...@omega.fintech.ru>...
>> По тем же причинам не катит decimal - заранее неизвестна необходимая
>> запятой нехорошо, тем более, что всего их 38.
>Масса Земли равна примерно 6E27 грамм, так что 38-разрядный decimal
>позволит вам оперировать с массой Земли с точностью до микрограмма.
>Неужели мало? Чем же вы там занимаетесь? Учитываете движение нейтрино
>в скоплениях галактик?
знаков после запятой может понадобиться, поэтому float - более естественный
в таком случае. На то и название у него "число с ПЛАВАЮЩЕЙ запятой".
Например, если базовая единица - кубический метр. Тогда для хранения запасов
в цистернах хватит и трех знаков. А если еще и в пробирках и ампулах, то
надо 9 знаков. Аналогично, неизвестено сколько надо перед запятой знаков
поиметь.
Но в принципе и децималы прокатят, если забиться на максимум с обеих сторон.
Но как предложил Анатолий Кузнецов, склад на комплексных числах - это еще
круче. Уж он - то точно все случаи хранения абстрактных сущностей покроет
;-)))
Tolik Tentser
В чреве акулы, пойманной 25 Dec 1998 19:32:28 +0300,
дети капитана Гранта нашли письмо на тему 'Re: Что-то мне становится
нехорошо':
>Так у вас что, данные не пропадают периодически ?
>Ну так будут.
Вряд ли.
Если не производить никаких операций типа + - * / ROUND,
то можно рассматривать float как массив битов, который
вполне корректно переносится при присваивании и сравнивается
при сравнении.
Если они только хранятся и используются для связи таблиц -
ничего страшного, но как только их начнут изменять (если там
такое предусмотрено) - тут могут начаться выкидоны.
>Блин. Нельзя сравнивать два float на равенство. PK служит для идентификации
>КАЖДОЙ записи.
>Т.е. select ... from my_table where PK = <ЗНАЧЕНИЕ PK>
Если это значение ПК лежит в другой таблице и заполнено теми же
битами - все прокатит для JOIN`а. Но вот руками ввсети ПК для поиска
или сформировать его в программе будет нетривиально.
>Следовательно, в PK не должно быть никаких float. Хотя , конечно, может,
>если вам не нужно каждую запись идентифицировать.
Но вообще ПK - float есть изврат крайний, хотя - велик аллах, в жизни
всякое бывает.
Alex Kaganoff
ST> Я изменю условия задачи. Уберем round, который у M$ возвращает тот же тип,
ST> что и тип аргумента.
ST> declare @f float
ST> select @f = 1.65
ST> select @f, convert( numeric( 10, 1 ), @f )
ST> (1 row(s) affected)
ST> ------------------------ --------------
ST> 1.65 1.6
ST> ^^^ - а это что за херомантия ?
А ты что хотел? Стандаpтное (для Запада) банковское окpугление до ближайшего
четного.
ST> и тип у него numeric( 10, 1 )
Так ты сам попpосил такой тип.
Alex
Лучше быть нужным, чем свободным -
Это я знаю по себе.
Akzhan Abdulin
19 Dec 98 22:39, Alexey Kopernick написал Serge Tarasov:
AK> Итак, кто делает жопу своим юзерам? MS? Или все-таки Sybase, разработчики
AK> которого похоже даже в школе не учились.
AK> Округляется в сторону ближайшей четной цифры. Этому еще в школе учат :)
AK> а вот когда 1.649999999 превращается в 1.7 ну это уже просто шик :)
Блин, как дети.
Сколько правил округления есть на свете? Много. А стандартизовано ли в SQL -
нет.
Hеча и пенять.
С уважением,
Akzhan