Dimitry SibiryakovЯ смотрю автора ещё никто не спросил какого типа данные у него в очереди... И почему бы не считать этот min/max при необходимости, а не на лету?..
Я оговаривался - целочисленные.авторm_Sla ворочал запятую, а уменя все целочисленное. Необходимость такая есть. Надо просто принять это :)

Anatoly MoskovskyТут бы еще узнать зачем оно вообще надо :)Да все очень просто. Нужно продемонстрировать, что существующая методика и инструментарий для сбора, оценки м анализа параметров процесса устарели и нужно вложиться в нормальную разработку. И уж если я на коленке смог собрать более эффективную и, главное, работающую модель, то наверное следует нанять профессионалов и сделать все красиво :)

maytonУ меня почему-то в голове крутиться аналогия с расчётом
"скользящего среднего" если считать FIFO - статистической
выборкой.Не удивительно, что крутится :)авторна каждом тике еще считаются (но все тривиально):
- приращение очереди: (Chg = New - Old);
- сумма значений очереди: (Sum = Sum + Chg);
- скользящее среднее: (Avg = Sum / Siz);
- диапазон минмакс: (Dnx = Max - Min)

Dimitry Sibiryakov"Я" бывают разные. (с) Кролик.

Целочисленные значения имеют разрядность от 1 до 64 бит минимум. Какие у тебя? До
разрядности в 8 бит будет эффективным уже предложенный способ счётчиков.
Мои целочисленные - VBA-шный тип long:
F1Long (long integer) variables are stored as signed 32-bit (4-byte) numbers ranging in value from -2,147,483,648 to 2,147,483,647

Dimitry Sibiryakov,

* Ну, раз ты так считаешь...
это VBA так считает. Чем-то мои лонги не понравились...

* кто и с какой частотой использует эти min/max значения?
С частотой поступления тиков все это предварительно считаемое добро участвует в последующей математике системы принятия решения. Также, параллельно с сырыми данными, пишется статистика. Для истории и для оффлайн анализа как наблюдаемых процессов, так и поведения самой системы наблюдения за ними

У меня был один простой вопрос - уважаемые спецы по Си, как вам видится мой алгоритм и получу ли я ожидаемую (в пределах +- трамвайная остановка) скорострельность.

Спасибо всем явно или косвено подтвердивших работоспособность алгоритма и особенно тем, кто не поленился и смоделировал. Vladimir Baskakov , m_Sla - снкс. Спасибо остальным за высказанные идеи и ориентиры на будущее.

Осталось два простых вопроса. Их, к сожалению, залистали:

- как передать в длл массив значений разом вместо нескольких параметров , и

- как получить из нее так же массив значений, вместо нескольких вызовов .

Dimitry Sibiryakov,
* Гораздо интереснее мнение того, кто эти данные присылает
Уточни, плз, что имеется ввиду?

Если только это:
* Конкретнее - диапазон генерируемых значений.
то датчиками генрируется абстракщина, понятия не имею. А на выходе из API - лонги любого знака. Порядок величин - 10^5, не более. За исключением моего собственного сквозного таймштемпа, который я проставляю с точностью 100 мксек. Так что у него порядок до 10^9.

авторТо есть принятие решения осуществляется на каждое поступление новых данных, 500 раз в секунду?Я оценил сарказм. Позволь и мне?

Не поверишь - именно так. 500 раз в секунду и даже с большей частотой оператор сидит ровно на заднице и не подпрыгивает к пультам, а принимает, и принимает и снова принимает решение сидеть так же ровно и дальше . И лишь несколько раз в день он отрывает тохес от стула потому что загорается большая красная лампочка. Сказать почему она загорается? В частности потому, что 500 раз в секунду считается (среди прочего) минмакс.

maytonЯ сильно сомневаюсь [...] Ну вот ... в таком вот аспекте. n'est-ce pas?
mayton , c'est tout. В смысле - pourquoi cure l'accordeon? ;)

Ну зачем же так серьезно о метафоре, тем более анонсированной как сарказм в ответ на сарказм :)

Конечно же, мой оператор, чтобы прервать свое бездействие, реагирует не на изменение минмакса с соответствующей частотой, а лишь на лампочку. Вобщем-то, это есть в завершающей метафору фразе.

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

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

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

Dimitry SibiryakovunderCдатчиками генрируется абстракщина, понятия не имею.А ты поинтересуйся. Потому что если диапазон значений невелик и разброс - тоже, то быстрейшим способом получить экстремумы будет массив счётчиков значений. Как тебе уже сказали.Может в этом и есть сермяжная правда. Но ведь таким образом ты меня подталкиваешь к написанию собственного API, а это не есть гуд. Сырые данные с датчиков... гальванические развязки, калибровки, шумы... Ты это все серьезно?

Dimitry SibiryakovunderCЯ оценил сарказм. Позволь и мне?Не позволю. Потому что это не был сарказм. Я знаю что такое ИИ и системы принятия решений.
Если их алгоритмы должны работать в реальном времени, на каждую порцию данных, тогда - да, min/max надо считать при занесении данных в буфер. Если они работают реже чтобы не дёргать зазря исполнительные цепи из-за кратковременных выбросов - нет смысла мучить сборщика данных.
* Не позволю.
Ну, я ужЕ, сорри :)

* Я знаю что такое [...]
Ну, я про себя так не скажу. А вот очередной притчей поделюсь. Про восходящие(!) стадии становления философа:

- Я знаю, что я знаю.
- Я знаю, что мало знаю.
- Я знаю, что ничего не знаю (это уже на смертном одре).

Так вот. Ты рассматриваешь кратенько, абрисно(!) описанную мной систему лишь в удобном для твоего знания и понимания разрезе. Оговорюсь о таком, к примеру, нюансе - есть один чуткий и нежный датчик. Так вот если в его отсчетах среди минмаксов начнут преобладать минимумы с явной периодичностью, а период будет иметь тенденцию уменьшаться, то готовь его к замене, он наелся. Если же он, начинает давать хаотичные выбросы в макс, то надо проверить его эл.цепь или же правильность установки. И таких примеров полно. Ты мне дашь гарантию, что заниженная частота опросов его минмаксов не стушует картину его тенденции к выходу? Или вообще не снивелирует ее? Йенг даешь на пятаки?

Я не могу понять, почему нельзя просто принять на веру мое "надо"? Даже если это просто мой каприз. Даже, если это просто дурость. Помогите разобраться с этим гребаным Си, и не учите меня жить ;)

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