Float по разному хранится в разных версиях

Уж не знаю, кто сделал цены в 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, тому поцелуй :)

Forums: 

Изображение пользователя Serguei_Tarassov.

Это внутреннее представление ч

Это внутреннее представление числа на сервере такое.

select convert(float, 186.92)
 
----------------------------------------------------- 
186.91999999999999

Но это не должно мешать работе. Итоги округляешь и все в порядке.

Но это не должно м

Но это не должно мешать работе. Итоги округляешь и все в порядке.

Еще как мешает. Такие ошибки округления лезут ...
Сейчам не могу привести компактный пример, но это прекрасно проявлется в сумме сделки продажи.

Может это я убирал переделки I

Может это я убирал переделки IP на float и не везде убрал
Вот пример Игорю почему нельзя использовать float
А зато единицы измерения хорошие

Изображение пользователя ipanshin.

Вот пример Игорю п

Вот пример Игорю почему нельзя использовать float
А зато единицы измерения хорошие

Да согласен. float нельзя здесь использовать. Лучше всего использовать numeric. Тогда и единицы измерения лягут куда надо. MS imho вообще наплевал на float. Я пытался вывести точность для тысячной доли угловой секунды. Только numeric. Все остальное для детей.
Кстати, ты мои переделки убирал? Тогда единицы измерения должны работать. А если ед.изм. не работают, тогда и переделки не мои. Там еще многое можно найти залихвастское. Как работает диву даешься.

Изображение пользователя Serguei_Tarassov.

Еще как мешает. Та

Еще как мешает. Такие ошибки округления лезут ...
Сейчам не могу привести компактный пример, но это прекрасно проявлется в сумме сделки продажи.

Серега, извини, не поверю, пока не увижу пример :) В ONTARIO у меня на float весь матучет работал без проблем.

См. начало темы. На 6.5 такой

См. начало темы. На 6.5 такой проблемы нет, а на 2000 наверняка им пришлось все на money переделать. Но это уже не твои проблемы, верно? :)

Изображение пользователя Serguei_Tarassov.

См. начало темы. Н

См. начало темы. На 6.5 такой проблемы нет, а на 2000 наверняка им пришлось все на money переделать. Но это уже не твои проблемы, верно? :)

Что на money переделывать, матучет ? :) :)
Деньги изначально хранились в money, которое есть просто numeric(19, 4). Во float хранятся количества, которые проблематично запихнуть а numeric из-за неизвестной заранее необходимой разрядности для хранения количества в базовых ед.измерения.

Я сделал небольшой типовой тест на MSSQL2000.
Заполняется таблица из 1000 строк вещественными занчениями (количество и цена). Затем считаем сумму их произведений
1. Без округления
2. Округляя предварительно каждое количество до 4 знаков

Результаты после округления отличаются на единицу во втором знаке. И это при относительной погрешности 2,3e-10 (!)

set nocount on
go
create table F (v1 float, v2 money)
go
declare @count int, @i int, @r1 float, @r2 float
set @count = 1000
set @r1 = rand(datepart(ms, getdate()))
set @i = 1
while @i <= @count begin
  set @r1 = rand(@r1 * 100000000)
  set @r2 = rand()
  insert into F values (@r1 + @r2 * 1000, @r2 * 100)
  select @i = @i + 1
end
go
select
  sum(v1 * v2),
  convert(numeric(12, 2), sum(v1 * v2)),
  sum(convert(numeric(12, 4), v1) * v2),
  convert(numeric(12, 2), sum(convert(numeric(12, 4), v1) * v2))
from F
go
drop table F
go

--
34777247.629571319
34777247.63
34777247.63744812
34777247.64

Бухгалтерия не эксперементальн

Бухгалтерия не эксперементальная физика, в фин. учете все погрешности АБСОЛЮТНЫЕ.
Расхождение на 1 цент - фин. преступление.

По поводу хранения натуральных величин (кол-ва, например) - согласен. Но я с самого начала писал про цены и суммы.

P.S.: хотел бы я послушать диалог СТ с Верещагиным (ННШ, фин. директор) :) :lol: :twisted:

Изображение пользователя Serguei_Tarassov.

А диалога бы просто не было.

