Подсчет среднего значения с нулевыми числами

← →
kyn66 © (2009-10-23 09:53) [0]

Сталкнулся с данной ситуацией, пытаясь установить в футоре DBGridEh подсчет среднего значения по столбцу. Вот ведь как оно получается, имеется два ряда чисел:

5 5
4 0
3 3
2 0
1 1
= =
3 1.8

Но для реальной отчетности нужны реальные данные среднего значения, без нулей. Это как-то решается? Может есть какой дополнительный параметр для компонента или ....?

← →
Медвежонок Пятачок © (2009-10-23 09:56) [1]

для реальной отчетности нужны реальные данные среднего значения

1.8 это и есть реальное среднее значение

← →
kyn66 © (2009-10-23 10:11) [2]

> 1.8 это и есть реальное среднее значение

но значения нужны без нулей. Через SQl это сделать было бы просто, но в данном случае компонент сам берет на себя работу по подсчету общих строк.

← →
Сергей М. © (2009-10-23 10:12) [3]

> Это как-то решается?

Это решается исключением ненужных значений из ряда перед расчетом

← →
Медвежонок Пятачок © (2009-10-23 10:12) [4]

ну так убери из грида строки с нулями

← →
Сергей М. © (2009-10-23 10:13) [5]

> компонент сам берет на себя работу по подсчету общих строк

Не нравится логика компонента - реализуй свою логику, в чем проблема-то ?

← →
sniknik © (2009-10-23 10:16) [6]

подозреваю, что если бы значение было null, то тогда бы не посчиталось, а 0 это вполне нормальное реальное значение. то что кто то решил, что оно для него нереально ничего не меняет в общей логике.

← →
Сергей М. © (2009-10-23 10:19) [7]

> подсчету общих строк

Каких таких "общих" ?
С кем/чем они "общие" ?

← →
kyn66 © (2009-10-23 10:19) [8]

> ну так убери из грида строки с нулями

Их нельзя убрать. Вот картинка с реальными данными http://yurec66.narod.ru/Vopros/gof.jpg . Там по суммам должны быть подсчитаны средние значения, а по кол-вам суммированные. А получается так, что замесяц движение где было, где небыло и средние значение получаются неверные...

← →
Медвежонок Пятачок © (2009-10-23 10:25) [9]

считай не гридом.
потому что грид считает по правилам арифметики.

← →
brother © (2009-10-23 10:25) [10]

я не понял, что смущает?

← →
Сергей М. © (2009-10-23 10:27) [11]

> средние значение получаются неверные

Не выдумывай.
Среднее арифметическое - оно и в Африке среднее арифметическое.

← →
brother © (2009-10-23 10:32) [12]

сам то понимаешь, чего хочешь? вопрос переформулируй

← →
kyn66 © (2009-10-23 10:39) [13]

> Среднее арифметическое - оно и в Африке среднее арифметическое.

Не, ну я согласен впринципе. Значит нужно футор убирать. Просто хотелось чтобы красиво грид смотрелся, как бы в законченном виде :)

← →
brother © (2009-10-23 10:40) [14]

имхо автор партизан... и шифрами говорит...)

← →
Сергей М. © (2009-10-23 10:49) [15]

> нужно футор убирать

Это уж тебе самому решать, убирать его или не убирать.

> я согласен впринципе

Если согласен, тогда что за ерунду ты городишь про "реальные значения" ?
те самые нули в тот самый период абсолютно реально влияют на статистику. Если ты выкинешь эти нули, то тогда ты обязан выкинуть из периода и соотв.дни, иначе коту под хвост такая статистика)

← →
kyn66 © (2009-10-23 10:50) [16]

> сам то понимаешь, чего хочешь? вопрос переформулируй

А что не понятного? Подсчитать среднее по столбцу без учета нулей

← →
brother © (2009-10-23 10:52) [17]

у тебя с математикой туго?
(5 + 3 + 1)/3 = 3

← →
Сергей М. © (2009-10-23 10:55) [18]

> Подсчитать среднее по столбцу без учета нулей

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

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

← →
brother © (2009-10-23 10:56) [19]

Сергей, твой телепатор еще работает?)

← →
kyn66 © (2009-10-23 10:57) [20]

> Если ты выкинешь эти нули, то тогда ты обязан выкинуть из
> периода и соотв.дни, иначе коту под хвост такая статистика)

