Переполнение Integer
Переполнение Integer
Здравствуйте! Если не трудно помогите разобраться в след. ситуации:
У меня есть поле в БД типа Integer в которых храняться байты трафика инетовского... При Select за большой промежуток времени по всем клиентам я получаю результат с отрицательным числом... Происходит как я понимаю переполнение мак. значения типа Integer.
как мне перехватить это событие, чтобы потом перевести эти байты в мегобайты.... гигобайты при select. Сразу хранить их в гигобайтах не получиться т.к. будет необъективная картина трафика....
Заранее спасибо...
если че непонятно написал я уточню...
У меня есть поле в БД типа Integer в которых храняться байты трафика инетовского... При Select за большой промежуток времени по всем клиентам я получаю результат с отрицательным числом... Происходит как я понимаю переполнение мак. значения типа Integer.
как мне перехватить это событие, чтобы потом перевести эти байты в мегобайты.... гигобайты при select. Сразу хранить их в гигобайтах не получиться т.к. будет необъективная картина трафика....
Заранее спасибо...
если че непонятно написал я уточню...
Переполнение Integer
А можно ли исходя из того какое число я получаю переводить или в мегобайты или в килобайты или в гигобайты?
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Переполнение Integer
Если можно поподробнее как это работает?
Переполнение Integer
Забыл сказать InterBase5. Там есть тип bigint?
Ну-ну. Numeric/Decimal с цифрами от 10 - это Double Precision в IB 5. Хочешь, чтобы у него в отчете трафик был с дробным числом байтов?WildSery писал(а):Переводи в numeric, туда точно влезет.
Самый простой вариант - переход на FB (юзать Int64). Либо суммировать в ХП (с проверкой переполнения). Но опять-таки, предел в 2 гига учитываемого трафика - это плохо.
Переполнение Integer
Либо суммировать в ХП (с проверкой переполнения).
Это как и что такое ХП? Возможности перейти на др. InterBase пока не представляеться возможным.... Понимаете ведь я могу попасть в переполнение в принципе при любом типе данных все зависит от количества хранимых в поле записей и том диапазоне Selecta котор. я делаю, как "перехватить " переполнение и исходя из этого делать какие либо операции типа перевести в гигобайты, теробайты и т.д.
Может так будет правильней?
Это как и что такое ХП? Возможности перейти на др. InterBase пока не представляеться возможным.... Понимаете ведь я могу попасть в переполнение в принципе при любом типе данных все зависит от количества хранимых в поле записей и том диапазоне Selecta котор. я делаю, как "перехватить " переполнение и исходя из этого делать какие либо операции типа перевести в гигобайты, теробайты и т.д.
Может так будет правильней?
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Ему как раз это и нужно. На больших значениях он собирается в Мега(Гига)байтах всё выдавать, так что ошибка на пару килобайт не видна невооружённым глазом. А на небольших значениях всё будет точно как в аптеке, надо только округлять правильно.CyberMax писал(а):Но в результате получаешь погрешность в несколько байт. Баланс в итоге не сойдется.
Уточнение:Dimitry Sibiryakov писал(а):Расхождение пойдет только когда у double precision станет нехватать значащих цифр на все число а их 15 штук как минимум ЕМНИП.
1. Их не минимум 15, а максимум 15.
2. 1 + 1 не всегда равно 2. Это может быть как 1.999...9, так и 2.000...1. Тем более при постоянном суммировании погрешность может оказаться слишком значительной.
А вообще дело хозяйское. Если мелочь вроде байтов не нужна, тогда юзай Double Precision на здоровье.
Вот это уж ты загнул. Откуда там значительная погрешность возьмётся? Когда мы сложим триллион значений таких разве что, но тут уже целые части теряться будут, куда там до дробей 10^-15...CyberMax писал(а):2. 1 + 1 не всегда равно 2. Это может быть как 1.999...9, так и 2.000...1. Тем более при постоянном суммировании погрешность может оказаться слишком значительной.
У нас в базе количество товара в строке хранится именно в numeric. И ничего, при любом суммировании всяких реализаций за весь период ни на копейку не уезжает
Насчет значительной погрешности - согласен, перегнул.
Извини за грубость, но ты х##ню сморозил. Стыдно не знать базовые вещи о типах. Numeric/Decimal фактически хранится в виде SmallInt/Integer/BigInt в зависимости от точности и масштаба числа. Поэтому дробные части и не слетают, потому что фактически их нет.WildSery писал(а):У нас в базе количество товара в строке хранится именно в numeric. И ничего, при любом суммировании всяких реализаций за весь период ни на копейку не уезжает
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
2 Dimitry Sibiryakov. Цитирую Х. Борри:
"Даже значения с подходящей точностью числа с плавающей запятой могут не всегда храниться в точном представлении. Такие значения, как 1.93 или даже 123, могут быть представлены в памяти как значения, очень близкие к указанному числу.". "Эффект такой: когда вы выполняете какое-либо вычисление, которое должно дать результат 123, оно может быть очень близким приближением к 123.".
Собственно, тут все сказано.
"Даже значения с подходящей точностью числа с плавающей запятой могут не всегда храниться в точном представлении. Такие значения, как 1.93 или даже 123, могут быть представлены в памяти как значения, очень близкие к указанному числу.". "Эффект такой: когда вы выполняете какое-либо вычисление, которое должно дать результат 123, оно может быть очень близким приближением к 123.".
Собственно, тут все сказано.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
При всем моем уважении к Хелен, я почти уверен что она не вдавалась глубоко в особенности хранения и обработки вещественных чисел, а просто в свое время убедилась что "вещественные числа неточны" и с тех пор говорит об этом всем остальным. В то время как могут быть нюансы... Например "неточны представления чисел с экспонентой отличной от нуля".