А диалога бы просто не было.
Для официальной отчетности, где важно совпадение до копейки (хотя, я читал постановления, где минфин и налоговики официально разрешают до рубля) все повсеместно используют подгонку.
В нехусе, например, она тоже используется для подгонки цен под "правильные" значения для расчета НДС, иначе итоги не совпадут.

P.S.: хотел бы я п

P.S.: хотел бы я послушать диалог СТ с Верещагиным (ННШ, фин. директор) :) :lol: :twisted:

Я так понял, последний смайлик изображает Верещагина ?

Смайлики символизируют смену н

Смайлики символизируют смену настроения "В" в процессе разговора. Последния фаза - характеное движение головой и руками (ДЦ его очень удачно копирует, так что покажет при случае СТ).

Что касается официальной отчетности с точнотью до рубля - не в курсе. Знаю только что, есть методические указания по составлению счетов-фактур, где сказано, что суммы в строке могут не биться. Т.е. цена без НДС * кол-во <> Сумма без НДС. Т.к. даже налоговая не в силах изменить правила арифметики с фиксированной точнотью.

А диалога бы просто не было.

Можно расценивать как признание собственной некомпетентности в постановке фин. учета? :)

В нехусе, например, она тоже используется для подгонки цен под "правильные" значения для расчета НДС, иначе итоги не совпадут.

В ПМ я переписал полностью расчет сумм в счетах (сделках), накладных и счетах-фактурах, т.к. в СР в каждом из этих документов применяется своя методика. В таких условиях совпадение сумм в связанных документах - счастливая случайность.

Изображение пользователя Serguei_Tarassov.

А диал

А диалога бы просто не было.

Можно расценивать как признание собственной некомпетентности в постановке фин. учета? :)

Не вижу смысла в диалоге: нужна точность в итогах - делаем подгонку с требуемой точностью, не нужна - обходимся маленькой относительной погрешностью.
Оцени уровень зрелости нишишанцевских руководителей здесь :)
http://krylov.lib.ru/maturity_man1.html

нужна точность в и

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

Это позиция кодера, а не аналитика.

Изображение пользователя ipanshin.

Поддерживаю. Точность нужна до

Поддерживаю. Точность нужна до копейки. Любая взятая копейка - это воровство. Отдай кесарю - кесарево. Сам сейчас вылавливаю блох.

В ПМ я переписал полностью расчет сумм в счетах (сделках),

Еще раз будем переписывать, но с ед.изм.

Добился генерации hash многократной.

Изображение пользователя Serguei_Tarassov.

нужна

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

Это позиция кодера, а не аналитика.

Почему ? Я же сразу сказал, что точность нужна для официальной отчестности, а в управленческом учете допустимы небольшие относительные погрешности. Т.е. тип числа для хранения данных учета инвариантен итоговому представлению данных. Важно, чтобы разрядность была достаточной для обеспечения требуемой погрешности.
Собсно гря, этот вопрос (точность хранения, обработки и представления числовых данных) к постановке задачи финучета имеет отдаленное отношение. Максимум, как одно из требований.

Потому что в управденческих от

Потому что в управденческих отчетах тоже ижут проверки сходится не сходится
Не сошлось на 1.33
Это накопилось округление по сотне счетов ? Или пропушена отгрузка одной мыши ?

Изображение пользователя Serguei_Tarassov.

Я тебе про то же и говорю. Есл

Я тебе про то же и говорю. Если манагер считает, что для поиска причин расхождения в 1,33 евро нужно потратить время своих сотрудников (не думаю, правда, что час работы кого-то из них обходится фирме дешевле), то выкатывается соответствующее требование к точности.
Обычно же расхождения ищутся, если поиск будет стоит дешевле. Иначе просто спишут "на усушку".

О чем вообще дискуссия ? Округляй float во время обработки, а не по итогам, и ты получишь тот же самый numeric. Сделай вьюшку, где поля float будут представлены как numeric и работай с ней.
Проблемы не существует.

2 СТ: тебя близко нельзя подпу

2 СТ: тебя близко нельзя подпускать к фин. учету. Ты абсолютгно легально объявляешь, что есть некоторый процент, который можно спи...ить и за это ни чего не будет.
Это как раз в официальной отчетности могут быть погрешности, если они не влияют на уплату налогов.
А в управленческой, даже при миллионных оборотах, все должно биться до цента. В реальности, конечно, такого добиться трудно, т.к. есть человеческий фактор. Но сама ИС не должна вносить дополнительную погрешность, иначе все будет списано на "компьютер, который не умеет считать" и контору разворуют.