В представленной картинке (http://yurec66.narod.ru/Vopros/gof.jpg) кокретно заострим внимание на графе "Реализация за месяц" . Там статистика показана не по дням, а по товару конкретно. И если реализации за месяц небыло, то зачем включать нули в общую сумму реализации по остальным позициям. Здесь есть здравый смысл. Может просто действия компонента в данном случае не совсем подходят.

← →
Сергей М. © (2009-10-23 10:57) [21]

> brother © (23.10.09 10:52) [17]

Почему туго ? Он на 5 делит, а не на 3, ибо в ряду 5 значений. И получает как и положено 1,8

← →
kyn66 © (2009-10-23 11:00) [22]

> у тебя с математикой туго?(5 + 3 + 1)/3 = 3

Это ты не мне скажи, а компоненту, чтобы нуливыкинул из столбца.

← →
brother © (2009-10-23 11:02) [23]

> чтобы нуливыкинул из столбца.

не заполняй значение

← →
Сергей М. © (2009-10-23 11:04) [24]

> Здесь есть здравый смысл

Нет тут никакого здравого смысла.

← →
kyn66 © (2009-10-23 11:25) [25]

> Нет тут никакого здравого смысла.

Тяжело объяснить , если не понятна задача. Представьте, что стоит такая задача, подсчитать среднее, без учета нулей, задействовав стандартный механизм компонента. Нужно глянуть в исходнике как там идет обработка.

← →
brother © (2009-10-23 11:31) [26]

> Тяжело объяснить , если не понятна задача.

если тебе задача не понятна, какие ТЗ ты нам предъявляешь?

← →
kyn66 © (2009-10-23 11:36) [27]

> если тебе задача не понятна, какие ТЗ ты нам предъявляешь?

Это не мне, а тебе не понятно. Сколько раз объяснять нужно? См. основной вопрос! Но для реальной отчетности нужны реальные данные среднего значения, без нулей.

← →
brother © (2009-10-23 11:39) [28]

а ты еще и не доволен? я умываю руки, тебе смотреть [6] [18]

> kyn66 © (23.10.09 11:25) [25]

Вообще-то пользователь в здравом рассудке вполне резонно должен полагать, что если в футере написано "ИТОГО", то в соответствующих колонках там фигурируют итоговые кол-ва и суммы по всей показанной гридом номенклатуре.
А ты там вместо ожидаемых итоговых количеств и сумм безо всяких на то комментариев хочешь вывести статистические расчеты типа среднеарифметических значений, да еще и никак не информируя пользователя о "нестандартной" логике этих расчетов.

> а ты еще и не доволен? я умываю руки, тебе смотреть [6]
> [18]

Да без обид, просто устал объяснять, что иногда ставятся разные задачи и все под одну логику не подведешь.

Я вот прошелся по исходнику в режиме отладки и вышел вот на эту строку http://yurec66.narod.ru/Vopros/rez.jpg . Явно понятно, что компонент подсчитывает все строки не Null. Но потом будет гемор с этими неопределенными значениями в дальнейших подсчетах. Exeption вываливать будут, было уже такое , тока уже не помню в какой ситуации, пока явно ноль не поставишь вместо пустого значения.

> Сергей М.

Если бы проблема была только в слове "ИТОГО"....

> Если бы проблема была только в слове "ИТОГО"

Действительно - если бы)

> Тяжело объяснить , если не понятна задача. Представьте,
> что стоит такая задача, подсчитать среднее, без учета нулей,
> задействовав стандартный механизм компонента. Нужно глянуть
> в исходнике как там идет обработка

Там реальное значение, а не пустые значения и механизм не только стандартный, но еще и соответствует математике.

А если там будут значения -3, тогда что, это же уже не реальное значение и оборота тоже нет, есть минусование.

АVG определен так Sum(Values)/Count(Values) и все
Все значения должный учитываться. NULL отсутствие значения.

Ура, решение найдено !!!

Немного подправил в модуле компонента DBSumLst строки относительно 0:
было
... goAvg: begin if (FDataSet.FieldByName(Item.FieldName).IsNull = False) then Inc(Item.FNotNullRecordCount); Item.FSumValueAsSum := Item.FSumValueAsSum + FDataSet.FieldByName(Item.FieldName).AsFloat; end; ...

после модернизации
goAvg: begin if (FDataSet.FieldByName(Item.FieldName).IsNull = False) AND (FDataSet.FieldByName(Item.FieldName).Value <> 0) then Inc(Item.FNotNullRecordCount); Item.FSumValueAsSum := Item.FSumValueAsSum + FDataSet.FieldByName(Item.FieldName).AsFloat; end;

И результат получился такой как требуется по задаче (хотя может это и протеворечит математической логике, не я ставлю задачи, руководство)

В итоге получились вот такие данные
http://yurec66.narod.ru/Vopros/rez2.jpg

Честно говоря это задача поставлена только сейчас, а изменятся требования? Опять перекомпилировать компонент. И не будет это наглостью менять чужой компонент? Хотя эта версия с открытыми кодами, нужно с автором переговорить.

> А если там будут значения -3, тогда что, это же уже не реальное
> значение и оборота тоже нет, есть минусование.

Да, интересно, про минусовое значение я как-то не думал...

Проще и правильней поставить на форму кнопулю, включающую/отключающую фильтрацию НД на предмет включения/исключения из avg-расчетов позиций, имеющих нуль в поле, участвующем в расчете.

Тогда и коверкать чужой компонент не придется)

> И не будет это наглостью менять чужой компонент?
это будет глупостью... т.к. с этим ты гораздо скорее словишь логическую ошибку на другом отчете, чем с испугавшим тебя null AV. потому как null вполне нормально, стандартными методами обрабатывается, и это значение, а не адрес метода/т.д..

> Проще и правильней поставить на форму кнопулю, включающую/отключающую
> фильтрацию НД на предмет включения/исключения из avg-расчетов
> позиций, имеющих нуль в поле, участвующем в расчете.Тогда
> и коверкать чужой компонент не придется)

Это самое лучшее было бы решение, только как эту кнопульку связать с компонентом? Это типа если бы у компонента было дополнительное свойство "Учитывать нулевые значения". А с временной доработкой компонента конечно не выход, я согласен. Мало ли придется переустанавливать с архивов и т.д.

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