Комментарии 213
Мне кажется это тот случай, когда можно использовать генетическое программирование.
У вас есть некий набор параметров, которые должны вычисляться относительно друг друга с разными коэффициентами, + сама формула неизвестно как должна выглядеть.
Но есть точное условие выявления правильной формулы — она должна на длительном прогоне, вне зависимости от стартовых значений, выдавать положительный баланс, и чем выше прибыль тем лучше.
Таким образом, если написать программу, которая будет переставлять стартовые параметры и менять формулы, прогонять её на разных данных и считать итоговый коэффициент успешности формулы, то за несколько тысяч(сотен тысяч, в зависимости от теоретического количества комбинаций) итераций можно найти самый удачный вариант формулы.
У вас есть некий набор параметров, которые должны вычисляться относительно друг друга с разными коэффициентами, + сама формула неизвестно как должна выглядеть.
Но есть точное условие выявления правильной формулы — она должна на длительном прогоне, вне зависимости от стартовых значений, выдавать положительный баланс, и чем выше прибыль тем лучше.
Таким образом, если написать программу, которая будет переставлять стартовые параметры и менять формулы, прогонять её на разных данных и считать итоговый коэффициент успешности формулы, то за несколько тысяч(сотен тысяч, в зависимости от теоретического количества комбинаций) итераций можно найти самый удачный вариант формулы.
Спасибо за совет. В статье я предполагал, что задача в стиле книг бородатых 50-х годов и интересно прежде всего концептуальное, а не вычислительное решение, с исследованием асимптотик.
ввиду сделанных оговорок, Мужик может и не продать корову, если их у него мало, а шанс встретить клиента побогаче достаточно велик
противоречит
любому, подошедшему к Мужику покупателю из k -го класса, он продает любую из имеющихся у него коров с наценкой xk-тое рублей
Ну и заодно:
появление покупателя каждого класса описывается пуассоновским процессом с неким, характерным для этого класса нагрузочным параметром lk-тое
Можете для тех, кто не в теме, рассказать о характеристиках этого процесса, а именно:
- по какой формуле рассчитывается вероятность появления покупателя того или иного класса в каждой момент времени t?
- может ли в момент t появиться одновременно два покупателя разных классов (и как тогда осуществляется продажа)?
1) Да есть некоторая неточность языка. Считается, что Мужик всегда способен продать, если захочет.
2)Вы правы, забыл уточнить: независимые пуассоновские процессы с непрерывным временем(определение можно посмотреть почти в любой книге по теории вероятностей или математической энциклопедии)
3)Ввиду 2) появление когда либо сразу двух покупателей — событие нулевой вероятности
2)Вы правы, забыл уточнить: независимые пуассоновские процессы с непрерывным временем(определение можно посмотреть почти в любой книге по теории вероятностей или математической энциклопедии)
3)Ввиду 2) появление когда либо сразу двух покупателей — событие нулевой вероятности
События все независимы, совместны но некоторые зависимы (и наверное даже — вероятностная зависимость есть и цепочках из n событий) а другие — нет.
Надо понять, какое событие случается в модели чаще всего и тогда можно определится как действовать/решать — так как это событие задаёт поведение всей системы.
Ввиду 2) появление когда либо сразу двух покупателей — событие нулевой вероятности
Это почему?
Потому, что появление покупателя, решение о продаже и сама продажа (или отказ) мгновенны. Время непрерывно и вероятность любого события, из рассматриваемых в задаче, за время, стремящееся к нулю, тоже стремится к нулю. Это значит, что одновременно два покупателя не появятся исходя из самой природы вещей. Всегда кто-то из низ был раньше и всегда между ними ненулевое время.
Вернее как… вероятность того, что между приходами покупателей пройдёт нулевое время — тоже нулевая.
Вернее как… вероятность того, что между приходами покупателей пройдёт нулевое время — тоже нулевая.
У вас несколько независимых друг от друга по условию Пуассоновских потоков. Вероятность появления покупателей в один и тот же момент времени ненулевая по определению.
Какая разница? Вероятность случайно дважды попасть в одну вещественную математическую точку строго нулевая. Не важно к каким Пуассоновским или не пуассоновским процессам относятся эти величины. Если угодно, два вещественных случайных числа не равны с вероятностью строго 1.
Это с какого перепугу?
Интервал — это сумма моментов времени.
Именно так. Я определяю момент как математическую точку на оси времени. Это никак не интервал. Если коллега считает моментом некий квант машинного времени, который по определению интервал, то нет смысла говорить об идеальном пуассоновском процессе и его нужно квантифицировать.
Короче, похоже, вы правильно указали на рассогласования, просто немного не очевидно выразились. Однако я неоднократно и достаточно явно говорил, что имею в виду под моментом, а retain не говорил, что считает момент интервалом. То, что интервал — это сумма моментов в интегральном смысле верно в любом случае.
Короче, похоже, вы правильно указали на рассогласования, просто немного не очевидно выразились. Однако я неоднократно и достаточно явно говорил, что имею в виду под моментом, а retain не говорил, что считает момент интервалом. То, что интервал — это сумма моментов в интегральном смысле верно в любом случае.
Интервал — это сумма моментов времени.А не разница ли?
Вот лично я ничего не путаю, а использую строго по назначению.
Любое событие происходит мгновенно в момент времени, а пуассоновский процесс определяет вероятность возникновения события на интервале времени. В интервале (любом вещественном диапазоне) бесконечное количество моментов (вещественных точек).
Любое событие происходит мгновенно в момент времени, а пуассоновский процесс определяет вероятность возникновения события на интервале времени. В интервале (любом вещественном диапазоне) бесконечное количество моментов (вещественных точек).
Поясню, в пуассоновском потоке вероятность появления следующего события через время t рассчитывается как P(t) = lambda * pow(e, -lambda*t). Возьмем два потока, с интенсивностями lambda1 и lambda2, пусть t = const. Тогда вероятности появления события в обоих потоках через время t P1 = lambda1 * pow(e, -lambda1 * t) и P2= lambda2 * pow(e, -lambda2 * t). Общая вероятность того, что в обоих потоках придут события через одно и то же время P1 * P2 = lambda1 * pow(e, -lambda1 * t) * lambda2 * pow(e, -lambda2 * t) = lambda1 * lambda2 * pow(e, -(labmda1 + lambda2) * t). Эта вероятность ненулевая при любых положительных интенсивностях. Другой вопрос, что в рамках условия, это все не сильно важно, потому что время обслуживания клиента равно 0. А вот в реальной жизни придется учитывать возможность появления очередей.
в пуассоновском потоке вероятность появления следующего события через время t
Не «через», а «в течение». Разве нет? Вероятность появления события строго «через» время t по определению нулевая. Потому что dt->0.
Нет, почитайте матчасть, в том числе про пределы. Ваша ошибка в том, что вы считаете вероятность попадания в заданную математическую точку нулевой (а значит нулевой в любую точку, а значит вероятность попадания в отрезок, который является суммой математических точек — тоже нулевой… Бред.). Она конечно очень мала, но совсем не равна нулю.
http://sernam.ru/book_tp.php?id=114 — начиная со слов «Важной характеристикой потока является закон распределения длины промежутка между соседними событиями...»
http://sernam.ru/book_tp.php?id=114 — начиная со слов «Важной характеристикой потока является закон распределения длины промежутка между соседними событиями...»
Не передергивайте. Я такого не говорил. А вот эти ваши рассуждения:
ошибочны вот в этой части:
Нулевая вероятность попадания в конкретную точку. А в любую на заданном отрезке уже не нулевая.
Я, конечно, могу ошибаться, но пока что явные логические нестыковки именно в ваших рассуждениях. Готов спорить.
Если вас смущает разница между «нулевая» и «стремящаяся к нулю при dt->0». То готов согласиться.
Ваша ошибка в том, что вы считаете вероятность попадания в заданную математическую точку нулевой (а значит нулевой в любую точку, а значит вероятность попадания в отрезок, который является суммой математических точек — тоже нулевой… Бред.)
ошибочны вот в этой части:
а значит нулевой в любую точку, а значит вероятность попадания в отрезок, который является суммой математических точек — тоже нулевой… Бред.
Нулевая вероятность попадания в конкретную точку. А в любую на заданном отрезке уже не нулевая.
Я, конечно, могу ошибаться, но пока что явные логические нестыковки именно в ваших рассуждениях. Готов спорить.
Если вас смущает разница между «нулевая» и «стремящаяся к нулю при dt->0». То готов согласиться.
Именно эта разница меня сильно и смущает. Между «нулевая» и «стремящаяся к нулю» есть огромная разница, которая проявляется, например, при попытке эти вероятности сложить. И, например, если пуассоновских потоков МНОГО, то вероятность о которой мы говорим становится вполне заметной.
Эта вероятность становится заметной только в случае, когда пуассоновских процессов БЕСКОНЕЧНО МНОГО. И то я бы еще подумал над этим. Бесконечности бывают разных порядков.
Подытожу. Математическая точка — это не интервал. Вероятность попадания в конкретную математическую точку строго нулевая, а вот вероятность попадания в отрезок стремящийся по длине к нулю уже не нулевая, а стремящаяся к нулю.
Подытожу. Математическая точка — это не интервал. Вероятность попадания в конкретную математическую точку строго нулевая, а вот вероятность попадания в отрезок стремящийся по длине к нулю уже не нулевая, а стремящаяся к нулю.
Хорошо, соглашусь. Только остается вопрос — почему вы считаете событие нульмерной математической точкой?
UPD. В рамках этой задачи. Чем отличается событие от процесса в физических моделях я знаю.
UPD. В рамках этой задачи. Чем отличается событие от процесса в физических моделях я знаю.
По определению.
Если мы оперируем пуассоновскими определениями, то и события надо рассматривать в математическом смысле.
К тому же по условию задачи длительность обработки события не обсуждалась, посему имеет смысл считать его нулевым, как математическую абстракцию.
Если мы оперируем пуассоновскими определениями, то и события надо рассматривать в математическом смысле.
К тому же по условию задачи длительность обработки события не обсуждалась, посему имеет смысл считать его нулевым, как математическую абстракцию.
Ок. Действительно, существует абстрактное понятие элементарного события (https://en.wikipedia.org/wiki/Elementary_event), вероятность которого в непрерывном пространстве всегда равна нулю, из чего в определениях делается вывод, что в непрерывном пространстве имеют вероятность только НЕэлементарные события (а события в пуассоновском потоке, очевидно, вероятность имеют).
И, действительно, определение пуассоновского процесса в русской википедии содержит «Свойство ординарности: вероятностью наступления за элементарный промежуток времени более одного события можно пренебречь по сравнению с вероятностью наступления за этот промежуток не более одного события», с чем я спорить не буду.
Определение свойства из другого источника: Поток событий называется ординарным, если вероятность появления двух или более событий в течении элементарного интервала времени Δt есть величина бесконечно малая по сравнению с вероятностью появления одного события на этом интервале.
Про нулевую вероятность не нашел ничего.
Вот только нигде я не нашел определения того, что пуассоновский поток оперирует именно элементарными событиями. Наоборот, везде рассматривают ТОЛЬКО события попадания в некоторый интервал (тут, например, довольно подробно — https://en.wikipedia.org/wiki/Poisson_point_process).
И, действительно, определение пуассоновского процесса в русской википедии содержит «Свойство ординарности: вероятностью наступления за элементарный промежуток времени более одного события можно пренебречь по сравнению с вероятностью наступления за этот промежуток не более одного события», с чем я спорить не буду.
Определение свойства из другого источника: Поток событий называется ординарным, если вероятность появления двух или более событий в течении элементарного интервала времени Δt есть величина бесконечно малая по сравнению с вероятностью появления одного события на этом интервале.
Про нулевую вероятность не нашел ничего.
Вот только нигде я не нашел определения того, что пуассоновский поток оперирует именно элементарными событиями. Наоборот, везде рассматривают ТОЛЬКО события попадания в некоторый интервал (тут, например, довольно подробно — https://en.wikipedia.org/wiki/Poisson_point_process).
Я так понимаю сути дела наш терминологический спор не меняет. Зачем захламлять тред несущественным гиковским буквоедством? Давайте прекратим.
По существу, как я понял мы сошлись. Тем более в классическом паттерне технической реализации подобных систем с «одновременным» приходом покупателей проблем нет. Если таймштампы у них оказались равны, то обрабатываем их по мере поступления запросов. Надо сильно «постараться», чтобы это стало технической проблемой.
По существу, как я понял мы сошлись. Тем более в классическом паттерне технической реализации подобных систем с «одновременным» приходом покупателей проблем нет. Если таймштампы у них оказались равны, то обрабатываем их по мере поступления запросов. Надо сильно «постараться», чтобы это стало технической проблемой.
Каждая заявка влияет на стейт нашего продавца, а значит порядок обработки все-таки важен.
Более того, в реальных задачах на operations research есть процесс обработки заявки имеющий конкретную длину и стоимость, а сама заявка — тайм-аут, и стратегия разгребания очереди может очень сильно повлиять на финансовое состояние продавца.
Но да, давайте прекратим.
Более того, в реальных задачах на operations research есть процесс обработки заявки имеющий конкретную длину и стоимость, а сама заявка — тайм-аут, и стратегия разгребания очереди может очень сильно повлиять на финансовое состояние продавца.
Но да, давайте прекратим.
P.S Вероятность попадания в конкретную точку равна 0
Важно, что она равна не 0, а бесконечно мала. Первый раз мы ведь в эту точку попали, значит вероятность была ненулевая)
Вероятность — это число. Действительное число не может быть бесконечно малым. Бесконечно малыми бывают только последовательности или функции.
Правильнее — не «очень мала», конечно, а бесконечно мала.
В итоге — по определению непрерывного пуассоновского потока. Событие ненулевой вероятности, но по определению мы этой вероятностью пренебрегаем и считаем, что сумма пуассоновских потоков — это тоже пуассоновский поток.
Это уже есть в задаче — мужик продаёт коров с наценкой, а этот термин подразумевает ненулевую прибавку к ненулевой денежной сумме себестоимиости (т. е. это все равно что сказать, что у всех классов всегда есть минимальная или большая платежеспособность, равная сумме себестоимости и минимальной наценки).
Если коров скопилось очень много, то за их сбыт Мужик сам даст денег, потому что это выгоднее чем их понапрасну кормить.
Поскольку процесс пуассоновский, предсказать появление следующего клиента на основе данных о предыдущих клиентах не получается и делать что-либо «в ожидании богатого клиента» нельзя.
Можно. (делать, а не предсказывать)
Пример: есть 1 корова, пополнение появится через большое время t.
По оценке, самый выгодный тип покупателей придёт раньше чем t c большой вероятностью (Например, 0.9). В таком случае нет смысла прям сейчас продавать корову дёшево.
за их сбыт Мужик сам даст денег
Т. е. на рынке появляются ещё и клоны Мужика — клиенты, которым он дал корову и пообещал дать денег за её сбыт другому клиенту?
Боюсь, оба решения вкладывают в вероятность совсем не тот смысл, который принят для этого понятия в математике. Вы никогда не знаете, сколько придет покупателей в ближайший час и каких: у вас есть лишь вероятности каждого их набора, которые оправдываются в среднем и то лишь по вероятности. Пусть, например, класс покупателей только один, их количество за час имеет распределение Пуассона с математическим ожиданием 1. Если вы собираетесь закупать раз в час корову, то учтите, что более чем в четверти случаев по истечению часа не сможете продать купленную в прошлый раз, и с довольно большой вероятностью, если на начало очередного часа у вас будет только одна корова, то по крайней мере один клиент будет потерян.
Тогда нужно уравнять вероятности получения сопоставимых дохода от продажи коровы и потери от потери клиентов и расходов на содержание у мужика. Другое дело — избавится от потерь совсем и получить всю возможную прибыль — не получится в принципе.
Достаточно словесных рассуждений.
Принимать эмпирический "+ некоторый запас сверх рассчетов." нет смысла так как для этого и предназначен вероятностный расчёт количества коров, и если расчёт вероятности не действует — то его надо править, убирая логический костыль.
Реальные барышники на реальных рынках скота (например — в дореволюционной России, на скотных рынках Аргентины — страна, которая в начале XX века считалась одной из самых процветающих в мире) статистику продаж мусоленным карандашом по обёрточной бумаге наверное вели, а вот обработать её, чтобы избавиться запаса сверх расчётов, не могли — и для этого они не должны были нанимать академика Крылова, достаточно было сообразить заплатить за эту работу бедному учителю математики или студенту тех времён.
Как мне представляется, задача достаточно сложная, ее решение с обоснованием, если оно где-то опубликовано,- небольшая глава в книге по алгоритмам. Не стоит торопится с ответом)
Глава 7? (задача напомнила задачу про ковры скомбинированную с потоками в сетях)
Боюсь, сильно мимо…
Я еще раз обдумал Ваше предложение и должен признать, что приближенное решение можно свести к задаче сильно напоминающей поиск максимального по мощности циклического потока в графе, однако на этот поток, в случае чистой стратегии (детерминированной), накладываются ограничения неделимости в узлах, поэтому, как Вы понимаете, вся простота алгоритмов теряется. Если применять смешанные стратегии (зависящие от случая), решение приближенной задачи действительно можно найти указанным способом, однако есть две проблемы:
а) нужно доказать, что максимум достигается на чистой стратегии (почти очевидно)
б) вычислительная сложность растет по экспоненте от величины обратной к величине шага дискретизации.
а) нужно доказать, что максимум достигается на чистой стратегии (почти очевидно)
б) вычислительная сложность растет по экспоненте от величины обратной к величине шага дискретизации.
б) можно отбросить: для поиска циклического потока максимальной стоимости есть алгоритм куда проще с вычислительной точки зрения, чем линейное программирования. Еще раз спасибо за идею.
Всё это, конечно, контринтуитивно. Поэтому, на уровне гипотез.
Если мужик не продает коров совсем, то прибыль -0, но и убытков 0.
Таким образом, может возникнуть ситуация (например при низкой интенсивности потока покупателей), что стратегия минимизации убытков — не торговать.
Пусть мужик держит на продажу одну корову. Тогда можно построить что-то типа протокола разборчивой невесты.
Дальше пока не придумывается.
Если мужик не продает коров совсем, то прибыль -0, но и убытков 0.
Таким образом, может возникнуть ситуация (например при низкой интенсивности потока покупателей), что стратегия минимизации убытков — не торговать.
Пусть мужик держит на продажу одну корову. Тогда можно построить что-то типа протокола разборчивой невесты.
Дальше пока не придумывается.
при почти бесконечном начальном капитале
Зачем Мужику при почти бесконечном капитале продавать коров?)
Если все условия можно задать в виде линейных неравенств, можно попробовать применить симплекс-метод.
В универе похожее решали на «Исследовании операций» (Мат. программирование)
Забавная задачка. Сходу напрашивается ряд «решений», а по зрелому размышлению проявляются интересные нюансы, упрощения и оптимизации.
Первое, что нам нужно для себя решить — это оптимальный размер буфера коров, который мы будем держать в резерве (S*). Очевидно, что оно будет зависеть от всех параметров этой задачи. Давайте отложим нахождение этой величины.
Итак, у нас для каждого случая (прихода покупателя; пронумеруем их по i) есть текущий запас коров S_i. Нам нужно:
1. решить, продавать корову этому покупателю или нет;
2. решить, сколько заказать коров из деревни (может быть 0, заказ-то бесплатный и, как я понял из задания, асинхронный? Поправьте меня, автор, если ошибаюсь).
По поводу второго пункта следует заметить, что акт заказа коров, строго говоря, не должен быть привязан к событиям прихода покупателей, то есть не обязательно должен происходить по факту прихода кого-то из них или по факту продажи. Похоже это тоже будет пуассоновский поток событий, параметр которого будет вычисляться из вероятностей потока покупателей. Если вероятности прихода покупателей рассчитаны (даны) верно, то процесс стационарный и, возможно, не придется даже динамически управлять параметром потока заказов. Вернее эффективнее будет не управлять.
Итак. Декомпозиция выявила три вопроса:
1. Каков оптимальный размер буфера (S*)?
2. Продавать ли корову i-му покупателю?
3. С каким интервалом дозаказывать коров?
Забавно, что в случае идеального пуассоновского процесса нам, скорее всего, можно вообще в самом начале определить какие классы обслуживать, а какие нет. И в начале же определить четко интервал времени дозаказа коровы. Очевидно, что при бесплатном асинхронном заказе нет смысла заказывать больше одной за раз.
Ок. С формулами я сейчас уже не осилю, да и тестовый стенд писать уже лень, но предположу, что мы просто откинем некоторые классы покупателей по рентабельности резервирования для них коровы с учетом среднего времени их появления. Остальным продаём корову из буфера, размер которого будет зависеть от вероятного количества обслуживаемых клиентов за время T.
Возможно следует еще оценить вероятностные характеристики убытка при потере клиента и как-то сравнить их с вероятностными характеристиками убытка от over-резервирования. Но это заметно усложнит формулу расчета глубины резерва.
Резюме. Задача похоже стационарна и не требует онлайн-управления процессом.
Первое, что нам нужно для себя решить — это оптимальный размер буфера коров, который мы будем держать в резерве (S*). Очевидно, что оно будет зависеть от всех параметров этой задачи. Давайте отложим нахождение этой величины.
Итак, у нас для каждого случая (прихода покупателя; пронумеруем их по i) есть текущий запас коров S_i. Нам нужно:
1. решить, продавать корову этому покупателю или нет;
2. решить, сколько заказать коров из деревни (может быть 0, заказ-то бесплатный и, как я понял из задания, асинхронный? Поправьте меня, автор, если ошибаюсь).
По поводу второго пункта следует заметить, что акт заказа коров, строго говоря, не должен быть привязан к событиям прихода покупателей, то есть не обязательно должен происходить по факту прихода кого-то из них или по факту продажи. Похоже это тоже будет пуассоновский поток событий, параметр которого будет вычисляться из вероятностей потока покупателей. Если вероятности прихода покупателей рассчитаны (даны) верно, то процесс стационарный и, возможно, не придется даже динамически управлять параметром потока заказов. Вернее эффективнее будет не управлять.
Итак. Декомпозиция выявила три вопроса:
1. Каков оптимальный размер буфера (S*)?
2. Продавать ли корову i-му покупателю?
3. С каким интервалом дозаказывать коров?
Забавно, что в случае идеального пуассоновского процесса нам, скорее всего, можно вообще в самом начале определить какие классы обслуживать, а какие нет. И в начале же определить четко интервал времени дозаказа коровы. Очевидно, что при бесплатном асинхронном заказе нет смысла заказывать больше одной за раз.
Ок. С формулами я сейчас уже не осилю, да и тестовый стенд писать уже лень, но предположу, что мы просто откинем некоторые классы покупателей по рентабельности резервирования для них коровы с учетом среднего времени их появления. Остальным продаём корову из буфера, размер которого будет зависеть от вероятного количества обслуживаемых клиентов за время T.
Возможно следует еще оценить вероятностные характеристики убытка при потере клиента и как-то сравнить их с вероятностными характеристиками убытка от over-резервирования. Но это заметно усложнит формулу расчета глубины резерва.
Резюме. Задача похоже стационарна и не требует онлайн-управления процессом.
Мне вот тоже пришла в голову идея, что можно просто посчитать, сколько покупателей какого типа к нам (в среднем, но в долгосрочной перспективе только среднее и интересно) приходит за некий (произвольно взятый) интервал времени Q. Столько коров нам и нужно (X). Дальше заказываем по одной корове в Q/X (а начальный резерв берем как T/(Q/X)).
Многие из ваших замечаний разумны, например, как вы правильно заметили, нужно учитывать, какие коровы уже заказаны и что они придут в будущем. Если же ваши ожидания насчет потока клиентов не оправдываются, действительно не стоит заказывать лишних коров, и поэтому правдоподобно, что заказ, если происходит, то только в момент продажи. Однако процесс требует постоянного управления и не сводится к определению размера буфера, поскольку оптимальность зависит не только от количества коров в вашем распоряжении сейчас но и от именно функции «уже заказанное пополнение»(«время»). С выбраковкой классов тоже не стоит спешить: если все шло как по часам, а затем случайно целый период T не было продаж, то возможно от лишних коров стоит избавится при первой возможности.
если все шло как по часам, а затем случайно целый период T не было продаж, то возможно от лишних коров стоит избавится при первой возможности.
А если 10 раз подряд выпало красное, то нужно ставить на черное?
Согласен с предыдущими ораторами. В силу случайности и полной непредсказуемости все, что происходило до данного момента времени абсолютно неважно. У нас есть только сейчас и будущее. Весь вопрос только в размере буфера. Если буфер забольшой, что приходится продавать корову — значит неправильно посчитан буфер и корову продавать не нужно было.
из-за отсутствия продаж на складе скопилось количество коров выше оптимального.
оптимальное количество не зависит от прошлых продаж/непродаж. Если текущее количество выше/ниже, то его надо вернуть до оптимального.
При любом (!) буфере будут ситуации, когда коров слишком много, и ситуации, когда продавать нечего.
Чувствуете в чем подвох? Если размер буфера больше оптимального, издержки на его содержание растут быстрее, чем прибыль от не упущенных (за счет этого увеличения буфера) клиентов. Если размер буфера меньше оптимального, издержки по статье недополученной прибыли из-за упущенных (из-за этого уменьшения буфера) хороших клиентов будут раст быстрее чем выигрыш (экономия) на прокорме буфера.
Предполагается наличие седловой точки оптимума размера буфера.
Оптимальный размер буфера мы можем в среднем держать за счет установки скорости заказа коров, равной средней скорости сбыта их рентабельным клиентам. Если эта средняя скорость сбыта известна наверняка и точно, то мы всегда будем блуждать около этой точки туда-сюда. Экстренно динамически продавая лишних коров сверх оптимума нерентабельным клиентам вы делаете подстройку только с одной стороны.
Во-первых, почему вы тогда не предлагаете явно дозаказывать динамически коров в ускоренном режиме при перерасходе (то есть когда буфер меньшеоптимального)?
Во-вторых, зачем вообще эта дополнительная инертная обратная связь нужна, когда по условию задачи четко известна средняя скорость сбыта коров? Дёргая динамически буфер туда-сюда, то есть заказывая коров из деревни с непостоянной скоростью и сбывая их иногда нерентабельным клиентам вы лишь уменьшаете добротность системы внося еще один маятник со всеми вытекающими. У нас нет «тренья» в системе и, может быть ваш такой микроменеджмент и не приведёт в среднем ни к профиту ни к издержкам, но зачем усложнять алгоритм?
Полагаю это обосновано было бы только для безопасности на случай внезапного и незадокументированного изменения параметров потока покупателей. А об этом в задаче речи не шло. Потому я и сказал в треде. что на данном этапе хорошо бы уже спуститься в реальность, а не надувать сферического коня в безвоздушном пространстве.
наоборот: если в какой-то момент мы накопили избыточный запас коров, для нас любой клиент внезапно становится рентабельным.
Тогда где остановиться? Характер закона распределения не позволяет нам рассчитывать на 100% от пропуска клиента при любом размере буфера. Да, в какой-то момент вероятность пропуска клиента становится столь малой, что можно пренебречь, но есть же и фиксированная цена заказа коровы a, а условие допускает отрицательную маржинальность. Это делает «любого клиента» ой как нерентабельным.
А если 10 раз подряд выпало красное, то нужно ставить на черное?
Не совсем так.
Совсем не так!
Нет. При любом (!) буфере будут ситуации, когда коров слишком много, и ситуации, когда продавать нечего.
Нет. Если буфер равен 0 или 1 — коров не будет слишком много. Продавать коров нет смысла. Если вы дошли до ситуации, когда продаете корову по дешевке — значит не нужно было ее покупать.
Просто в этом месте становится понятно, что вы не очень понимаете теорию вероятностей. Если вероятность, что клиент придет в ближайшую минуту — 0.001%, то от того, что клиент не приходил 1000 минут вероятность не изменится.
Вы мыслите на классическом обывательском уровне — «редкое событие произошло, значит в ближайшее время вероятность его возникновения понижена».
Понимаю, что для вас это контринтуитивно, но, увы, это не так.
Вы мыслите на классическом обывательском уровне — «редкое событие произошло, значит в ближайшее время вероятность его возникновения понижена».
Понимаю, что для вас это контринтуитивно, но, увы, это не так.
Ну да, конечно, если покупателей, например, 0, то 1 корова уже слишком много)
Я говорил об этом:
Я приведу пример. В рулетке вероятность выпадения числа 13 — 1/37. Если выпало 13 — необходимо ли пропустить пару следующих бросков, чтобы приблизиться к следующим 13?
Вот так и тут. От того, что клиент пришел абсолютно нету никакого резона отступать на какой-то промежуток времени — это не дает выгоды, а только затягивает игру.
Я говорил об этом:
в таких условиях можно было бы устроить её доставку ближе к середине среднего интервала между двумя клиентами
Я приведу пример. В рулетке вероятность выпадения числа 13 — 1/37. Если выпало 13 — необходимо ли пропустить пару следующих бросков, чтобы приблизиться к следующим 13?
Вот так и тут. От того, что клиент пришел абсолютно нету никакого резона отступать на какой-то промежуток времени — это не дает выгоды, а только затягивает игру.
Ну я так понимаю, вероятность 1/37 говорит о том, что после 37 бросков вероятность выпадения 13 хотя бы 1 раз близка к 1. Но ок, тут может и не так.
А вот распределение Пуассона, насколько я понял, зависит от времени, то есть за определенное время происходит определенное число событий. Получается, чем больше мы ждем, тем число событий ближе к этому определенному. А как только событие произошло, вероятность его повторения в следующий момент времени маленькая, иначе это число событий было бы больше.
Как с автобусом — чем дольше ждешь, тем больше вероятность, что придет нужный номер, и тем меньше причин ехать на другом. И после того, как он пришел, маловероятно, что через полминуты появится еще один такой же.
Вот как раз сравнение с автобусом — ошибочно. Приход автобуса — процесс не случайный, ведь они ходят по графику. Если бы автобусы запускали подбрасыванием монетки — ага, решка, значит 15-й, а орел — 21-й, то ваш пример был бы аналогичен, но снова ошибочен.
Вероятность решки на монетке 1/2, следует ли из этого, что при двух бросках вероятность выбросить решку близка к 1?
Нет, нет и еще раз нет. Предыдущее событие НИКАК не влияет на следующее. Серьезно. Возьмите монетку. Киньте ее. А потом считайте, сколько раз выпало то же, что и в предыдущий, а сколько раз иной вариант. И вы увидите, что в 50% случаев выпадает тот же вариант, а в 50% случаев вариант меняется. Потому что неважно, что выпало перед этим. Если вы кинули 5 раз подряд орла — шестой раз ровно так же у орла 50% вероятности, как и у решки. Оно не уменьшается от того, что Пуассон вывел свое распределение.
Смотрите. Допустим мы монетку кидаем дважды. Значит у нас есть такие варианты:
(О-О), (О-Р), (Р-О), (Р-Р). Вероятность того, что выпадет два орла всего 25%, но если перед этим уже выпал орел вероятность того, что снова выпадет орел — 50%, понимаете?
Ну я так понимаю, вероятность 1/37 говорит о том, что после 37 бросков вероятность выпадения 13 хотя бы 1 раз близка к 1
Вероятность решки на монетке 1/2, следует ли из этого, что при двух бросках вероятность выбросить решку близка к 1?
А как только событие произошло, вероятность его повторения в следующий момент времени маленькая, иначе это число событий было бы больше.
Нет, нет и еще раз нет. Предыдущее событие НИКАК не влияет на следующее. Серьезно. Возьмите монетку. Киньте ее. А потом считайте, сколько раз выпало то же, что и в предыдущий, а сколько раз иной вариант. И вы увидите, что в 50% случаев выпадает тот же вариант, а в 50% случаев вариант меняется. Потому что неважно, что выпало перед этим. Если вы кинули 5 раз подряд орла — шестой раз ровно так же у орла 50% вероятности, как и у решки. Оно не уменьшается от того, что Пуассон вывел свое распределение.
Смотрите. Допустим мы монетку кидаем дважды. Значит у нас есть такие варианты:
(О-О), (О-Р), (Р-О), (Р-Р). Вероятность того, что выпадет два орла всего 25%, но если перед этим уже выпал орел вероятность того, что снова выпадет орел — 50%, понимаете?
Да, с монеткой вы правы. Ну я поэтому и сделал оговорку, что возможно это не так. Просто, как мне кажется, здесь 2 принципиально разные ситуации. В случае с рулеткой и монеткой вероятность зависит от количества вариантов, в случае пуассоновских процессов вероятность рассчитывается по отрезкам времени. Если мы знаем, что за час должно прийти 2 покупателя такого типа, то если за полчаса никто не пришел, то в следующие полчаса вероятность появления выше. А если и за час не пришел, то в следующий час можно ожидать 4. Иначе характеристика была бы не "2 покупателя в час", а "1 покупатель в час". А если стабильно никто не приходит, уже надо говорить о том, что характеристика изменилась.
С автобусами аналогично. Автобусы ходят по графику, но в пределах одной остановки появление следующего номера рассматривается как случайная величина. Вернее, обладающая свойствами случайных. Потому что есть светофоры, пробки, поломки, а также другие автобусы, у которых свое расписание и набор остановок. А вот расписание как раз и означает, что за час на эту остановку должно прийти 3 автобуса с этим номером.
Нет, вам неправильно кажется.
Начнем с автобусов. На них не работает распределение Пуассона. Потому что оно работает только на независимых событиях. А приход автобусов очень даже зависим. Да, есть случайные факторы, которые смещают время прихода в одну или другую сторону, но это не связано с распределением Пуассона.
Дальше.
Нет, не выше. Вы думаете, что за углом стоит Пуассон и считает, сколько именно покупателей к нам заходит и если их меньше чем нужно, то срочно посылает своих агентов? А если пришли 8 вместо 2? То теперь шестеро умрут не выйдя из магазина?
Распределение Пуассона говорит приблизительно следующее. В среднем у нас десять покупателей в час. Следовательно:
11% вероятности, что у нас будет 10 покупателей
10% вероятности, что у нас будет 9 покупателей
9% вероятности, что у нас в ближайший час будет 11 покупателей
и даже 1% вероятности, что у нас будет 20 покупателей за ближайший час.
Все. Больше распределение Пуассона ни о чем не говорит. Только о том с какой вероятностью какой час выпадет. Так вот. Есть 5% вероятности, что придет 5 покупателей и 5% вероятности, что придет 15 покупателей. Если в первые полчаса пришло только двое — может мы попали в неудачные 5%. А если в первые 15 минут пришло 10, то может попали в тот удачный 1% и потом будет еще десять.
Самое главное, что предыдущие события НИКАК не влияют на следующие. То есть пусть у нас предыдущих два часа был полный завал или пустой магазин следующий час с сего момента (и с любого момента) имеет ровно тот же график распределения Пуассона.
Конечно, только в теории и потому с магазином контринтуитивно. Ведь вы ведь знаете — в обед в магазине обуви никого нет, а под вечер просто завал, вот же доказательство. Но нет, это влияние не распределения, а просто рабочего графика среднего класса
Начнем с автобусов. На них не работает распределение Пуассона. Потому что оно работает только на независимых событиях. А приход автобусов очень даже зависим. Да, есть случайные факторы, которые смещают время прихода в одну или другую сторону, но это не связано с распределением Пуассона.
Дальше.
Если мы знаем, что за час должно прийти 2 покупателя такого типа, то если за полчаса никто не пришел, то в следующие полчаса вероятность появления выше
Нет, не выше. Вы думаете, что за углом стоит Пуассон и считает, сколько именно покупателей к нам заходит и если их меньше чем нужно, то срочно посылает своих агентов? А если пришли 8 вместо 2? То теперь шестеро умрут не выйдя из магазина?
Распределение Пуассона говорит приблизительно следующее. В среднем у нас десять покупателей в час. Следовательно:
11% вероятности, что у нас будет 10 покупателей
10% вероятности, что у нас будет 9 покупателей
9% вероятности, что у нас в ближайший час будет 11 покупателей
и даже 1% вероятности, что у нас будет 20 покупателей за ближайший час.
Все. Больше распределение Пуассона ни о чем не говорит. Только о том с какой вероятностью какой час выпадет. Так вот. Есть 5% вероятности, что придет 5 покупателей и 5% вероятности, что придет 15 покупателей. Если в первые полчаса пришло только двое — может мы попали в неудачные 5%. А если в первые 15 минут пришло 10, то может попали в тот удачный 1% и потом будет еще десять.
Самое главное, что предыдущие события НИКАК не влияют на следующие. То есть пусть у нас предыдущих два часа был полный завал или пустой магазин следующий час с сего момента (и с любого момента) имеет ровно тот же график распределения Пуассона.
Конечно, только в теории и потому с магазином контринтуитивно. Ведь вы ведь знаете — в обед в магазине обуви никого нет, а под вечер просто завал, вот же доказательство. Но нет, это влияние не распределения, а просто рабочего графика среднего класса
А если и за час не пришел, то в следующий час можно ожидать 4.
Ок, почитал комменты ниже, понял, что не прав)
На самом деле, предел 1-(1-1/n)n стремится не к 1, а к 1-1/e, что составляет примерно 0,63
Именно такова будет вероятность получить хотя бы одно число 13 после 37 вращений рулетки.
С выбраковкой классов тоже не стоит спешить: если все шло как по часам, а затем случайно целый период T не было продаж, то возможно от лишних коров стоит избавится при первой возможности.
Во-первых, надо понимать, насколько адекватно у нас заданы условия. Это, я считаю, важно отметить в описнии задачи. Если характеристики случайных величин верны (например случайные величины специально генерируются с указанными параметрами), то онлайн регулирование не требуется, или требуется, но исключительно калибровочное. Мы можем немножко менять скорость выписывания коров или изредка просто сливать лишних как исключение. Для реального мира эти величины скорее всего взяты из статистики и нам постоянно грозят черные лебеди, неучтенные ошибки и изменения на рынке. В этом случае надо более агрессивно держать оптимальный запас.
В любом случае эти параметры тонкой настройки не гарантируют ничего. Это просто рандомная ставка на риски, те или иные — не важно.
Если же ваши ожидания насчет потока клиентов не оправдываются, действительно не стоит заказывать лишних коров
Мои ожидания по поводу потока клиентов основаны на данных из условий задачи. Это вектор l. Если эти ожидания не оправдываются на долгосрочной перспективе, то это значит лишь, что исходные данные (тот самый вектор) не описывает распределение событий. В этом случае мы должны корректировать вектор (например, уточнять его статистикой), или агрессивно подстраивать поток заказов. Но это уже не будет исходной задачей.
Да и на счет "лишних коров", почему вы однобоко подходите к возможным рискам? А если «неоправдавшиеся ожидания» привели к обратной ситуации и коров не хватило, отчего мы потеряли хороших клиентов и недополучили прибыль? Если скорость пополнения буффера и его размер выбраны верно, а «ожидания» соответствуют характеристикам случайной величины, то риски в ту и другую сторону одинаковы.
Ну а вы в данном случае поддались классическому когнитивному искажению отдавая в плане рисков незаслуженный приоритет тому, что имеете по отношению к тому, что могли бы иметь.
Подчеркну для ясности.
как вы правильно заметили, нужно учитывать, какие коровы уже заказаны и что они придут в будущем.
Я не говорил, что это нужно как-то учитывать онлайн-управлением. Это должно быть учтено автоматически в скорости заказа коров из деревни на основе вероятностных зарактеристик потока покупателей.
Добавил пояснения в текст статьи.
не должен быть привязан к событиям прихода покупателей, то есть не обязательно должен происходить по факту прихода кого-то из них или по факту продажи
На самом деле, скорее всего, должен. Смотрите.
Допустим, у нас есть состояние (state). В этом состоянии:
1. Вероятность прихода покупателя
2. Текущее количество коров
3. И другая статика типа цены на корову
Решение о покупке (покупать или нет) мы делаем только на основе этого состояния, но не того, что было ДО него. У нас полностью случайный рынок, следовательно ситуация как в казино — приход 10 черных цифр все-еще оставляет равную вероятность прихода каждого цвета. Ждать какое-то время после прихода покупателя — все-равно, что ждать, чтобы выпало еще черное, чтобы ставить на красное.
То есть наш state изменяется исключительно в момент покупки коровы, а потом каждый отрезок времени ничего не меняется.
Значит весь вопрос задачи только в максимальном количестве коров, к которому мы всегда стремимся. Ну и, конечно, определение списка классов, которым мы продаем, но это статика, которая определяется до начала продаж.
И еще на примере. Допустим T=0 (то есть корову могут доставить сразу после заказа). Следовательно в таком случае мы делаем Макс=1 и заказываем корову сразу после того, как у нас забирают ту, что есть. Ждать время — это исключительно игра в рулетку:
— У меня корову только что купили, так что ближашие несколько минут покупателя точно не будет, значит надо немножко подождать, перед тем, как заказывать следующую и плевать на теорию вероятностей.
— У меня корову только что купили, так что ближашие несколько минут покупателя точно не будет, значит надо немножко подождать, перед тем, как заказывать следующую и плевать на теорию вероятностей.
На примере. Допустим, цена продажи коровы Ц=100, цена содержание за время доставки — Р=70, а также приходит в среднем 10 человек за время доставки.
Если мы возьмем максимум коров М=10, то получим такое распределение:
Если количество коров М=15, то такое распределение:
Для того, чтобы посчитать среднюю прибыль для каждого количества коров необходимо умножить прибыль каждого варианта на вероятность этого варианта и просуммировать.
К примеру, для 15:
Уверен, для этого есть формула. К сожалению, по образованию гуманитарий, так что вспомнить ее не могу.
Так вот, таким образом мы получим прибыль для каждого варианта. Увеличивая М на 1 будем получать все большую сумму. (при М=0 — С=0, при М=1 — С=~30). И в какой-то момент эта сумма начнет падать. Вот это число М, которое имеет наибольшую сумму — есть наш буфер для данных чисел.
Если мы возьмем максимум коров М=10, то получим такое распределение:
Если количество коров М=15, то такое распределение:
Для того, чтобы посчитать среднюю прибыль для каждого количества коров необходимо умножить прибыль каждого варианта на вероятность этого варианта и просуммировать.
К примеру, для 15:
... + -550*вероятность(5) + ... + -50*вероятность(10) + ... + 450*вероятность(15)
Уверен, для этого есть формула. К сожалению, по образованию гуманитарий, так что вспомнить ее не могу.
Так вот, таким образом мы получим прибыль для каждого варианта. Увеличивая М на 1 будем получать все большую сумму. (при М=0 — С=0, при М=1 — С=~30). И в какой-то момент эта сумма начнет падать. Вот это число М, которое имеет наибольшую сумму — есть наш буфер для данных чисел.
Я забыл учесть, что коровы продаются, следовательно в расходе необходимо это учитывать. Например для М=15:
Может показаться странным, что я не беру в рассчет заказанные коровы, но это неважно. Мы рассчитываем буфер и заказываем новую корову при продаже старой. Следовательно за это время буфер обновится и в среднем для новых 15 коров будет та же выгода.
Расход в случае 5 покупателей: 70 * (15 - 5/2)
Расход в случае 10 покупателей: 70 * (15 - 10/2)
Расход в случае 15 покупателей: 70 * (15 - 15/2)
Может показаться странным, что я не беру в рассчет заказанные коровы, но это неважно. Мы рассчитываем буфер и заказываем новую корову при продаже старой. Следовательно за это время буфер обновится и в среднем для новых 15 коров будет та же выгода.
Никогда не стоит плевать на теорию вероятностей, иначе мы рискуем впасть в азарт и просадить все состояние из-за когнитивных искажений.
Не забывайте, что у нас речь идет о симметричном риске с двух сторон: 1) подержать лишних коров какое-то время на довольствии; 2) пропустить ценного клиента при опустевшем буфере.
Пуассоновский характер поступления покупателей даёт нам понимание, сколько в среднем на большом интервале времени их приходит за единицу времени. Этого (вкупе с прочими параметрами) достаточно, чтобы определить строгую регулярную частоту заказа коров, которая в среднем будет покрывать требования покупателей. Увеличение буфера уменьшает количество упущеных покупателей (недополученная прибыль), зато увеличивает расходы на корм. Уменьшение буфера снижает расходы на корм, зато недополученная прибыль на пропущенных клиентах начнет расти.
Не забывайте, что у нас речь идет о симметричном риске с двух сторон: 1) подержать лишних коров какое-то время на довольствии; 2) пропустить ценного клиента при опустевшем буфере.
Пуассоновский характер поступления покупателей даёт нам понимание, сколько в среднем на большом интервале времени их приходит за единицу времени. Этого (вкупе с прочими параметрами) достаточно, чтобы определить строгую регулярную частоту заказа коров, которая в среднем будет покрывать требования покупателей. Увеличение буфера уменьшает количество упущеных покупателей (недополученная прибыль), зато увеличивает расходы на корм. Уменьшение буфера снижает расходы на корм, зато недополученная прибыль на пропущенных клиентах начнет расти.
Про «плевать на теорию вероятностей» это был сарказм, конечно. Но если отвязаться от покупателя и просто покупать коров равнораспределенно, то тогда формулы вообще упрощаются.
Именно! И надежность решения растёт. Надо нарисовать графики рисков по упущению и по перерасходу кормёжки от размера буффера. Там, где они пересекутся и будет оптимальный размер.
Простите, не могу комментировать с вашей скоростью, поэтому отвечу здесь.
Нельзя заказывать только по факту продажи из-за возможного очень большого лага T. Интуитивно представьте, что наблюдается времнное затишье и покупатели не идут. Если они потом не усилят частоту прихода, значит у нас неверные данные о потоке, а если верные, то потом покупатели пойдут чаще и мы тупо не сформируем лаг. Я настаиваю на том, что данные о потоке однозначно определяют скорость заказов. И это будет работать при любых соотношениях T и среднего времени появления поупателей. А из-за вашего лага придется неоправданно увеличивать буффер терпя издержки на хавчике.
Простите, не могу комментировать с вашей скоростью, поэтому отвечу здесь.
Я говорю о том, что по факту покупки необходимо покупать сразу корову, все. Продал корову — заказал новую. Если мы сидим с пустым буфером, то значит у нас в заказах уже висит максимальное количество коров. И такое может быть с абсолютно любой выгодной стратегией — пустой буфер, куча коров в ожидании и новый клиент. Вопрос исключительно в том, какой должен быть буфер.
Нельзя заказывать только по факту продажи из-за возможного очень большого лага T. Интуитивно представьте, что наблюдается времнное затишье и покупатели не идут. Если они потом не усилят частоту прихода, значит у нас неверные данные о потоке, а если верные, то потом покупатели пойдут чаще и мы тупо не сформируем лаг. Я настаиваю на том, что данные о потоке однозначно определяют скорость заказов. И это будет работать при любых соотношениях T и среднего времени появления поупателей. А из-за вашего лага придется неоправданно увеличивать буффер терпя издержки на хавчике.
На самом деле, что ваш, что мой вариант в долгосрочной перспективе приблизительно одинаковые. Смотрите, что у вас, что у меня будет буфер. И мы с вами в среднем заказываем абсолютно одинаковое количество коров за единицу времени. Вы ведь заказываете в среднем коров столько, сколько клиентов приходит и я заказываю коров столько, сколько клиентов приходит. Следовательно где-то уже через 1Т у нас с вами будут висеть в заказах одинаковое количество коров и равное среднему количеству покупателей.
Вопрос лишь в начальном буфере. С каким количество коров необходимо прийти, чтобы максимизировать прибыль?
Вопрос лишь в начальном буфере. С каким количество коров необходимо прийти, чтобы максимизировать прибыль?
Увеличение буфера уменьшает количество упущеных покупателей (недополученная прибыль), зато увеличивает расходы на корм. Уменьшение буфера снижает расходы на корм, зато недополученная прибыль на пропущенных клиентах начнет расти
Главный вопрос — как правильно рассчитать буфер, чтобы максимизировать прибыль.
Например, построить график прибыли (упущеной с вероятностью P=const) от размера буфера. И посроить график издержек (с той же зафиксированной вероятностью вероятностью P) от размера буфера. Точка пересечения — идеальный размер с вероятностью P.
Поигравшись с вероятностями и применив волшебные три сигма по гауссу мы получим хорошие показатели.
Поигравшись с вероятностями и применив волшебные три сигма по гауссу мы получим хорошие показатели.
У нас есть М (количество коров), Ц (цена продажи), Р (расходы на корову за время, равное времени доставки коровы) и А (среднее количество человек). Какие формулы для этих графиков?
Формула на самом деле будет еще сложнее, чем кажется, из-за множества категорий клиентов с разной скоростью потоков. Тут можно статистически графики построить оттабулировав настройки. Благо модель не сложная.
Можно заморочиться интегралами и дифурами, конечно, но если задача чисто академиеская, то я лучше спать, а если практическая, то там наверняка не так всё гладко с параметрами потока и лучше сразу строить адативную модель, которая будет инкремнтально уточнять себя по мере накопления данных и даже с учетом их устаревания и инвалидации.
Это тот самый порог, где порой стоит остановиться и решать даьше практическую задачу, вместо сферической в вакууме.
Можно заморочиться интегралами и дифурами, конечно, но если задача чисто академиеская, то я лучше спать, а если практическая, то там наверняка не так всё гладко с параметрами потока и лучше сразу строить адативную модель, которая будет инкремнтально уточнять себя по мере накопления данных и даже с учетом их устаревания и инвалидации.
Это тот самый порог, где порой стоит остановиться и решать даьше практическую задачу, вместо сферической в вакууме.
Решение о покупке (покупать или нет) мы делаем только на основе этого состояния, но не того, что было ДО него.
Нам не нужно принимать такие решения по факту покупки. Из-за T, которое может в том числе сильно превышать средний интервал появления клиентов, мы рискуем замешкаться и пропустить покупателей сидя у пустого буфера. При этом мы халатно не используем данные в условии задачи параметры потока клиентов. Вероятностные характеристики потока однозначно определяют скорость наших заказов коров. Попытка рулить онлайн чревата потерями.
По-прежнему настаиваю, что никаких решений онлайн принимать в задаче не надо, если речь идет о достоверно известных параметрах потока (то есть величины генерируются по этим параметрам). Если параметры распределения собраны статистически, то нужно делать предоханители сверху и снизу, а также агрессивную петлю отрицательной обратной связи для борьбы с неполнотой сведений о реальных параметрах случайных величин.
В реальном мире параметры этих случайных величин не могут быть известны достоверно в принципе. А статистика — это заведомо неполная неточная информация.
Нам не нужно принимать такие решения по факту покупки. Из-за T, которое может в том числе сильно превышать средний интервал появления клиентов, мы рискуем замешкаться и пропустить покупателей сидя у пустого буфера
Я говорю о том, что по факту покупки необходимо покупать сразу корову, все. Продал корову — заказал новую. Если мы сидим с пустым буфером, то значит у нас в заказах уже висит максимальное количество коров. И такое может быть с абсолютно любой выгодной стратегией — пустой буфер, куча коров в ожидании и новый клиент. Вопрос исключительно в том, какой должен быть буфер.
Хотел бы добавить несколько соображений.
- Запрашивать достаточно по одной корове. В любом случае запрос нескольких коров одновременно можно разбить на несколько запросов по одной корове с бесконечно малым промежутком по времени.
Тогда можно ещё приравнять стоимость коровы к единице (если в исходных данных она ненулевая)
И время доставки тоже нормализовать, пересчитав параметры распределения. Минус два параметра.
Sergey_Kovalenko, Мужик платит за содержание коровы, пока её доставляют на склад или нет?
Это может сильно повлиять на стратегию: коровы ещё в пути, а он уже несет убытки.
И время доставки тоже нормализовать, пересчитав параметры распределения. Минус два параметра.
Sergey_Kovalenko, Мужик платит за содержание коровы, пока её доставляют на склад или нет?
Это может сильно повлиять на стратегию: коровы ещё в пути, а он уже несет убытки.
Простите, отправил недописанный комментарий! Должно было быть примерно так:
Таким образом, как мне кажется, задача сводится к одному классу клиентов с известным параметром l, и это уже значительно более поддающаяся решению задача.
- Запрашивать достаточно по одной корове. В любом случае запрос нескольких коров одновременно можно разбить на несколько запросов по одной корове с бесконечно малым промежутком по времени.
- Похоже, что все классы покупателей можно рассматривать по-отдельности.
Пусть у нас есть только один класс k1, пусть для него оптимальной будет стратегия S1.
Стратегия,Аналогично, для класса k2 — стратегия S2. Теперь предположим, что нужно решить задачу для двух классов: k1 и k2. Так вот, я утверждаю, что оптимальной будет просто независимая комбинация двух стратегий S1 и S2 (в одной мы ориентируемся только на данные по клиентам первого класса, во второй — только на второго). Если же предположить, что есть более хорошая стратегия, то она даст больше доходности на одном из классов. Тогда для задачи только с одним классом можно применить эту, улучшенную стратегию (урезанную на один класс) и получить большую доходность, а это противоречие.… в моём понимании, это некоторый функционал от всех имеющихся на данный момент данных (о клиентах, о коровах, о запросах и т.д.) и времени, который принимает значение 0 или 1. 0 означает, что в этот момент времени мы ждём, 1 — запрашиваем корову.
Немного сумбурно и не очень строго, но надеюсь, понятна мысль. - Можно считать, что параметры распределения известны. Так как интересует матожидание доходности, то любым начальным отрезком времени (конечным) можно пренебречь. А за этот начальный отрезок можно с любой заданной точностью найти параметры распределения.
Таким образом, как мне кажется, задача сводится к одному классу клиентов с известным параметром l, и это уже значительно более поддающаяся решению задача.
Думаю, независимость стратегий стоит обосновать получше: когда на рынке два продавца, каждый на свою аудиторию, иногда им будет выгодно кредитовать друг друга коровами.
Продавец ведь всегда один, разве нет? Я про классы покупателей
Если A кредитует B, то B получает выгоду в виде неупущенного клиента, но зато у A образуется дефицит и увеличивается вероятность отказать своему клиенту. С другой стороны, B придётся когда-то отдавать корову, и в момент отдачи у него тоже образуется дефицит и вероятность отказа, зато у A в этот момент увеличится буфер и уменьшатся риски. На круг, риски скомпенсируют бенефиты, и все останутся при своих, как если бы стратегии были полностью независимыми.
Не будет у B дефицита и вероятности отказа, потому что ту корову, которую он будет отдавать обратно, он закажет дополнительно.
В любом решении этой задачи должен соблюдаться закон сохранения среднего потока, иначе коровы будут либо накапливаться, либо склад опустеет. Если A и B оба держат поток заказов в среднем равным потоку продаж, то количество коров на складе у них в среднем не растёт и не падает, а держится вблизи оптимума, задаваемого соотношением средней цены потери клиента и средней стоимости корма для коровы до её продажи.
Если кто-то начинает заказывать коров вне очереди, значит где-то должно быть накопление коров и отклонение от оптимума — либо у А, либо у B. Заказ дополнительной коровы для покрытия кредита эквивалентен экстренному заказу дополнительной коровы для покрытия внезапного опустошения буфера в сценарии объединённого буфера.
Если кто-то начинает заказывать коров вне очереди, значит где-то должно быть накопление коров и отклонение от оптимума — либо у А, либо у B. Заказ дополнительной коровы для покрытия кредита эквивалентен экстренному заказу дополнительной коровы для покрытия внезапного опустошения буфера в сценарии объединённого буфера.
Смотрите еще раз:
- А отдал Б корову
- Б продал корову и заказал новую
- Б получил корову и вернул ее А
Где тут нарушился баланс-то?
Если бы кредитования не было, то вышло бы так:
1) А продал единственную корову первому миллионеру
2) А отказал второму миллионеру
3) А некоторое время не заказывает новую корову, потому что по его оптимальной стратегии делать это ещё рано: средний поток миллионеров мал, и если заказывать корову немедленно, то её придётся долго кормить. А должен поддерживать достаточно низкий поток коров. Делать это он может лишь меняя частоту заказов (он не может заказывать пол-коровы)
Но в случае с кредитованием Б приносит А корову через день, и теперь у А больше коров, чем его оптимум, и он тратит деньги на корм, хотя, возможно, следующего миллионера после двух первых придётся ждать очень долго. Эффективная частота заказов увеличилась из-за Б, и на бесконечно большом промежутке времени А проиграет примерно столько, сколько выиграл.
1) А продал единственную корову первому миллионеру
2) А отказал второму миллионеру
3) А некоторое время не заказывает новую корову, потому что по его оптимальной стратегии делать это ещё рано: средний поток миллионеров мал, и если заказывать корову немедленно, то её придётся долго кормить. А должен поддерживать достаточно низкий поток коров. Делать это он может лишь меняя частоту заказов (он не может заказывать пол-коровы)
Но в случае с кредитованием Б приносит А корову через день, и теперь у А больше коров, чем его оптимум, и он тратит деньги на корм, хотя, возможно, следующего миллионера после двух первых придётся ждать очень долго. Эффективная частота заказов увеличилась из-за Б, и на бесконечно большом промежутке времени А проиграет примерно столько, сколько выиграл.
Но в случае с кредитованием Б приносит А корову через день,
Прошу прощения, в последнем абзаце напутал чутка. Б даёт корову А немедленно. После этого А заказывает и отдаёт корову Б, а также должен решить, заказывать ли корову для себя или нет. Если он закажет, то эффективная частота заказов будет выше оптимума, и он будет терять на корме. Оптимальной стратегией будет пропустить один запланированный заказ, чтобы скомпенсировать незапланированное увеличение потока заказов — но это увеличивает риск отказа. На бесконечном промежутке времени… и т.д.
Прошу прощения, в последнем абзаце напутал чутка. Б даёт корову А немедленно. После этого А заказывает и отдаёт корову Б, а также должен решить, заказывать ли корову для себя или нет. Если он закажет, то эффективная частота заказов будет выше оптимума, и он будет терять на корме. Оптимальной стратегией будет пропустить один запланированный заказ, чтобы скомпенсировать незапланированное увеличение потока заказов — но это увеличивает риск отказа. На бесконечном промежутке времени… и т.д.
Вот вам простейший пример. Допустим, есть два типа покупателей. Первый покупает задорого (например, за миллион), но настолько редко, что для него выгодно держать только 1 корову. Второй покупает чаще, но с наценкой всего в 1 рубль.
Допустим, первый покупатель пришел два раза подряд. В таком случае выгодно отдать ему корову, которую держали для второго покупателя — потому что одна его покупка выгодна так же, как миллион покупок второго покупателя.
Это равносильно тому, что у мы смешиваем два буфера (для редких богачей, длиной 1 и для частых бедняков, длиной L) в один, и берём коров не глядя. В смешанном буфере будет L+1 корова, и если L настроено правильно, чтобы обслуживать большой поток бедняков, то у нас практически всегда найдётся корова для внезапного зашедшего богача (что увеличит риск отказа более часто заходящему бедняку). Пока не вижу отличий.
Два потока с интенсивностью I и J и маржой x и y соответственно смешиваются в один с интнсивностью I+J и маржой (x*I+y*J)/(I+J).
Что позволяет из двух нерентабельных классов сделать один рентабельный.
Что позволяет из двух нерентабельных классов сделать один рентабельный.
А вообще, вы тут неявно пронесли дополнительное условие: якобы первый продавец не может спокойно ждать появления ещё одного покупателя, пока второй торгует вовсю. Т.е. вы задали граничное условие: конечность времени.
В случае с бесконечным временем нет проблем подождать своего покупателя хоть ещё миллиард лет — так как средний поток покупателей неизменен, то на длинном промежутке все отказы из-за дефицита коровы будут скомпенсированы удачными продажами сразу после прибытия новой коровы (без необходимости кормить её слишком долго).
В случае с бесконечным временем нет проблем подождать своего покупателя хоть ещё миллиард лет — так как средний поток покупателей неизменен, то на длинном промежутке все отказы из-за дефицита коровы будут скомпенсированы удачными продажами сразу после прибытия новой коровы (без необходимости кормить её слишком долго).
Ваша задача происходит из экономики. И решается, как правило не математически, а организационным-экономическим путем, с помощью новых вводных.
В общем виде задача сводится к уменьшению количества связанного капитала. Или пропускной способности предприятия. Классическая книжка по теме: Голдрейт, Цель.
Кстати, если вам интересны экономические задачи. То я как раз занимаюсь проектом по решению более общей задачи: организацией разделения труда и вычислением требуемого количества капитала, для его существования. На основе модели Рикардо.
Здесь капитал явно указан неограниченным
Задача просто максимизировать прибыль
Зачем максимизировать то, что даётся по условию в неограниченном количестве? Без ограничения по капиталу задача не имеет смысла в принципе. Экономика должна быть экономной, иначе это не экономика. Вы же не будете продавать людям снег зимой, и стараться просто максимизировать прибыль от этого занятия..?
процентная ставка подразумевается нулевой
в реальной жизни ставка уже давно отрицательная, лишь бы клиент нашелся, что бы было на кого риски спихнуть))
Можно как-нибудь поделится ссылкой на электронную версию книги?
Есть классическая задача об обслуживании кораблей в порту. Возможно покупателей можно рассматривать как корабли, а коров — как причалы.
Буду благодарен за ссылку.
Начну с конца. Системы массового обслуживания бывают без очередей. Корову можно считать устройством обслуживания, время обслуживания — Т (время доставки очредной коровы после продажи)
Очень похоже что так и есть, но хотелось бы доказательство того факта, что оптимальная стратегия всегда заказывает новую корову в момент продажи старой.
Если вы закажете корову до продажи то число устройств обслуживания какое-то время будет больше чем нужно. А если после то меньше. Как то так.
"… что оптимальная стратегия всегда заказывает новую корову в момент продажи старой."-Это весьма правдоподобно, но не верно.
не верно.
Аргументируйте
Всего один класс, разумные предположения о прибыли и расходах, T много больше среднего ожидания клиента, скажем минута и месяц, тогда стоит заказывать на месяц вперед одну корову в минуту почти независимо от текущего состояния дел.
Черт, классный пример. Как говорится, вместо тысячи слов. При заказе только по факту продажи мы будем продавать корову раз в месяц, а при ежеминутном раз в минуту начиная через месяц.
Но предвосхищу возражения и патчи алгоритма любителей интуитивных оптимизаций.
Они скажет, что заказывать надо только по факту прихода хорошего клиента независимо от того продали мы ему корову или нет.
На это возразить будет сложнее.
Сморите. Клиенты приходят в среднем раз в минуту, а это эквивалентно 60 раз в час.
Представьте, что так уж вышло, что пол часа было затишье, а потом они на какое-то время повалили быстрее. Вполне вероятная ситуация для пуассоновского процесса.
Фишка в том, что все эти пол часа мы не заказывали коров, но это никак не отразилось на размере буфера. Получасовое затишье в приходе коров произойдёт аж через месяц, а все эти пол часа приходили коровы, которые были заказаны месяц назад. То есть, мы зачем-то отодвинули затишье на месяц вперёд, когда оно может и не наступить, а может через месяц напротив на это получасовое затишье придет наплыв клиентов.
Понятно, что в среднем мы на этом потеряем не так много, но определённо потеряем. И бессмысленно усложним процесс закупки. Вместо заказов раз в минуту будем делать заказы именно в момент продажи.
Что это. как не суеверная интуитивная «оптимизация» (в кавычках, потому что нет, не оптимизация это).
Но предвосхищу возражения и патчи алгоритма любителей интуитивных оптимизаций.
Они скажет, что заказывать надо только по факту прихода хорошего клиента независимо от того продали мы ему корову или нет.
На это возразить будет сложнее.
Сморите. Клиенты приходят в среднем раз в минуту, а это эквивалентно 60 раз в час.
Представьте, что так уж вышло, что пол часа было затишье, а потом они на какое-то время повалили быстрее. Вполне вероятная ситуация для пуассоновского процесса.
Фишка в том, что все эти пол часа мы не заказывали коров, но это никак не отразилось на размере буфера. Получасовое затишье в приходе коров произойдёт аж через месяц, а все эти пол часа приходили коровы, которые были заказаны месяц назад. То есть, мы зачем-то отодвинули затишье на месяц вперёд, когда оно может и не наступить, а может через месяц напротив на это получасовое затишье придет наплыв клиентов.
Понятно, что в среднем мы на этом потеряем не так много, но определённо потеряем. И бессмысленно усложним процесс закупки. Вместо заказов раз в минуту будем делать заказы именно в момент продажи.
Что это. как не суеверная интуитивная «оптимизация» (в кавычках, потому что нет, не оптимизация это).
Черт, классный пример. Как говорится, вместо тысячи слов. При заказе только по факту продажи мы будем продавать корову раз в месяц, а при ежеминутном раз в минуту начиная через месяц.
Плохой пример. Он проигнорировал необходимость буфера, который как раз на это и рассчитан. Мы берем столько коров, чтобы за этот месяц «ожидания» получить максимальную прибыль. Ровно так же, как и закупая их случайным образом. Необходим одинаковый буфер для обоих случае и число заказов для обоих случаев будет в среднем одинаковым.
Они скажет, что заказывать надо только по факту прихода хорошего клиента независимо от того продали мы ему корову или нет.
Глупость какая-то. Заказывать необходимо по факту продажи.
Меня бомбит. Либо я дупак, либо лыжи не едут. Только не исчезайте, докажите мне что я не прав.
Под словом «пример» я подразумевал интервалы: минута и месяц. Это позволяет сделать проблему более интуитивно понятной.
Буфер делать в этом примере можно и нужно.
Давайте рассмотрим стационарную ситуацию.
Клиенты приходят примерно раз в минуту, коровы добираются по месяцу и буфер,, скажем, из 10 коров полон. Также в пути дофигища коров, они поступают тоже со скоростью примерно раз в минуту.
Рассмотрим ваш вариант. Пуассоновский процесс допускает вероятность, что случится «затишье» на пол часика, когда ни один клиент не придет, хотя мат-ожидание 1 минута.
Все эти пол часа ни одной коровы не вызвано из деревни. Ровно через месяц выдаются пол часа, когда коровы не приходят из деревни. За это время пусть пришло примерно 30 человек. Первые 10 выбрали пул, остальные 20 ушли. Это не прогноз, а просто один из вполне вероятных вариантов развития событий.
Теперь представьте, что при прочих равных коров мы заказываем строго раз в минуту, это значит, что пул вырастет за пол часа тишины на 30 коров (получится их 40 у нас), потом они постепенно будут рассасываться неопределенно долгое время. Но через месяц не будет полу часа без коров. Всё будет в штатном режиме.
Ваша схема фактически апрещает рост пула сверх некоторого числа, а моя никак не ограничивает его, но за счет фиксированного интервала заказа равного мат-ожиданию прихода покупателей скорость прихода коров получается в среднем равной скорости их сбыта.
Под словом «пример» я подразумевал интервалы: минута и месяц. Это позволяет сделать проблему более интуитивно понятной.
Буфер делать в этом примере можно и нужно.
Давайте рассмотрим стационарную ситуацию.
Клиенты приходят примерно раз в минуту, коровы добираются по месяцу и буфер,, скажем, из 10 коров полон. Также в пути дофигища коров, они поступают тоже со скоростью примерно раз в минуту.
Рассмотрим ваш вариант. Пуассоновский процесс допускает вероятность, что случится «затишье» на пол часика, когда ни один клиент не придет, хотя мат-ожидание 1 минута.
Все эти пол часа ни одной коровы не вызвано из деревни. Ровно через месяц выдаются пол часа, когда коровы не приходят из деревни. За это время пусть пришло примерно 30 человек. Первые 10 выбрали пул, остальные 20 ушли. Это не прогноз, а просто один из вполне вероятных вариантов развития событий.
Теперь представьте, что при прочих равных коров мы заказываем строго раз в минуту, это значит, что пул вырастет за пол часа тишины на 30 коров (получится их 40 у нас), потом они постепенно будут рассасываться неопределенно долгое время. Но через месяц не будет полу часа без коров. Всё будет в штатном режиме.
Ваша схема фактически апрещает рост пула сверх некоторого числа, а моя никак не ограничивает его, но за счет фиксированного интервала заказа равного мат-ожиданию прихода покупателей скорость прихода коров получается в среднем равной скорости их сбыта.
У вас слишком маленький пул. Первую заказанную корову вы получите не раньше, чем через час по любой системе, следовательно необходимо прийти с количеством коров, достаточным для часа торговли (самым выгодным, если быть точным). Допустим, это 60.
Теперь возьмем ваш пример, но инвертированный. В первые полчаса пришли 60 клиентов, разобрали всех коров и следующие полчаса никогда не было. В следующий час снова в первые полчаса пришли 60 клиентов. Если мы заказывали коров сразу после покупки, то смогли обслужить всех 60 клиентов, а если равномерно, то вторая половина коров не получит, ибо пришли до их прихода.
Обратно работает и для равнораспределенного варианта — можно придумать кучу гипотетических ситуаций, когда он выгоден.
Допустим с монеткой. Можно ставить на орел, а можно ставить на решку. Например в случае если из трех раз орел выпадет три раза, или два раза, то выгоднее ставить на орла. А если же нет, то выгоднее ставить на решку.
Но в перспективе они одинаковые. Потому что как вы считаете среднее количество коров в час? Берете всех покупателей и делите на время. А я просто беру всех покупателей.
И если за час приходит в среднем 60 покупателей, то за 1000 придет приблизительно 60000 покупателей. И за 1000 часов и вы и я закажем и продадим приблизительно 60000 коров.
Теперь возьмем ваш пример, но инвертированный. В первые полчаса пришли 60 клиентов, разобрали всех коров и следующие полчаса никогда не было. В следующий час снова в первые полчаса пришли 60 клиентов. Если мы заказывали коров сразу после покупки, то смогли обслужить всех 60 клиентов, а если равномерно, то вторая половина коров не получит, ибо пришли до их прихода.
Обратно работает и для равнораспределенного варианта — можно придумать кучу гипотетических ситуаций, когда он выгоден.
Допустим с монеткой. Можно ставить на орел, а можно ставить на решку. Например в случае если из трех раз орел выпадет три раза, или два раза, то выгоднее ставить на орла. А если же нет, то выгоднее ставить на решку.
Но в перспективе они одинаковые. Потому что как вы считаете среднее количество коров в час? Берете всех покупателей и делите на время. А я просто беру всех покупателей.
И если за час приходит в среднем 60 покупателей, то за 1000 придет приблизительно 60000 покупателей. И за 1000 часов и вы и я закажем и продадим приблизительно 60000 коров.
И еще один пример. Представьте инвертированную ситуацию. Допустим, клиент приходит в среднем раз в час, а корова до нас доходит за минуту. Если вы будете заказывать корову раз в час, то у вас будут моменты, когда будет и 3 и 4 коровы, а если вы продадите последнюю корову, а следующая покупка будет только через 40 минут, то все клиенты, которые придут в эти 40 минут останутся без коров. В то же время, если заказывать сразу после покупки — не будет излишка и мы можем потерять только 1/60 клиентов. Если сделать буфер в 2 коровы, а не в одну, то потеряем еще меньше клиентов — 1\3600. Понимаете?
Понимаю, что филигранно подобранным примером можно доказать все что угодно. Я даже сам в этом неслабо так преуспел доказывая себе=).
Не очень понятно откуда 1/60. А насчет ситуации, когда ща 40 минут придет много клиентов, которые обычно ходят с мат-ожиданием раз в час, то вероятность (вернее частота) таких ситуаций довольно мала. И ее надо сравнивать с настолько же неудобными и вероятными случаями для вашей стратегии.
Короче, надо либо формулы уже начинать писать, либо имитационную модель для статистической проверки стратегий.
Не очень понятно откуда 1/60. А насчет ситуации, когда ща 40 минут придет много клиентов, которые обычно ходят с мат-ожиданием раз в час, то вероятность (вернее частота) таких ситуаций довольно мала. И ее надо сравнивать с настолько же неудобными и вероятными случаями для вашей стратегии.
Короче, надо либо формулы уже начинать писать, либо имитационную модель для статистической проверки стратегий.
Не очень понятно откуда 1/60
В среднем у нас не будет коров в течении 1 минуты каждый час. То есть смотрите. Следовательно в 1/60 случаев прихода клиентов у нас не будет коровы.
За 40 минут вполне может прийти 2-3 клиента, но в долгосрочной перспективе у нас также не будет коров, чтобы обслужить каждого 60-ого клиента)
Меня бомбит. Либо я дупак, либо лыжи не едут. Только не исчезайте, докажите мне что я не прав.
Под словом «пример» я подразумевал интервалы: минута и месяц. Это позволяет сделать проблему более интуитивно понятной.
Буфер делать в этом примере можно и нужно.
Давайте рассмотрим стационарную ситуацию.
Клиенты приходят примерно раз в минуту, коровы добираются по месяцу и буфер,, скажем, из 10 коров полон. Также в пути дофигища коров, они поступают тоже со скоростью примерно раз в минуту.
Рассмотрим ваш вариант. Пуассоновский процесс допускает вероятность, что случится «затишье» на пол часика, когда ни один клиент не придет, хотя мат-ожидание 1 минута.
Все эти пол часа ни одной коровы не вызвано из деревни. Ровно через месяц выдаются пол часа, когда коровы не приходят из деревни. За это время пусть пришло примерно 30 человек. Первые 10 выбрали пул, остальные 20 ушли. Это не прогноз, а просто один из вполне вероятных вариантов развития событий.
Теперь представьте, что при прочих равных коров мы заказываем строго раз в минуту, это значит, что пул вырастет за пол часа тишины на 30 коров (получится их 40 у нас), потом они постепенно будут рассасываться неопределенно долгое время. Но через месяц не будет полу часа без коров. Всё будет в штатном режиме.
Ваша схема фактически апрещает рост пула сверх некоторого числа, а моя никак не ограничивает его, но за счет фиксированного интервала заказа равного мат-ожиданию прихода покупателей скорость прихода коров получается в среднем равной скорости их сбыта.
Под словом «пример» я подразумевал интервалы: минута и месяц. Это позволяет сделать проблему более интуитивно понятной.
Буфер делать в этом примере можно и нужно.
Давайте рассмотрим стационарную ситуацию.
Клиенты приходят примерно раз в минуту, коровы добираются по месяцу и буфер,, скажем, из 10 коров полон. Также в пути дофигища коров, они поступают тоже со скоростью примерно раз в минуту.
Рассмотрим ваш вариант. Пуассоновский процесс допускает вероятность, что случится «затишье» на пол часика, когда ни один клиент не придет, хотя мат-ожидание 1 минута.
Все эти пол часа ни одной коровы не вызвано из деревни. Ровно через месяц выдаются пол часа, когда коровы не приходят из деревни. За это время пусть пришло примерно 30 человек. Первые 10 выбрали пул, остальные 20 ушли. Это не прогноз, а просто один из вполне вероятных вариантов развития событий.
Теперь представьте, что при прочих равных коров мы заказываем строго раз в минуту, это значит, что пул вырастет за пол часа тишины на 30 коров (получится их 40 у нас), потом они постепенно будут рассасываться неопределенно долгое время. Но через месяц не будет полу часа без коров. Всё будет в штатном режиме.
Ваша схема фактически апрещает рост пула сверх некоторого числа, а моя никак не ограничивает его, но за счет фиксированного интервала заказа равного мат-ожиданию прихода покупателей скорость прихода коров получается в среднем равной скорости их сбыта.
Вполне вероятная ситуация для пуассоновского процесса.
Фишка в том, что все эти пол часа мы не заказывали коров, но это никак не отразилось на размере буфера
И не должно. От того, что полчаса никто не приходил вероятность прихода клиента далее осталась такой же, как и была.
Поймите, распределение пуассона не говорит, что если первые полчаса никто не приходил, то все ожидаемые клиенты повалят во вторые полчаса. Оно говорит о том, что если мы в час ожидаем в среднем 10 клиентов, то можем за этот час получить и 1 и 25.
Почему вы так старательно держите меня за идиота. КОнечно я не считаю, «что если первые полчаса никто не приходил, то все ожидаемые клиенты повалят во вторые пол часа».
Я просто сказал, что в бесконечном пуассоновском потоке с указанными характеристиками наверняка (100%) когда-то случаится такой час, когда в первой половине никого, а во творой 60. Вероятность, что следующий час будет именно таким не нулевая. Я просто привел это как пример. Если кто-то с вами не согласен, надо допускать всё же что это вы чего-то не поняли, а не собеседник тупит.
Я просто сказал, что в бесконечном пуассоновском потоке с указанными характеристиками наверняка (100%) когда-то случаится такой час, когда в первой половине никого, а во творой 60. Вероятность, что следующий час будет именно таким не нулевая. Я просто привел это как пример. Если кто-то с вами не согласен, надо допускать всё же что это вы чего-то не поняли, а не собеседник тупит.
Не надо рассматривать краевой эффект. Он в данном случае не имеет значения. Сравните:
У вас есть пул касс, клиенты приходят по пуассоновскому потоку. Время обслуживания на одной кассе Т.
У вас есть пул коров, вы заказываете новую сразу после продажи. Клиенты приходят по пуассоновскому потоку. Время доставки новой коровы Т.
Я думаю это одно и то же.
У вас есть пул касс, клиенты приходят по пуассоновскому потоку. Время обслуживания на одной кассе Т.
У вас есть пул коров, вы заказываете новую сразу после продажи. Клиенты приходят по пуассоновскому потоку. Время доставки новой коровы Т.
Я думаю это одно и то же.
Не очень понял почему вы ТАК ответили на комментарий выше и что хотели доказать, но вы только что привели еще один хороший довод ПРОТИВ идеи заказывать коров в момент покупки.
Вы привели аналогию, в которой пул касс фиксирован, их не становится больше, а должно становиться, чтобы не пропускать клиентов через T после «затишья».
Вы привели аналогию, в которой пул касс фиксирован, их не становится больше, а должно становиться, чтобы не пропускать клиентов через T после «затишья».
Какое «затишье»? У вас интенсивность потока запросов на обслуживание задана и не меняется. Для системы массового обслуживания без очереди она определяет сколько нужно касс/коров, чтобы вероятность отказа в обслуживании не превышала заданную величину.
Вы забываете, что поток пуассоновский и описывается грубо говоря средним количеством на 1 времени. Это 1 в минуту = 60 в час и т.д., но интервалы между приходам это случайные величины и существует ненулевая вероятность сколь угодно долгого "затишья" независимо от мат ожидания. По затишье я имею в виду, что обычно люди идут 60 в час, но может статься, что и в течении получаса никто не появится. Почитайте мой коммент выше про это. Там про месячную доставку и ежеминутный поток.
Я не понимаю, что вы хотите мне доказать. Если в течении получаса никто не появится коровы будут жрать сено и вы будете терпеть убытки. Но фишка в том, что вы не можете спрогнозировать затишье или аншлаг. Поэтому вам необходимо выбирать размер пула для обслуживания исходя из вероятности отказа в обслуживании.
Размышляя в этом направлении пришел к мысли о существовании нерентабельных клиентов, то есть таких, которые в среднем за промежуток времени приносят денег меньше чем корова съедает.
Размышляя в этом направлении пришел к мысли о существовании нерентабельных клиентов, то есть таких, которые в среднем за промежуток времени приносят денег меньше чем корова съедает.
А вы, похоже, неверно поняли условие задачи. А своей аналогие и вовсе себя запутали. Если задумаетесь как следует, поймёте, то оригинальная задача допускает ситуации, недопустимые в вашем примере, иначе число касс можно было бы варьировать. Пример с кассами нормально иллюстрирует только недостатки плохого решения с заказом коровы в момент покупки.
Если заказывать коров независимо от покупок равномерно со скоростью их потока, то получится эффективнее. Могу доказать, если еще сами не поняли.
Если заказывать коров независимо от покупок равномерно со скоростью их потока, то получится эффективнее. Могу доказать, если еще сами не поняли.
Могу доказать, если еще сами не поняли.
не можете, потому что предположение ошибочно.
Я написал, что пример с фиксированным пулом касс эквивалентен примеру с фиксированным пулом коров и дозаказом в момент покупки.
И да, я хочу пример стратегии с нефиксированным пулом, с доказательством того что он не хуже. И пример случая, недопустимого в моем варианте.
И да, я хочу пример стратегии с нефиксированным пулом, с доказательством того что он не хуже. И пример случая, недопустимого в моем варианте.
Уж несколько раз приводил такие примеры. Еще раз. Без краевого случая. У нас есть некое расчетное N — оптимальный размер пула для заданных a, T и вектора l. Оставим а скобками методику расчета этого N.
Мы постоянно заказываем коров со средней скоростью потока, то есть если средняя скорость потока 1/мин, то и коров мы заказываем по одной строго каждую минуту. Одно исключение. не заказываем очередную корову, если случилось, что пул опустел и клиент ушел без коровы, Очевидно, что если средняя скорость потока верна, то буфер в среднем будет держаться около N. Иногда он будет пустеть и мы будем пропускать клиентов, а иногда будет вырастать, возможно очень сильно больше N/
Мы постоянно заказываем коров со средней скоростью потока, то есть если средняя скорость потока 1/мин, то и коров мы заказываем по одной строго каждую минуту. Одно исключение. не заказываем очередную корову, если случилось, что пул опустел и клиент ушел без коровы, Очевидно, что если средняя скорость потока верна, то буфер в среднем будет держаться около N. Иногда он будет пустеть и мы будем пропускать клиентов, а иногда будет вырастать, возможно очень сильно больше N/
Отлично, пусть на некотором сколь угодно малом интервале, отличном от нуля у вас пул больше N, тогда вы на этом интервале несете убыток. Пусть у вас на некотором сколь угодно малом интервале, отличном от нуля пул меньше N, тогда вы несете убыток. Значит пул должен быть всегда N.
Пусть у вас на некотором сколь угодно малом интервале, отличном от нуля пул меньше N
Это почему?
Дв и не так важен сам факт наличия расходов, или прибыли, как их положительный баланс. Его нужно максимизировать. Пул можно зафиксировать только сверху. Снзу его невозбранно время от времени будут расхватывать клиенты. Если пул ограниен сверху,, то больше вероятность опустошения пула.
Вопрос что перевесит, недополученная прибыль при лишних опустошениях или расходы на кормёжку.
Вернее вопрос в том, как найти оптимальный средний размер пула, чтобы макимизировать баланс.
Потому что пулл отличен от оптимального (для определенности случай нескольких одинаковых оптимальных точек опустим). А раз он оптимальный по прибыли (не по доходам/расходам), а по прибыли, тогда он неоптимальный то плохо. В свою очередь процесс запросов на обслуживание непрерывен, значит можно рассматривать малые интервалы. И наконец если вы продали корову, но сразу не заказали новую у вас в пул меньше, если не продали но заказали — больше оптимального.
Что вы преподаете, если не секрет?
Что вы преподаете, если не секрет?
Вы забываете, что поток пуассоновский и описывается грубо говоря средним количеством на 1 времени. Это 1 в минуту = 60 в час и т.д., но интервалы между приходам это случайные величины и существует ненулевая вероятность сколь угодно долгого «затишья» независимо от мат ожидания
Вы неправильно понимаете. Распределение Пуассона не говорит, что если мы ожидаем в среднем 1 клиента в минуту, то нам придет ровно 60 в час, но непонятно в какой момент. Для 1 человека в минуту в час может прийти и 1 (с очень маленькой вероятность) и 150 человек (с еще меньшей вероятностью). И оно говорит лишь нам о вероятности именно такого числа, а не распределении количества людей по времени.
Отлчно я это всё понимаю. Просто проиллюстрировать хотел именно то что вы сказали. Но добился прямо противоположного эффекта. Я не утверждаю, что если первые пол часа тишина, то вторые пол часа обязательно придут 60 человек. Но такой расклад вполне возможен. Он не невозможен. Именно эту ситуацию, которую, конечно, никак не спрогнозировать, я и привел в качестве примера.
Я отлично понимаю распределение Пуассона.
Я отлично понимаю распределение Пуассона.
Да, но точно так же в первый час может большинство клиентов прийти в начале часа и во второй час большинство клиентов в начале часа. Если закупать сразу после продажи, то ко второму наплыву буфер восстановится, если же закупать равномерно, то восстановиться не успеет. Оба варианта имеют плюсы и минусы, но оба равны в долгосрочной перспективе, потому что вариант с равномерной закупкой является средним от количества продаж.
Так а если они равны в долгосрочной перспективе, то почему не выбрать тот, что проще? Равномерный интервальный заказ проще же. Ну и насчет равнсти в перспективе… надо бы проверить аналитически или экспериментально.
Чем проще? Они одинаково просты, как на меня.
Ну как же. В инженерном смысле навскидку:
В принуипе можно и в вашей стратегии найти плюсы. Типа, поток один и постоянно спит между прерываниями от клиентов.
Но ок. Что там, что там доводы не решающие. Ценность их зависит от конкретной задачи и реализации.
- Изоляция. Мы можем один раз передать в деревню интервал и не слать больше сигналов туда, коровы сами пойдут.
- Равномерность и предсказуемость нагрузки на дереаню. Ъотя этот плюс компенсруется непредсказуемостью роста (пусть даже краткосрочно и маловероятно) буфера, что, явно, минус
В принуипе можно и в вашей стратегии найти плюсы. Типа, поток один и постоянно спит между прерываниями от клиентов.
Но ок. Что там, что там доводы не решающие. Ценность их зависит от конкретной задачи и реализации.
Для не краевого случая добавьте класс с тем же средним временем ожидания и нулевой надбавкой. Это позволяет избавиться от лишних коров куда быстрее, чем они смогут оказать какое-то влияние на распределение их запаса через месяц.
Оптимальная скорость заказа коров равна средней скорости сбыта этих коров.
Размер буфера:
Очевидно, что заказывать коров надо со средней скоростью сбыта (не больше и не меньше)
Ввиду Пуассоновского процесса наш реальный размер буфера будет топтаться около оптимума время от времени с ненулевой вероятностью то упираясь в ноль, то улетая в плюс. Беда в том, что упираясь в ноль мы теряем клиентов, а вылезая в плюс терпим перерасход на содержание скота.
Закупка следующей скотины только по факту продажи, а не когда пришло среднее время закупки толкает нас к нулю и потере клиентов в худшем случае на одну корову, в среднем на пол коровы (в коровах мы буфер измеряем).
Кстати, размер буфера вполне может быть нецелым. Эта мысль только что пришла. То есть седловая точка может попасть, скажем, на 10.5 коров в буфере. Процесс ламинарный по времени и если отвязать закупку коров от продажи эвентуально, то вполне можно держать дробное кол-во коров в буфере.
Размер буфера:
- чем он больше, тем меньше вероятность пропустить клиента, зато больше издержки на корм;
- чем он меньше, тем больше вероятность пропустить клиента, но меньше издержки на корм
Очевидно, что заказывать коров надо со средней скоростью сбыта (не больше и не меньше)
Ввиду Пуассоновского процесса наш реальный размер буфера будет топтаться около оптимума время от времени с ненулевой вероятностью то упираясь в ноль, то улетая в плюс. Беда в том, что упираясь в ноль мы теряем клиентов, а вылезая в плюс терпим перерасход на содержание скота.
Закупка следующей скотины только по факту продажи, а не когда пришло среднее время закупки толкает нас к нулю и потере клиентов в худшем случае на одну корову, в среднем на пол коровы (в коровах мы буфер измеряем).
Кстати, размер буфера вполне может быть нецелым. Эта мысль только что пришла. То есть седловая точка может попасть, скажем, на 10.5 коров в буфере. Процесс ламинарный по времени и если отвязать закупку коров от продажи эвентуально, то вполне можно держать дробное кол-во коров в буфере.
Закупка следующей скотины только по факту продажи, а не когда пришло среднее время закупки толкает нас к нулю и потере клиентов в худшем случае на одну корову, в среднем на пол коровы (в коровах мы буфер измеряем).
Не толкает. Смотрите. Если клиенты приходят равномерно — оба варианта равны. Если клиентов было сначала больше, потом меньше, то больше коров будет, если заказывать сразу после покупки. А если клиентов пришло сначала меньше, а потом больше, то больше коров будет в случае равномерной закупки. В среднем на долгосрочной перспективе оба варианта абсолютно идентичны.
Похоже на то. Но заказ через интервал проще же и прозранее.
Надо тестовый стендик закодить для статистической проверки на днях.
Но я теперь знаю какую задачу задать студентам=).
Надо тестовый стендик закодить для статистической проверки на днях.
Но я теперь знаю какую задачу задать студентам=).
Выяснилось, что равномерно со скорость потока клиентов заказывать коров нельзя.
Почему?
Сначала у вас будут отказы в обслуживании и поток сделок будет меньшей интенсивности чем поток заказов. Затем образуется буфер, который будет необходимо обслуживать.
Впрочем причины не важны. Просто есть контр пример.
Впрочем причины не важны. Просто есть контр пример.
Почему?
Где?
И как тогда заказывать?
Где?
И как тогда заказывать?
Если очень хочется равномерно, то нужно снизить интенсивность потока заказов. Но глобального оптимума вы все равно не достигните.
Если снизить интенсивность, то упремся в 0 и будем пропускать очень много клиентов. Аргументируйте свою позицию, пожалуйста
Аргументирую. Пусть время доставки коровы 1. Интенсивность покупателей 3, прибыль от покупки 10. Корова съедает за 1 времени 2. При равномерном заказе надо заказывать коров не с интервалом 1/3 а с интервалом порядка 1.16/3.
Интервал заказов может чуть-чуть отличаться, я не помню точное значение, но он точно больше 1/3.
Впрочем, я мог ошибиться, нужен независимый контроль.
Интервал заказов может чуть-чуть отличаться, я не помню точное значение, но он точно больше 1/3.
Впрочем, я мог ошибиться, нужен независимый контроль.
Это не аргумент. Вы просто вывалили какие-то цифры. Откуда взялось 1.16? Почему именно столько выгодно? А если корова съедает за 2 времени 1? И даже допустим на этих цифрах — как вы посчитали, что именно это выгодно?
Посчитал я просто. Создал пуассоновский поток клиентов, создал поток коров. Скормил одно другому и посчитал среднюю прибыль. Да, сделал это при разных значениях начального параметра ГСЧ.
Получилось что получилось.
Надеюсь вы понимаете что контрпример нужен один.
Получилось что получилось.
Надеюсь вы понимаете что контрпример нужен один.
А я говорю, что при таких параметрах получается 1.578/3.041. Потому что посчитал.
Если посчитали — как? Формулы, код программы.
Если посчитали — как? Формулы, код программы.
Пока без программы. Вы правы, если снизить интенсивность то поджимает к 0 и начинаешь пропускать клиентов. Но при этом не кормишь коров. Если увеличивать интенсивность то клиентов становится больше, но и приходится кормить коров, которых в наличии становится больше. Почему вы решили что оптимум должен находиться там где скорость поступления коров совпадает со скоростью потока клиентов?
Потому что я предположил, что в среднем выгоднее держать корову на каждого клиента, чем не держать и интенсивность дозаказа коров равна количеству их продажи — это максимальная цифра при которой буфер не будет безконтрольно и постоянно расти вверх.
Конечно, если выгоды от продаж коров нету, то в таких случаях закупки вообще быть не должно.
Таким образом, мы выбираем только клиентов, которых считаем выгодными, продаем только им и заказываем сразу после продажи.
Все, что между этими двумя значениями — исключительно гэмблинг — авось я угадаю, когда выгодно заказать корову.
А почему вы решили взять число 1.16?
Конечно, если выгоды от продаж коров нету, то в таких случаях закупки вообще быть не должно.
Таким образом, мы выбираем только клиентов, которых считаем выгодными, продаем только им и заказываем сразу после продажи.
Все, что между этими двумя значениями — исключительно гэмблинг — авось я угадаю, когда выгодно заказать корову.
А почему вы решили взять число 1.16?
Потому что я ошибся в одном месте (потом исправил) получил несоответсвие и стал подгонять модели. Так обнаружил что в указанном выше примере прибыль больше если заказывать реже.
Есть еще такое соображение, при равномерном заказе у вас будут промахи, когда коровы еще не пришли, а клиенты уже есть. Это дает в среднем вероятность отказа отличную от нуля. Но тогда интенсивность продаж меньше интенсивности прихода клиентов. А значит коров нужно заказывать реже. Заказываете реже, растет вероятность отказа, падает доход, но при этом падают расходы на коровник.
Есть еще такое соображение, при равномерном заказе у вас будут промахи, когда коровы еще не пришли, а клиенты уже есть. Это дает в среднем вероятность отказа отличную от нуля. Но тогда интенсивность продаж меньше интенсивности прихода клиентов. А значит коров нужно заказывать реже. Заказываете реже, растет вероятность отказа, падает доход, но при этом падают расходы на коровник.
Потому что я ошибся в одном месте (потом исправил) получил несоответсвие и стал подгонять модели. Так обнаружил что в указанном выше примере прибыль больше если заказывать реже.
Похоже, что вы ошиблись не в одном месте, а т.к. код свой не показываете — понимаете, что это очень вероятно.
Есть еще такое соображение, при равномерном заказе у вас будут промахи, когда коровы еще не пришли, а клиенты уже есть
Конечно, всегда будут вероятности отказа, если только не с бесконечным буфером.
Но тогда интенсивность продаж меньше интенсивности прихода клиентов. А значит коров нужно заказывать реже
Что? Как у вас получилось вывести второе из первого? У нас недостаточно коров, а значит их нужно заказывать еще меньше?
В случае достаточной наценки нет никакого смысла заказывать коров меньше, чем среднестатистических приход клиента. Регулировать расход на коровник нужно исключительно размером буфера.
Наверное, может и ошибся. Путь к истине он такой извилистый. Сейчас уже точно не пойду перепроверять.
Может быть дело вот в чем… При равных скоростях потоков заказа и клиентов все равно остается вероятность отказов, и зависит она в том числе от среднего размера буфера. Фактически это значит, что поток коров превышает поток продаж. Именно поэтому нельзя заказывать со скоростью потока клиентов, а нужно со скоростью потока продаж. В принципе, это решающий и, по-моему, единственный важный аргумент в пользу заказа по факту продажи. Рассчитать равновесия поток через поток клиентов с учетом вероятности отказов сильно сложнее.
Но я по-моему по прежнему вижу проблему. Похоже, что возникнет положительная обратная связь: больше отказов — меньше заказов; меньше заказов — больше отказов. Хорошо бы сформировать отрицательную обратную связь. Это сильно сложнее, но можно рассчитать, например, оптимальный поток заказов с учетом вероятности отказов из-за конечного буфера. Именно с такой фиксированной скоростью и следует делать равномерный заказ. Это сформирует отрицательную обратную связь. При отказах формируется избыток коров и это влечет уменьшение отказов, что, в свою очередь уменьшает избыток, отчего растут отказы и так все саморегулируется.
Резюмирую гипотезу:
1) заказ по факту продажи формирует положительную обратную связь, ведущую к росту отказов;
2) заказ со скоростью потока клиентов формирует положительную обратную связь, приводящую к постоянному росту буфера;
3) наверно можно вычислить фиксированную скорость заказов, при которой буфер будет в среднем одной длины.
4) наверно можно сформулировать закон адаптивного изменения скорости регулярных заказов на основе текущей статистики процесса, чтобы эта скорость регулировалась отрицательной обратной связью.
Какие ваши соображения, коллеги?
Но я по-моему по прежнему вижу проблему. Похоже, что возникнет положительная обратная связь: больше отказов — меньше заказов; меньше заказов — больше отказов. Хорошо бы сформировать отрицательную обратную связь. Это сильно сложнее, но можно рассчитать, например, оптимальный поток заказов с учетом вероятности отказов из-за конечного буфера. Именно с такой фиксированной скоростью и следует делать равномерный заказ. Это сформирует отрицательную обратную связь. При отказах формируется избыток коров и это влечет уменьшение отказов, что, в свою очередь уменьшает избыток, отчего растут отказы и так все саморегулируется.
Резюмирую гипотезу:
1) заказ по факту продажи формирует положительную обратную связь, ведущую к росту отказов;
2) заказ со скоростью потока клиентов формирует положительную обратную связь, приводящую к постоянному росту буфера;
3) наверно можно вычислить фиксированную скорость заказов, при которой буфер будет в среднем одной длины.
4) наверно можно сформулировать закон адаптивного изменения скорости регулярных заказов на основе текущей статистики процесса, чтобы эта скорость регулировалась отрицательной обратной связью.
Какие ваши соображения, коллеги?
больше отказов — меньше заказов; меньше заказов — больше отказов
Как-то непонятно. У нас есть буфер и (количество коров в буфере+количество заказанных коров) всегда константно. Больше продаж — больше заказов. Отказы, конечно, могут быть, но размером буфера мы балансируем так, чтобы получать максимальную прибыль.
Зачем вы раз за разом все усложняете без причины?
Без причины или нет покажет эксперимент или строгое математическое доказательство. Пока что это все лишь гипотезы и предположения. В ваших рассуждениях выше о балансировке буфером в реальном времени речи не шло. Пояснительная как это мы балансирует буфером. Я очень стараюсь понимать ваш ход мысли. Надеюсь на взаимном там, ибо это может сэкономить время.
Так. Ок. Делаю скрипт для проверки наших гипотез. Нужно обсудить.
В питоновском пакете numpy нашел такую штуку:
Вроде даёт интервалы с мат-ожиданием 100.
Вопроса сразу два:
По второму пункту я полагаю как-то так:
В питоновском пакете numpy нашел такую штуку:
import numpy
print(numpy.random.poisson(100))
Вроде даёт интервалы с мат-ожиданием 100.
Вопроса сразу два:
- Почему оттуда целые числа сыпятся? Я думал там вещественные числа должны быть.
- Как правильно смешивать пуассоновские потоки?
По второму пункту я полагаю как-то так:
- взять из каждого потока по интервалу и отсортировать по неубыванию (сформировать кучу);
- извлечь и выдать минимальный интервал (из вершины кучи) и сгенерировать следующий интервал для потока, чей интервал только что извлекли;
- вычесть извлеченный из всех интервалов кучи;
- поместить новый интервал в кучу;
- повторять бесконечно от пункта 2...
Как и предполагалось, теория сошлась с практикой.
Система эквивалентна системе массового обслуживания с отказами.
Число коров в пуле равно числу коров находящихся на рынке плюс коровы в пути.
Заказывать коров надо по факту продажи, другие идеи не оптимальны.
Система эквивалентна системе массового обслуживания с отказами.
Число коров в пуле равно числу коров находящихся на рынке плюс коровы в пути.
Заказывать коров надо по факту продажи, другие идеи не оптимальны.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
На рынке корову мужик продавал