Изображение пользователя Serguei_Tarassov.

О, Серега разозлился не на шут

О, Серега разозлился не на шутку :) Хорошо, давай пофлеймим немного.
Я утверждаю, что независимо от того, будешь ты хранить деньги в money или во float система все равно будет вносить погрешности.
Я также утверждаю, что если все четыре арифметических операции используются при обработке равновероятно, то эти погрешности будут одинаковые.

Я также предлагаю тебе не путать погрешности и "совпадение до цента". Совпадение можно получить при любой погрешности, потому что, как грил тов.Сталин: "Неважно как проголосовали, важно как посчитали".

Проиллюстрирую преимущество float перед money на простом примере

DECLARE @n1 float, @n2 money, @divider int, @i int
 
SELECT @divider = 777
SELECT @n1 = 1.0 / @divider,
       @n2 = 1.0 / @divider
SELECT @i = 2
 
WHILE @i <= @divider BEGIN
  SELECT @n1 = @n1 + 1.0 / @divider,
         @n2 = @n2 + 1.0 / @divider
  SELECT @i = @i + 1
END
 
SELECT convert(money, @n1), @n2

Результаты: (float округлен до четвертого знака как в money)
1.0000 1.0101

Вопросы есть ? :)

Изображение пользователя Serguei_Tarassov.

О, вспомнил и нашел дискуссию

О, вспомнил и нашел дискуссию в ФИДО по той же теме. Там и про Sybase и про вещественный склад есть :)
Вот ссылка на дискуссию
Вот ссылка на мое сообщение про склад и единицы измерения там же.

Вообще, тема сильно связана с единицами измерения.

Изображение пользователя ipanshin.

Тю, дал ссылки на 1998 год. Эт

Тю, дал ссылки на 1998 год. Это прямо исторический экскурс.

Последний проект, в котором я реализовал единицы измерения (проект учета масел) я реализовал на типе varchar(). В принципе и в питер мобил реализовано также, только перед запросом происходит конвертация. Я могу делать документы зависимые от единиц измерения. Более того можно даже подключал физический закон ( скажем f=m*g ) к единицам измерения в документе, что и было проверено.

&quot;Пробежал&quot; анналы от

"Пробежал" анналы от СТ.
Полное подтверждение моей позиции - Float (Real) в учетных системах использовать нельзя!

Изображение пользователя ipanshin.

Float (Real) в уч

Float (Real) в учетных системах использовать нельзя!

И numeric() тоже так как по существу это таже float. только varchar() только в ней ты не теряешь контроля над всеми цифровыми позициями числа.

И numeric() тоже т

И numeric() тоже так как по существу это таже float. только varchar() только в ней ты не теряешь контроля над всеми цифровыми позициями числа.

Numeric самый правильны тип для учета финансов и склада, т.к. он реализует двоично-десятичное представление числа, только в более компактной форме - 4 бита на разряд, в отличие от varchar (8 бит на разряд).

Изображение пользователя ipanshin.

Можно и numeric, т

Можно и numeric, только непонятно, "где запятую ставить"
ИМХО,
Можно и float

Да только реализовано на varchar() :) Т.е., что видит человек то и правильно

Для отчетности да convert(numeric() ) согласен
для арифметических всяческих наворотов да convert(float ) согласен
Но хранить надо в varchar()
Например, он хочет видеть такой формат

000444.565656000000 or
000444,565656000000

Какой numeric() или float справится? :)

Можно и numeric, т

Можно и numeric, только непонятно, "где запятую ставить" :)
ИМХО, float рулит.

В numeric запятая всегда на своем месте, в отличии от float. У float очень небольшое кол-во значащих разрядов, использовать этот тип в регистрах учета нельзя.

declare @v1 float, @v2 numeric(38,4)
 
set @v1=123123123123123123123.15
set @v2=123123123123123123123.15
 
select @v1 as [float], @v2 as [numeric], convert(numeric(38,4),@v1) as [float to numeric]

получаем:
1,23123123123123E+20 123123123123123123123.1500 123123123123123130000.0000

Например, он хочет

Например, он хочет видеть такой формат

000444.565656000000 or
000444,565656000000

Какой numeric() или float справится? :)

Это формат предствления, для хренения "лишнии" нули не нужны.
Numeric выводит все знаки после запятой.

