Пишет SergeyBykov,
Уж не знаю, кто сделал цены в DealGoods float, но я чуть рассудка не лишился, пытаясь их округлить до 2-х знаков. В результате пришел к выводу что это сделать нельзя. Ниже простой пример, это иллюстрирующий:
create table t1 (f1 float) insert into t1 (f1) values (186.92) select * from t1
В 6.5 получаем:
186.92
В 2000-м получаем:
186.91999999999
Кто сможет на 2000-м (SP2) получить в поле float ровно 186.92, тому поцелуй :)
Это внутреннее представление ч
Пишет st,
Это внутреннее представление числа на сервере такое.
Но это не должно мешать работе. Итоги округляешь и все в порядке.
Но это не должно м
Пишет SergeyBykov,
Еще как мешает. Такие ошибки округления лезут ...
Сейчам не могу привести компактный пример, но это прекрасно проявлется в сумме сделки продажи.
Может это я убирал переделки I
Пишет DTsuranoff,
Может это я убирал переделки IP на float и не везде убрал
Вот пример Игорю почему нельзя использовать float
А зато единицы измерения хорошие
Вот пример Игорю п
Пишет ipanshin,
Да согласен. float нельзя здесь использовать. Лучше всего использовать numeric. Тогда и единицы измерения лягут куда надо. MS imho вообще наплевал на float. Я пытался вывести точность для тысячной доли угловой секунды. Только numeric. Все остальное для детей.
Кстати, ты мои переделки убирал? Тогда единицы измерения должны работать. А если ед.изм. не работают, тогда и переделки не мои. Там еще многое можно найти залихвастское. Как работает диву даешься.
Еще как мешает. Та
Пишет st,
Серега, извини, не поверю, пока не увижу пример :) В ONTARIO у меня на float весь матучет работал без проблем.
На какой версии
Пишет SergeyBykov,
На какой версии?
На какой версии?</
Пишет st,
Начинали с 6.5, сейчас у них все на 2000.
См. начало темы. На 6.5 такой
Пишет SergeyBykov,
См. начало темы. На 6.5 такой проблемы нет, а на 2000 наверняка им пришлось все на money переделать. Но это уже не твои проблемы, верно? :)
См. начало темы
Пишет st,
Что на money переделывать, матучет ? :) :)
Деньги изначально хранились в money, которое есть просто numeric(19, 4). Во float хранятся количества, которые проблематично запихнуть а numeric из-за неизвестной заранее необходимой разрядности для хранения количества в базовых ед.измерения.
Я сделал небольшой типовой тест на MSSQL2000.
Заполняется таблица из 1000 строк вещественными занчениями (количество и цена). Затем считаем сумму их произведений
1. Без округления
2. Округляя предварительно каждое количество до 4 знаков
Результаты после округления отличаются на единицу во втором знаке. И это при относительной погрешности 2,3e-10 (!)
Бухгалтерия не эксперементальн
Пишет SergeyBykov,
Бухгалтерия не эксперементальная физика, в фин. учете все погрешности АБСОЛЮТНЫЕ.
Расхождение на 1 цент - фин. преступление.
По поводу хранения натуральных величин (кол-ва, например) - согласен. Но я с самого начала писал про цены и суммы.
P.S.: хотел бы я послушать диалог СТ с Верещагиным (ННШ, фин. директор) :) :lol: :twisted:
А диалога бы просто не было.
Пишет st,
А диалога бы просто не было.
Для официальной отчетности, где важно совпадение до копейки (хотя, я читал постановления, где минфин и налоговики официально разрешают до рубля) все повсеместно используют подгонку.
В нехусе, например, она тоже используется для подгонки цен под "правильные" значения для расчета НДС, иначе итоги не совпадут.
P.S.: хотел бы я п
Пишет DTsuranoff,
Я так понял, последний смайлик изображает Верещагина ?
Смайлики символизируют смену н
Пишет SergeyBykov,
Смайлики символизируют смену настроения "В" в процессе разговора. Последния фаза - характеное движение головой и руками (ДЦ его очень удачно копирует, так что покажет при случае СТ).
Что касается официальной отчетности с точнотью до рубля - не в курсе. Знаю только что, есть методические указания по составлению счетов-фактур, где сказано, что суммы в строке могут не биться. Т.е. цена без НДС * кол-во <> Сумма без НДС. Т.к. даже налоговая не в силах изменить правила арифметики с фиксированной точнотью.
Можно расценивать как признание собственной некомпетентности в постановке фин. учета? :)
В ПМ я переписал полностью расчет сумм в счетах (сделках), накладных и счетах-фактурах, т.к. в СР в каждом из этих документов применяется своя методика. В таких условиях совпадение сумм в связанных документах - счастливая случайность.
А диал
Пишет st,
Не вижу смысла в диалоге: нужна точность в итогах - делаем подгонку с требуемой точностью, не нужна - обходимся маленькой относительной погрешностью.
Оцени уровень зрелости нишишанцевских руководителей здесь :)
http://krylov.lib.ru/maturity_man1.html
нужна точность в и
Пишет SergeyBykov,
Это позиция кодера, а не аналитика.
Поддерживаю. Точность нужна до
Пишет ipanshin,
Поддерживаю. Точность нужна до копейки. Любая взятая копейка - это воровство. Отдай кесарю - кесарево. Сам сейчас вылавливаю блох.
Еще раз будем переписывать, но с ед.изм.
Добился генерации hash многократной.
нужна
Пишет st,
Почему ? Я же сразу сказал, что точность нужна для официальной отчестности, а в управленческом учете допустимы небольшие относительные погрешности. Т.е. тип числа для хранения данных учета инвариантен итоговому представлению данных. Важно, чтобы разрядность была достаточной для обеспечения требуемой погрешности.
Собсно гря, этот вопрос (точность хранения, обработки и представления числовых данных) к постановке задачи финучета имеет отдаленное отношение. Максимум, как одно из требований.
Потому что в управденческих от
Пишет DTsuranoff,
Потому что в управденческих отчетах тоже ижут проверки сходится не сходится
Не сошлось на 1.33
Это накопилось округление по сотне счетов ? Или пропушена отгрузка одной мыши ?
Я тебе про то же и говорю. Есл
Пишет st,
Я тебе про то же и говорю. Если манагер считает, что для поиска причин расхождения в 1,33 евро нужно потратить время своих сотрудников (не думаю, правда, что час работы кого-то из них обходится фирме дешевле), то выкатывается соответствующее требование к точности.
Обычно же расхождения ищутся, если поиск будет стоит дешевле. Иначе просто спишут "на усушку".
О чем вообще дискуссия ? Округляй float во время обработки, а не по итогам, и ты получишь тот же самый numeric. Сделай вьюшку, где поля float будут представлены как numeric и работай с ней.
Проблемы не существует.
2 СТ: тебя близко нельзя подпу
Пишет SergeyBykov,
2 СТ: тебя близко нельзя подпускать к фин. учету. Ты абсолютгно легально объявляешь, что есть некоторый процент, который можно спи...ить и за это ни чего не будет.
Это как раз в официальной отчетности могут быть погрешности, если они не влияют на уплату налогов.
А в управленческой, даже при миллионных оборотах, все должно биться до цента. В реальности, конечно, такого добиться трудно, т.к. есть человеческий фактор. Но сама ИС не должна вносить дополнительную погрешность, иначе все будет списано на "компьютер, который не умеет считать" и контору разворуют.
все должно биться
Пишет ipanshin,
Да, весьма правильно.
О, Серега разозлился не на шут
Пишет st,
О, Серега разозлился не на шутку :) Хорошо, давай пофлеймим немного.
Я утверждаю, что независимо от того, будешь ты хранить деньги в money или во float система все равно будет вносить погрешности.
Я также утверждаю, что если все четыре арифметических операции используются при обработке равновероятно, то эти погрешности будут одинаковые.
Я также предлагаю тебе не путать погрешности и "совпадение до цента". Совпадение можно получить при любой погрешности, потому что, как грил тов.Сталин: "Неважно как проголосовали, важно как посчитали".
Проиллюстрирую преимущество float перед money на простом примере
Результаты: (float округлен до четвертого знака как в money)
1.0000 1.0101
Вопросы есть ? :)
О, вспомнил и нашел дискуссию
Пишет st,
О, вспомнил и нашел дискуссию в ФИДО по той же теме. Там и про Sybase и про вещественный склад есть :)
Вот ссылка на дискуссию
Вот ссылка на мое сообщение про склад и единицы измерения там же.
Вообще, тема сильно связана с единицами измерения.
Тю, дал ссылки на 1998 год. Эт
Пишет ipanshin,
Тю, дал ссылки на 1998 год. Это прямо исторический экскурс.
Последний проект, в котором я реализовал единицы измерения (проект учета масел) я реализовал на типе varchar(). В принципе и в питер мобил реализовано также, только перед запросом происходит конвертация. Я могу делать документы зависимые от единиц измерения. Более того можно даже подключал физический закон ( скажем f=m*g ) к единицам измерения в документе, что и было проверено.
"Пробежал" анналы от
Пишет SergeyBykov,
"Пробежал" анналы от СТ.
Полное подтверждение моей позиции - Float (Real) в учетных системах использовать нельзя!
Float (Real) в уч
Пишет ipanshin,
И numeric() тоже так как по существу это таже float. только varchar() только в ней ты не теряешь контроля над всеми цифровыми позициями числа.
И numeric() тоже т
Пишет SergeyBykov,
Numeric самый правильны тип для учета финансов и склада, т.к. он реализует двоично-десятичное представление числа, только в более компактной форме - 4 бита на разряд, в отличие от varchar (8 бит на разряд).
Можно и numeric, только непоня
Пишет st,
Можно и numeric, только непонятно, "где запятую ставить" :)
ИМХО, float рулит.
Можно и numeric, т
Пишет ipanshin,
Да только реализовано на varchar() :) Т.е., что видит человек то и правильно
Для отчетности да convert(numeric() ) согласен
для арифметических всяческих наворотов да convert(float ) согласен
Но хранить надо в varchar()
Например, он хочет видеть такой формат
000444.565656000000 or
000444,565656000000
Какой numeric() или float справится? :)
Не, до varchar я еще не созрел
Пишет st,
Не, до varchar я еще не созрел. ИМХО, на преобразования потребуется много ненужного времени.
Можно и numeric, т
Пишет SergeyBykov,
В numeric запятая всегда на своем месте, в отличии от float. У float очень небольшое кол-во значащих разрядов, использовать этот тип в регистрах учета нельзя.
получаем:
1,23123123123123E+20 123123123123123123123.1500 123123123123123130000.0000
Например, он хочет
Пишет SergeyBykov,
Это формат предствления, для хренения "лишнии" нули не нужны.
Numeric выводит все знаки после запятой.
В numeric запятая
Пишет st,
В этом и проблема. Поставишь запятую в одно место - нормально, для других ТМЦ окажется запятой.
Если у тебя два склада в системе: один бетон учитывает, другой - химреактивы, то всякий раз придется "настраивать" разрядность и положение запятой.
При этом самый точный float (15 разрядов) занимает 8 байт (есть еще 8-разрядный 4-байтовый), а самый точный numeric (38 разрядов) - 17 байт, более чем в 2 раза больше.
У float 15 знаков с плавающей точкой. Относительная погрешность (1Е-15, 10 в минус 15 степени) уже физически недостижима при измерениях. Обычные весы в магазине - 10E-2, электронные - 1Е-3. Написать 20 знаков до запятой - это фикция. Нет таких весов даже близко.
Масса Земли 6*10^24 кг. Сколько у нее в 16 знаке - трудно сказать.
Таким образом, float обеспечивает охват практически всех физ.величин с разумной точностью учета (намного перекрывает все относительные погрешности измерений).
Приведу пример из практики. Дагестанцы, когда везут арбузы в Питер, перед самым городом останавливают машину и ночуют "на природе". А утром едут сдавать груз.
Потому что если приехать вечером, то окажется, что арбузы весят на полстони-сотню кило меньше (усушка по жаре). А за ночь арбузы впитывают влагу и добирают вес.
Грузятся они тоже утром или днем, поэтому вечерний привоз означал бы "недостачу", которую надо оплатить из своего кармана. А так, чаще всего, вес оказывается чуть больше загруженного.
Еще пример. Грузоподъемность нефтяного танкера - около 100 тыс. тонн. Использование float позволит "учесть" (беру в кавычки, т.к. см. пример с арбузами) нефть с точностью до микрограммов.
СТ, что бы отстоять свою позиц
Пишет SergeyBykov,
СТ, что бы отстоять свою позицию ты сменил тему на учет физ. величин. Посмотри первый пост, там речь о том, что деньги нельзя хранить во float.
Это настраивается в способе учета (система ед. измерения) связанном с каждой товарной позицией. В первом случае будут куб. м, во втором - граммы (или милиграммы).
Между прочим, бетон на складе хранить трудно - быстротвердеет :-).
1. В этой теме есть примеры, когда погрешность должна возникать. Например, все расчеты финансов ведутся с точностью до 2-х или 4-х знаков. Точно также в бухгалтерии поступают и с физическими величинами - округляют до удобного кол-ва знаков.
2. Для учета денег (а это основной объект в учетных системах) такого кол-ва разрядов может оказаться мало. До недавнего времени в Турции килограмм персиков стоил 1 500 000 лир. Сколько стоят все персики экспортированные за год в турецких лирах?
С деньгами вопросов нет - там
Пишет st,
С деньгами вопросов нет - там фиксированно 4 знака после запятой и неограничено :)) до запятой. Поэтому currency или decimal.
Float только для матучета.
Грузоподъемность н
Пишет ipanshin,
Замечу, что его никогда полностью не заливают, потому как объем нефтепродуктов в зависимости от температуры нелинейная величина. Отсюда вывод, чтобы его разгрузить требуется 100 составов поездов при температуре t градусов и 101 состав при температуре t+20
Т.е. надо учитывать еще и обычные физические законы. Но тогда ничего не положишь в карман левым способом. Типа пиво было бы неинтересно, если бы не было пены сверху пива. :) Кстати в Англии наливают в пинту пену, а оно превращается вся в пиво. Сам видел. :) Так зачем нам такой учет без физических законов?