Оптимальная скорость заказа коров равна средней скорости сбыта этих коров.
Размер буфера:
чем он больше, тем меньше вероятность пропустить клиента, зато больше издержки на корм;
чем он меньше, тем больше вероятность пропустить клиента, но меньше издержки на корм
Очевидно, что заказывать коров надо со средней скоростью сбыта (не больше и не меньше)
Ввиду Пуассоновского процесса наш реальный размер буфера будет топтаться около оптимума время от времени с ненулевой вероятностью то упираясь в ноль, то улетая в плюс. Беда в том, что упираясь в ноль мы теряем клиентов, а вылезая в плюс терпим перерасход на содержание скота.
Закупка следующей скотины только по факту продажи, а не когда пришло среднее время закупки толкает нас к нулю и потере клиентов в худшем случае на одну корову, в среднем на пол коровы (в коровах мы буфер измеряем).
Кстати, размер буфера вполне может быть нецелым. Эта мысль только что пришла. То есть седловая точка может попасть, скажем, на 10.5 коров в буфере. Процесс ламинарный по времени и если отвязать закупку коров от продажи эвентуально, то вполне можно держать дробное кол-во коров в буфере.
наоборот: если в какой-то момент мы накопили избыточный запас коров, для нас любой клиент внезапно становится рентабельным.
Тогда где остановиться? Характер закона распределения не позволяет нам рассчитывать на 100% от пропуска клиента при любом размере буфера. Да, в какой-то момент вероятность пропуска клиента становится столь малой, что можно пренебречь, но есть же и фиксированная цена заказа коровы a, а условие допускает отрицательную маржинальность. Это делает «любого клиента» ой как нерентабельным.
Я так понимаю сути дела наш терминологический спор не меняет. Зачем захламлять тред несущественным гиковским буквоедством? Давайте прекратим.
По существу, как я понял мы сошлись. Тем более в классическом паттерне технической реализации подобных систем с «одновременным» приходом покупателей проблем нет. Если таймштампы у них оказались равны, то обрабатываем их по мере поступления запросов. Надо сильно «постараться», чтобы это стало технической проблемой.
По определению.
Если мы оперируем пуассоновскими определениями, то и события надо рассматривать в математическом смысле.
К тому же по условию задачи длительность обработки события не обсуждалась, посему имеет смысл считать его нулевым, как математическую абстракцию.
Это отдельные понятия. Есть точка и есть интервал. Зачем вводить путаницу подразумевая под первым второе? Пуассоновский процесс оперирует и точками и интервалами в разных смыслах.
кажется, вообще лишены смысла в рамках подобных задач
То, что кажется, нужно оговаривать явно. И нет, не лишены.
Эта вероятность становится заметной только в случае, когда пуассоновских процессов БЕСКОНЕЧНО МНОГО. И то я бы еще подумал над этим. Бесконечности бывают разных порядков.
Подытожу. Математическая точка — это не интервал. Вероятность попадания в конкретную математическую точку строго нулевая, а вот вероятность попадания в отрезок стремящийся по длине к нулю уже не нулевая, а стремящаяся к нулю.
Именно так. Я определяю момент как математическую точку на оси времени. Это никак не интервал. Если коллега считает моментом некий квант машинного времени, который по определению интервал, то нет смысла говорить об идеальном пуассоновском процессе и его нужно квантифицировать.
Короче, похоже, вы правильно указали на рассогласования, просто немного не очевидно выразились. Однако я неоднократно и достаточно явно говорил, что имею в виду под моментом, а retain не говорил, что считает момент интервалом. То, что интервал — это сумма моментов в интегральном смысле верно в любом случае.
Не передергивайте. Я такого не говорил. А вот эти ваши рассуждения:
Ваша ошибка в том, что вы считаете вероятность попадания в заданную математическую точку нулевой (а значит нулевой в любую точку, а значит вероятность попадания в отрезок, который является суммой математических точек — тоже нулевой… Бред.)
ошибочны вот в этой части:
а значит нулевой в любую точку, а значит вероятность попадания в отрезок, который является суммой математических точек — тоже нулевой… Бред.
Нулевая вероятность попадания в конкретную точку. А в любую на заданном отрезке уже не нулевая.
Я, конечно, могу ошибаться, но пока что явные логические нестыковки именно в ваших рассуждениях. Готов спорить.
Если вас смущает разница между «нулевая» и «стремящаяся к нулю при dt->0». То готов согласиться.
Вот лично я ничего не путаю, а использую строго по назначению.
Любое событие происходит мгновенно в момент времени, а пуассоновский процесс определяет вероятность возникновения события на интервале времени. В интервале (любом вещественном диапазоне) бесконечное количество моментов (вещественных точек).
Какая разница? Вероятность случайно дважды попасть в одну вещественную математическую точку строго нулевая. Не важно к каким Пуассоновским или не пуассоновским процессам относятся эти величины. Если угодно, два вещественных случайных числа не равны с вероятностью строго 1.
из-за отсутствия продаж на складе скопилось количество коров выше оптимального.
оптимальное количество не зависит от прошлых продаж/непродаж. Если текущее количество выше/ниже, то его надо вернуть до оптимального.
При любом (!) буфере будут ситуации, когда коров слишком много, и ситуации, когда продавать нечего.
Чувствуете в чем подвох? Если размер буфера больше оптимального, издержки на его содержание растут быстрее, чем прибыль от не упущенных (за счет этого увеличения буфера) клиентов. Если размер буфера меньше оптимального, издержки по статье недополученной прибыли из-за упущенных (из-за этого уменьшения буфера) хороших клиентов будут раст быстрее чем выигрыш (экономия) на прокорме буфера.
Предполагается наличие седловой точки оптимума размера буфера.
Оптимальный размер буфера мы можем в среднем держать за счет установки скорости заказа коров, равной средней скорости сбыта их рентабельным клиентам. Если эта средняя скорость сбыта известна наверняка и точно, то мы всегда будем блуждать около этой точки туда-сюда. Экстренно динамически продавая лишних коров сверх оптимума нерентабельным клиентам вы делаете подстройку только с одной стороны.
Во-первых, почему вы тогда не предлагаете явно дозаказывать динамически коров в ускоренном режиме при перерасходе (то есть когда буфер меньшеоптимального)?
Во-вторых, зачем вообще эта дополнительная инертная обратная связь нужна, когда по условию задачи четко известна средняя скорость сбыта коров? Дёргая динамически буфер туда-сюда, то есть заказывая коров из деревни с непостоянной скоростью и сбывая их иногда нерентабельным клиентам вы лишь уменьшаете добротность системы внося еще один маятник со всеми вытекающими. У нас нет «тренья» в системе и, может быть ваш такой микроменеджмент и не приведёт в среднем ни к профиту ни к издержкам, но зачем усложнять алгоритм?
Полагаю это обосновано было бы только для безопасности на случай внезапного и незадокументированного изменения параметров потока покупателей. А об этом в задаче речи не шло. Потому я и сказал в треде. что на данном этапе хорошо бы уже спуститься в реальность, а не надувать сферического коня в безвоздушном пространстве.
Похоже не платит за еду при доставке. Но, на самом деле, не важно. В случае, если платит,. задача не изменится. Время доставки фиксировано, а значит стоимость еды во время доставки можно заложить в цену коровы.
Формула на самом деле будет еще сложнее, чем кажется, из-за множества категорий клиентов с разной скоростью потоков. Тут можно статистически графики построить оттабулировав настройки. Благо модель не сложная.
Можно заморочиться интегралами и дифурами, конечно, но если задача чисто академиеская, то я лучше спать, а если практическая, то там наверняка не так всё гладко с параметрами потока и лучше сразу строить адативную модель, которая будет инкремнтально уточнять себя по мере накопления данных и даже с учетом их устаревания и инвалидации.
Это тот самый порог, где порой стоит остановиться и решать даьше практическую задачу, вместо сферической в вакууме.
Например, построить график прибыли (упущеной с вероятностью P=const) от размера буфера. И посроить график издержек (с той же зафиксированной вероятностью вероятностью P) от размера буфера. Точка пересечения — идеальный размер с вероятностью P.
Поигравшись с вероятностями и применив волшебные три сигма по гауссу мы получим хорошие показатели.
Именно! И надежность решения растёт. Надо нарисовать графики рисков по упущению и по перерасходу кормёжки от размера буффера. Там, где они пересекутся и будет оптимальный размер.
Простите, не могу комментировать с вашей скоростью, поэтому отвечу здесь.
Я говорю о том, что по факту покупки необходимо покупать сразу корову, все. Продал корову — заказал новую. Если мы сидим с пустым буфером, то значит у нас в заказах уже висит максимальное количество коров. И такое может быть с абсолютно любой выгодной стратегией — пустой буфер, куча коров в ожидании и новый клиент. Вопрос исключительно в том, какой должен быть буфер.
Нельзя заказывать только по факту продажи из-за возможного очень большого лага T. Интуитивно представьте, что наблюдается времнное затишье и покупатели не идут. Если они потом не усилят частоту прихода, значит у нас неверные данные о потоке, а если верные, то потом покупатели пойдут чаще и мы тупо не сформируем лаг. Я настаиваю на том, что данные о потоке однозначно определяют скорость заказов. И это будет работать при любых соотношениях T и среднего времени появления поупателей. А из-за вашего лага придется неоправданно увеличивать буффер терпя издержки на хавчике.
Решение о покупке (покупать или нет) мы делаем только на основе этого состояния, но не того, что было ДО него.
Нам не нужно принимать такие решения по факту покупки. Из-за T, которое может в том числе сильно превышать средний интервал появления клиентов, мы рискуем замешкаться и пропустить покупателей сидя у пустого буфера. При этом мы халатно не используем данные в условии задачи параметры потока клиентов. Вероятностные характеристики потока однозначно определяют скорость наших заказов коров. Попытка рулить онлайн чревата потерями.
По-прежнему настаиваю, что никаких решений онлайн принимать в задаче не надо, если речь идет о достоверно известных параметрах потока (то есть величины генерируются по этим параметрам). Если параметры распределения собраны статистически, то нужно делать предоханители сверху и снизу, а также агрессивную петлю отрицательной обратной связи для борьбы с неполнотой сведений о реальных параметрах случайных величин.
В реальном мире параметры этих случайных величин не могут быть известны достоверно в принципе. А статистика — это заведомо неполная неточная информация.
Никогда не стоит плевать на теорию вероятностей, иначе мы рискуем впасть в азарт и просадить все состояние из-за когнитивных искажений.
Не забывайте, что у нас речь идет о симметричном риске с двух сторон: 1) подержать лишних коров какое-то время на довольствии; 2) пропустить ценного клиента при опустевшем буфере.
Пуассоновский характер поступления покупателей даёт нам понимание, сколько в среднем на большом интервале времени их приходит за единицу времени. Этого (вкупе с прочими параметрами) достаточно, чтобы определить строгую регулярную частоту заказа коров, которая в среднем будет покрывать требования покупателей. Увеличение буфера уменьшает количество упущеных покупателей (недополученная прибыль), зато увеличивает расходы на корм. Уменьшение буфера снижает расходы на корм, зато недополученная прибыль на пропущенных клиентах начнет расти.
С выбраковкой классов тоже не стоит спешить: если все шло как по часам, а затем случайно целый период T не было продаж, то возможно от лишних коров стоит избавится при первой возможности.
Во-первых, надо понимать, насколько адекватно у нас заданы условия. Это, я считаю, важно отметить в описнии задачи. Если характеристики случайных величин верны (например случайные величины специально генерируются с указанными параметрами), то онлайн регулирование не требуется, или требуется, но исключительно калибровочное. Мы можем немножко менять скорость выписывания коров или изредка просто сливать лишних как исключение. Для реального мира эти величины скорее всего взяты из статистики и нам постоянно грозят черные лебеди, неучтенные ошибки и изменения на рынке. В этом случае надо более агрессивно держать оптимальный запас.
В любом случае эти параметры тонкой настройки не гарантируют ничего. Это просто рандомная ставка на риски, те или иные — не важно.
Если же ваши ожидания насчет потока клиентов не оправдываются, действительно не стоит заказывать лишних коров
Мои ожидания по поводу потока клиентов основаны на данных из условий задачи. Это вектор l. Если эти ожидания не оправдываются на долгосрочной перспективе, то это значит лишь, что исходные данные (тот самый вектор) не описывает распределение событий. В этом случае мы должны корректировать вектор (например, уточнять его статистикой), или агрессивно подстраивать поток заказов. Но это уже не будет исходной задачей.
Да и на счет "лишних коров", почему вы однобоко подходите к возможным рискам? А если «неоправдавшиеся ожидания» привели к обратной ситуации и коров не хватило, отчего мы потеряли хороших клиентов и недополучили прибыль? Если скорость пополнения буффера и его размер выбраны верно, а «ожидания» соответствуют характеристикам случайной величины, то риски в ту и другую сторону одинаковы.
Ну а вы в данном случае поддались классическому когнитивному искажению отдавая в плане рисков незаслуженный приоритет тому, что имеете по отношению к тому, что могли бы иметь.
Подчеркну для ясности.
как вы правильно заметили, нужно учитывать, какие коровы уже заказаны и что они придут в будущем.
Я не говорил, что это нужно как-то учитывать онлайн-управлением. Это должно быть учтено автоматически в скорости заказа коров из деревни на основе вероятностных зарактеристик потока покупателей.
Размер буфера:
Очевидно, что заказывать коров надо со средней скоростью сбыта (не больше и не меньше)
Ввиду Пуассоновского процесса наш реальный размер буфера будет топтаться около оптимума время от времени с ненулевой вероятностью то упираясь в ноль, то улетая в плюс. Беда в том, что упираясь в ноль мы теряем клиентов, а вылезая в плюс терпим перерасход на содержание скота.
Закупка следующей скотины только по факту продажи, а не когда пришло среднее время закупки толкает нас к нулю и потере клиентов в худшем случае на одну корову, в среднем на пол коровы (в коровах мы буфер измеряем).
Кстати, размер буфера вполне может быть нецелым. Эта мысль только что пришла. То есть седловая точка может попасть, скажем, на 10.5 коров в буфере. Процесс ламинарный по времени и если отвязать закупку коров от продажи эвентуально, то вполне можно держать дробное кол-во коров в буфере.
По-моему всё вполне интуитивно. А вас, похоже, смущает антропный принцип.
Тогда где остановиться? Характер закона распределения не позволяет нам рассчитывать на 100% от пропуска клиента при любом размере буфера. Да, в какой-то момент вероятность пропуска клиента становится столь малой, что можно пренебречь, но есть же и фиксированная цена заказа коровы a, а условие допускает отрицательную маржинальность. Это делает «любого клиента» ой как нерентабельным.
По существу, как я понял мы сошлись. Тем более в классическом паттерне технической реализации подобных систем с «одновременным» приходом покупателей проблем нет. Если таймштампы у них оказались равны, то обрабатываем их по мере поступления запросов. Надо сильно «постараться», чтобы это стало технической проблемой.
Если мы оперируем пуассоновскими определениями, то и события надо рассматривать в математическом смысле.
К тому же по условию задачи длительность обработки события не обсуждалась, посему имеет смысл считать его нулевым, как математическую абстракцию.
То, что кажется, нужно оговаривать явно. И нет, не лишены.
Подытожу. Математическая точка — это не интервал. Вероятность попадания в конкретную математическую точку строго нулевая, а вот вероятность попадания в отрезок стремящийся по длине к нулю уже не нулевая, а стремящаяся к нулю.
Короче, похоже, вы правильно указали на рассогласования, просто немного не очевидно выразились. Однако я неоднократно и достаточно явно говорил, что имею в виду под моментом, а retain не говорил, что считает момент интервалом. То, что интервал — это сумма моментов в интегральном смысле верно в любом случае.
ошибочны вот в этой части:
Нулевая вероятность попадания в конкретную точку. А в любую на заданном отрезке уже не нулевая.
Я, конечно, могу ошибаться, но пока что явные логические нестыковки именно в ваших рассуждениях. Готов спорить.
Если вас смущает разница между «нулевая» и «стремящаяся к нулю при dt->0». То готов согласиться.
Любое событие происходит мгновенно в момент времени, а пуассоновский процесс определяет вероятность возникновения события на интервале времени. В интервале (любом вещественном диапазоне) бесконечное количество моментов (вещественных точек).
Не «через», а «в течение». Разве нет? Вероятность появления события строго «через» время t по определению нулевая. Потому что dt->0.
Чувствуете в чем подвох? Если размер буфера больше оптимального, издержки на его содержание растут быстрее, чем прибыль от не упущенных (за счет этого увеличения буфера) клиентов. Если размер буфера меньше оптимального, издержки по статье недополученной прибыли из-за упущенных (из-за этого уменьшения буфера) хороших клиентов будут раст быстрее чем выигрыш (экономия) на прокорме буфера.
Предполагается наличие седловой точки оптимума размера буфера.
Оптимальный размер буфера мы можем в среднем держать за счет установки скорости заказа коров, равной средней скорости сбыта их рентабельным клиентам. Если эта средняя скорость сбыта известна наверняка и точно, то мы всегда будем блуждать около этой точки туда-сюда. Экстренно динамически продавая лишних коров сверх оптимума нерентабельным клиентам вы делаете подстройку только с одной стороны.
Во-первых, почему вы тогда не предлагаете явно дозаказывать динамически коров в ускоренном режиме при перерасходе (то есть когда буфер меньшеоптимального)?
Во-вторых, зачем вообще эта дополнительная инертная обратная связь нужна, когда по условию задачи четко известна средняя скорость сбыта коров? Дёргая динамически буфер туда-сюда, то есть заказывая коров из деревни с непостоянной скоростью и сбывая их иногда нерентабельным клиентам вы лишь уменьшаете добротность системы внося еще один маятник со всеми вытекающими. У нас нет «тренья» в системе и, может быть ваш такой микроменеджмент и не приведёт в среднем ни к профиту ни к издержкам, но зачем усложнять алгоритм?
Полагаю это обосновано было бы только для безопасности на случай внезапного и незадокументированного изменения параметров потока покупателей. А об этом в задаче речи не шло. Потому я и сказал в треде. что на данном этапе хорошо бы уже спуститься в реальность, а не надувать сферического коня в безвоздушном пространстве.
Можно заморочиться интегралами и дифурами, конечно, но если задача чисто академиеская, то я лучше спать, а если практическая, то там наверняка не так всё гладко с параметрами потока и лучше сразу строить адативную модель, которая будет инкремнтально уточнять себя по мере накопления данных и даже с учетом их устаревания и инвалидации.
Это тот самый порог, где порой стоит остановиться и решать даьше практическую задачу, вместо сферической в вакууме.
Поигравшись с вероятностями и применив волшебные три сигма по гауссу мы получим хорошие показатели.
Простите, не могу комментировать с вашей скоростью, поэтому отвечу здесь.
Нельзя заказывать только по факту продажи из-за возможного очень большого лага T. Интуитивно представьте, что наблюдается времнное затишье и покупатели не идут. Если они потом не усилят частоту прихода, значит у нас неверные данные о потоке, а если верные, то потом покупатели пойдут чаще и мы тупо не сформируем лаг. Я настаиваю на том, что данные о потоке однозначно определяют скорость заказов. И это будет работать при любых соотношениях T и среднего времени появления поупателей. А из-за вашего лага придется неоправданно увеличивать буффер терпя издержки на хавчике.
Нам не нужно принимать такие решения по факту покупки. Из-за T, которое может в том числе сильно превышать средний интервал появления клиентов, мы рискуем замешкаться и пропустить покупателей сидя у пустого буфера. При этом мы халатно не используем данные в условии задачи параметры потока клиентов. Вероятностные характеристики потока однозначно определяют скорость наших заказов коров. Попытка рулить онлайн чревата потерями.
По-прежнему настаиваю, что никаких решений онлайн принимать в задаче не надо, если речь идет о достоверно известных параметрах потока (то есть величины генерируются по этим параметрам). Если параметры распределения собраны статистически, то нужно делать предоханители сверху и снизу, а также агрессивную петлю отрицательной обратной связи для борьбы с неполнотой сведений о реальных параметрах случайных величин.
В реальном мире параметры этих случайных величин не могут быть известны достоверно в принципе. А статистика — это заведомо неполная неточная информация.
Не забывайте, что у нас речь идет о симметричном риске с двух сторон: 1) подержать лишних коров какое-то время на довольствии; 2) пропустить ценного клиента при опустевшем буфере.
Пуассоновский характер поступления покупателей даёт нам понимание, сколько в среднем на большом интервале времени их приходит за единицу времени. Этого (вкупе с прочими параметрами) достаточно, чтобы определить строгую регулярную частоту заказа коров, которая в среднем будет покрывать требования покупателей. Увеличение буфера уменьшает количество упущеных покупателей (недополученная прибыль), зато увеличивает расходы на корм. Уменьшение буфера снижает расходы на корм, зато недополученная прибыль на пропущенных клиентах начнет расти.
Во-первых, надо понимать, насколько адекватно у нас заданы условия. Это, я считаю, важно отметить в описнии задачи. Если характеристики случайных величин верны (например случайные величины специально генерируются с указанными параметрами), то онлайн регулирование не требуется, или требуется, но исключительно калибровочное. Мы можем немножко менять скорость выписывания коров или изредка просто сливать лишних как исключение. Для реального мира эти величины скорее всего взяты из статистики и нам постоянно грозят черные лебеди, неучтенные ошибки и изменения на рынке. В этом случае надо более агрессивно держать оптимальный запас.
В любом случае эти параметры тонкой настройки не гарантируют ничего. Это просто рандомная ставка на риски, те или иные — не важно.
Мои ожидания по поводу потока клиентов основаны на данных из условий задачи. Это вектор l. Если эти ожидания не оправдываются на долгосрочной перспективе, то это значит лишь, что исходные данные (тот самый вектор) не описывает распределение событий. В этом случае мы должны корректировать вектор (например, уточнять его статистикой), или агрессивно подстраивать поток заказов. Но это уже не будет исходной задачей.
Да и на счет "лишних коров", почему вы однобоко подходите к возможным рискам? А если «неоправдавшиеся ожидания» привели к обратной ситуации и коров не хватило, отчего мы потеряли хороших клиентов и недополучили прибыль? Если скорость пополнения буффера и его размер выбраны верно, а «ожидания» соответствуют характеристикам случайной величины, то риски в ту и другую сторону одинаковы.
Ну а вы в данном случае поддались классическому когнитивному искажению отдавая в плане рисков незаслуженный приоритет тому, что имеете по отношению к тому, что могли бы иметь.
Подчеркну для ясности.
Я не говорил, что это нужно как-то учитывать онлайн-управлением. Это должно быть учтено автоматически в скорости заказа коров из деревни на основе вероятностных зарактеристик потока покупателей.