Изображение пользователя Serguei_Tarassov.

В numeric запятая

В numeric запятая всегда на своем месте, в отличии от float.

В этом и проблема. Поставишь запятую в одно место - нормально, для других ТМЦ окажется запятой.
Если у тебя два склада в системе: один бетон учитывает, другой - химреактивы, то всякий раз придется "настраивать" разрядность и положение запятой.

При этом самый точный float (15 разрядов) занимает 8 байт (есть еще 8-разрядный 4-байтовый), а самый точный numeric (38 разрядов) - 17 байт, более чем в 2 раза больше.

У float очень небольшое кол-во значащих разрядов, использовать этот тип в регистрах учета нельзя.

У float 15 знаков с плавающей точкой. Относительная погрешность (1Е-15, 10 в минус 15 степени) уже физически недостижима при измерениях. Обычные весы в магазине - 10E-2, электронные - 1Е-3. Написать 20 знаков до запятой - это фикция. Нет таких весов даже близко.

Масса Земли 6*10^24 кг. Сколько у нее в 16 знаке - трудно сказать.

Таким образом, float обеспечивает охват практически всех физ.величин с разумной точностью учета (намного перекрывает все относительные погрешности измерений).

Приведу пример из практики. Дагестанцы, когда везут арбузы в Питер, перед самым городом останавливают машину и ночуют "на природе". А утром едут сдавать груз.
Потому что если приехать вечером, то окажется, что арбузы весят на полстони-сотню кило меньше (усушка по жаре). А за ночь арбузы впитывают влагу и добирают вес.
Грузятся они тоже утром или днем, поэтому вечерний привоз означал бы "недостачу", которую надо оплатить из своего кармана. А так, чаще всего, вес оказывается чуть больше загруженного.

Еще пример. Грузоподъемность нефтяного танкера - около 100 тыс. тонн. Использование float позволит "учесть" (беру в кавычки, т.к. см. пример с арбузами) нефть с точностью до микрограммов.

СТ, что бы отстоять свою позиц

СТ, что бы отстоять свою позицию ты сменил тему на учет физ. величин. Посмотри первый пост, там речь о том, что деньги нельзя хранить во float.

Если у тебя два склада в системе: один бетон учитывает, другой - химреактивы, то всякий раз придется "настраивать" разрядность и положение запятой.

Это настраивается в способе учета (система ед. измерения) связанном с каждой товарной позицией. В первом случае будут куб. м, во втором - граммы (или милиграммы).
Между прочим, бетон на складе хранить трудно - быстротвердеет :-).

У float 15 знаков с плавающей точкой. Относительная погрешность (1Е-15, 10 в минус 15 степени) уже физически недостижима при измерениях. Обычные весы в магазине - 10E-2, электронные - 1Е-3. Написать 20 знаков до запятой - это фикция. Нет таких весов даже близко.

1. В этой теме есть примеры, когда погрешность должна возникать. Например, все расчеты финансов ведутся с точностью до 2-х или 4-х знаков. Точно также в бухгалтерии поступают и с физическими величинами - округляют до удобного кол-ва знаков.
2. Для учета денег (а это основной объект в учетных системах) такого кол-ва разрядов может оказаться мало. До недавнего времени в Турции килограмм персиков стоил 1 500 000 лир. Сколько стоят все персики экспортированные за год в турецких лирах?

Изображение пользователя Serguei_Tarassov.

С деньгами вопросов нет - там

С деньгами вопросов нет - там фиксированно 4 знака после запятой и неограничено :)) до запятой. Поэтому currency или decimal.
Float только для матучета.

Изображение пользователя ipanshin.

Грузоподъемность н

Грузоподъемность нефтяного танкера - около 100 тыс. тонн.

Замечу, что его никогда полностью не заливают, потому как объем нефтепродуктов в зависимости от температуры нелинейная величина. Отсюда вывод, чтобы его разгрузить требуется 100 составов поездов при температуре t градусов и 101 состав при температуре t+20
Т.е. надо учитывать еще и обычные физические законы. Но тогда ничего не положишь в карман левым способом. Типа пиво было бы неинтересно, если бы не было пены сверху пива. :) Кстати в Англии наливают в пинту пену, а оно превращается вся в пиво. Сам видел. :) Так зачем нам такой учет без физических законов?