С выбраковкой классов тоже не стоит спешить: если все шло как по часам, а затем случайно целый период T не было продаж, то возможно от лишних коров стоит избавится при первой возможности.
Во-первых, надо понимать, насколько адекватно у нас заданы условия. Это, я считаю, важно отметить в описнии задачи. Если характеристики случайных величин верны (например случайные величины специально генерируются с указанными параметрами), то онлайн регулирование не требуется, или требуется, но исключительно калибровочное. Мы можем немножко менять скорость выписывания коров или изредка просто сливать лишних как исключение. Для реального мира эти величины скорее всего взяты из статистики и нам постоянно грозят черные лебеди, неучтенные ошибки и изменения на рынке. В этом случае надо более агрессивно держать оптимальный запас.
В любом случае эти параметры тонкой настройки не гарантируют ничего. Это просто рандомная ставка на риски, те или иные — не важно.
Если же ваши ожидания насчет потока клиентов не оправдываются, действительно не стоит заказывать лишних коров
Мои ожидания по поводу потока клиентов основаны на данных из условий задачи. Это вектор l. Если эти ожидания не оправдываются на долгосрочной перспективе, то это значит лишь, что исходные данные (тот самый вектор) не описывает распределение событий. В этом случае мы должны корректировать вектор (например, уточнять его статистикой), или агрессивно подстраивать поток заказов. Но это уже не будет исходной задачей.
Да и на счет "лишних коров", почему вы однобоко подходите к возможным рискам? А если «неоправдавшиеся ожидания» привели к обратной ситуации и коров не хватило, отчего мы потеряли хороших клиентов и недополучили прибыль? Если скорость пополнения буффера и его размер выбраны верно, а «ожидания» соответствуют характеристикам случайной величины, то риски в ту и другую сторону одинаковы.
Ну а вы в данном случае поддались классическому когнитивному искажению отдавая в плане рисков незаслуженный приоритет тому, что имеете по отношению к тому, что могли бы иметь.
Подчеркну для ясности.
как вы правильно заметили, нужно учитывать, какие коровы уже заказаны и что они придут в будущем.
Я не говорил, что это нужно как-то учитывать онлайн-управлением. Это должно быть учтено автоматически в скорости заказа коров из деревни на основе вероятностных зарактеристик потока покупателей.
Потому, что появление покупателя, решение о продаже и сама продажа (или отказ) мгновенны. Время непрерывно и вероятность любого события, из рассматриваемых в задаче, за время, стремящееся к нулю, тоже стремится к нулю. Это значит, что одновременно два покупателя не появятся исходя из самой природы вещей. Всегда кто-то из низ был раньше и всегда между ними ненулевое время.
Вернее как… вероятность того, что между приходами покупателей пройдёт нулевое время — тоже нулевая.
Забавная задачка. Сходу напрашивается ряд «решений», а по зрелому размышлению проявляются интересные нюансы, упрощения и оптимизации.
Первое, что нам нужно для себя решить — это оптимальный размер буфера коров, который мы будем держать в резерве (S*). Очевидно, что оно будет зависеть от всех параметров этой задачи. Давайте отложим нахождение этой величины.
Итак, у нас для каждого случая (прихода покупателя; пронумеруем их по i) есть текущий запас коров S_i. Нам нужно:
1. решить, продавать корову этому покупателю или нет;
2. решить, сколько заказать коров из деревни (может быть 0, заказ-то бесплатный и, как я понял из задания, асинхронный? Поправьте меня, автор, если ошибаюсь).
По поводу второго пункта следует заметить, что акт заказа коров, строго говоря, не должен быть привязан к событиям прихода покупателей, то есть не обязательно должен происходить по факту прихода кого-то из них или по факту продажи. Похоже это тоже будет пуассоновский поток событий, параметр которого будет вычисляться из вероятностей потока покупателей. Если вероятности прихода покупателей рассчитаны (даны) верно, то процесс стационарный и, возможно, не придется даже динамически управлять параметром потока заказов. Вернее эффективнее будет не управлять.
Итак. Декомпозиция выявила три вопроса:
1. Каков оптимальный размер буфера (S*)?
2. Продавать ли корову i-му покупателю?
3. С каким интервалом дозаказывать коров?
Забавно, что в случае идеального пуассоновского процесса нам, скорее всего, можно вообще в самом начале определить какие классы обслуживать, а какие нет. И в начале же определить четко интервал времени дозаказа коровы. Очевидно, что при бесплатном асинхронном заказе нет смысла заказывать больше одной за раз.
Ок. С формулами я сейчас уже не осилю, да и тестовый стенд писать уже лень, но предположу, что мы просто откинем некоторые классы покупателей по рентабельности резервирования для них коровы с учетом среднего времени их появления. Остальным продаём корову из буфера, размер которого будет зависеть от вероятного количества обслуживаемых клиентов за время T.
Возможно следует еще оценить вероятностные характеристики убытка при потере клиента и как-то сравнить их с вероятностными характеристиками убытка от over-резервирования. Но это заметно усложнит формулу расчета глубины резерва.
Резюме. Задача похоже стационарна и не требует онлайн-управления процессом.
По этой рации скорее всего нельзя будет. Частота съедет из-за доплеровского смещения, да и из радиуса действия выскочите слишком быстро. Хотя, если ехать с одинаковой скоростью и в одном направлении…
Вот это я, блин, оригинал, конечно! По существу, конечно можно соединить пару ламп последовательно и никакие их мозги не помешают работать закону Ома для участка цепи. Всё будет хорошо. Но вот вопрос. В таких случаях имеет ли смысл отдавать в сеть именно постоянное напряжение 12 или 24 вольт? Если есть переменное низкое напряжение, будет ли оно эффективнее по сравнению с постоянным? С электрогенератора вполне можно получить ~12 вольт. Профит?
А как сгорят? С искрами и микроядерным взрывом или просто тихо мирно? Это довольно важно, поскольку может быть опасным. Хотя бы со стремянки можно летануть вкручивая, казалось бы, безопасную лампочку. Я, когда светодиодные ввинчиваю, не выключаю зачастую свет вовсе.
Проблемы проблемам рознь. У меня, вот, тоже проблемы со сном: спать хочется, а неплохо было бы ещё поработать. Здорово, наверно, жилось Наполеону. Сколько можно успеть накодить… эх.
Обычные диктофоны не приспособлены к непрерывной записи, зачастую нет привязки записи к реальному времени, иногда нет возможности ставить тегированную временнУю метку, хочется шифрование. Носить с собой постоянно пишущий диктофон без надежного блочного ассиметричного шифрования не безопасно.
Насчет негласного получения информации. По логике вещей, если обычный телефон умеет незаметно записывать звук и он не признаётся устройством негласного получения информации, хотя имеется у каждого первого, то устройство на воротничке с явной пиктограммой микрофона на корпусе (или с корпусом в форме декоративного микрофончика), предназначенное для личных целей аудиофиксации… Короче докопаться можно до чего угодно. Будем надеяться на здравый смысл, иначе самый главный прибор негласного сбора информации — это мозг. За его использование тоже скоро будут сажать?
Не сможет. Если он будет вести запись, то, скорее всего использовать его по назначению будет не удобно, а в некоторых случаях (звонки, музыка) невозможно не ломая функциональность аудио-трекера. Смартфон громоздкий, поэтому придется использовать микрофон-петличку на проводе.
Речь не о том, чтобы иногда записывать что-то. Речь о том, чтобы весь звук вокруг вас был записан.
Звук записывается непрерывно не для того, чтобы потом его слушать, монтировать или анализировать. 99.99% этого звука никто никогда не будет слушать. Представьте, что у вас идеальная память и вы можете вспомнить всё, что слышали; можете порыться в памяти поиском по тегам, можете быстренько вернуться к вчерашнему разговору и вытащить из него номер телефона или адрес, которые не собирались запоминать или использовать. Нет, смартфон не годится.
Какой интересный проект и как вовремя. Только на днях оформил идею на cofounder'е в поисках толкового инженера, умеющего про звук и микроконтроллеры, а вы тут как тут.
Смысл в том, чтобы сделать диктофон, который не требовалось бы включать. То есть он постоянно ведет запись и складывает зашифрованные файлики на флешку. Во время зарядки через USB накопленные данные сливаются в облако. Теги, голосовые метки, индексация распознаванием, текстовый поиск по записям, гистограмма на шкале времени. Думаю на счет BT на борту девайса, чтобы сёрфить по его памяти с телефона в путешествии.
Хочу, чтобы ничего из происходящего вокруг не забывалось и не терялось. Особенно в путешествиях.
Или блютуз поставть и завлекалочкой, или вайфай. Да и с каких пор мы на микроваттах экономим? Во всех приведенных случаях, как мне кажется, трансмиттер можно запитать от солнечной батарейки с ионистором или просто от батарейки. Плакат уже неактуален будет, когда батарейка сядет.
Но тема, кстати,. интересная и полезная. Развивать экономичную электронику надо. Кстати, наши специалисты, похоже, именно этот принцип применили ещё в 1960. Та история про эндовибратор
Вот человек очень правильно сказал. Только я чуть уточню. Пользователь приходит за лампочкой и знает он немножко не то, что сказал комментатор выше. В большинстве кейсов пользователь наверняка знает только одно: куда ему нужно лампочку. Это определяет тип патрона, размер лампочки (форма с учетом радиатора). Обычно это люстры, бра, лампы напольные или настольные, светильники… Теги, даже, пусть, нечеткие по применимости для коллекции ламп были бы очень полезными.
В итоге получается своеобразная экспертная система, которая на выходе даст шорт-топ-лист подходящих вариантов. И вот тут самое интересное. Пользователю надо этот шортлист в виде ссылочки на смартфон или для печати, чтобы с ним зайти по пути в магазин и взять те лампы, которые по его списку будут как можно выше.
Нужно сделать возможность пользователям показывать какие лампочки из представленных где они видели (с гео-меткой). Крупные магазины сразу обрастут флажками и можно будет как-то скорректировать маршрут, чтобы закупиться нормальными лампами. Пусть не идеальными, но нормальными.
Автору спасибо за большое и важное дело.
Хотел было предложить содрать идеи с яндекс-маркета, но заглянул и понял, что они испортились. Раньше у них рядом с названиями характеристик был синий знак вопроса справа от слова, как будто степень 2. При клике выскакивает блок немодальный с расшифровкой термина. Обычный div с абсолютным позиционированием. Своего рода баллон. А вот в хинте картинки лепить и много текста — это действительно не всегда удобно. Они закрывают другие чекбоксы.
Тогда нужно. чтобы все терминалы были прозрачными, иначе неспециалист не поймёт должен именно этот быть таким или нет. Ну и временная это мера, опять же. Клавиатуру можно читать миниатюрной камерой или считывать инфракрасный тепловой след на кнопках, а данные с полосы со временем научатся читать с помощью наклейки размером с почтовую марку на внутренней стороне штатной щели.
ТРИЗ же уже подключили, и комплексное решение, в общем-то, есть. Это упрощенный отзыв транзакции банком, камера на банкомате, двухфакторная авторизация. Из сего этого самое главное — это отмена транзакций. Безопасность таких вещей должна быть проблемой банка, а не пользователя. Нельзя требовать от простого человека, извиняюсь, жопой чуять аутентичность сорта пластика и пропорции щели терминала.
Вот и тема-кандидат для очередного меморандума после истории с гомеопатией. Пора уже усвоить, что шифрование может быть и программное и зашифровать всё что хочешь можно на обычном компе так, что не расшифруешь. В свете всего этого любые препоны при ввозе чего бы то ни было — это лишь алчность бюрократов.
Может быть уже скоро люди с детства будут носить специальные подкожные импланты, устанавливаемые обычным шприцом, которые будут 24*7 обучать нейронную сеть. которая в будущем станет полноценным нейроинтерфейсом для виртуальной реальности. К совершеннолетию сеть научится очень точно сопоставлять активность мозга с тем. что делает тело. При входе в VR достаточно будет просто искусственно обратимо парализовать мышцы, после чего лежи себе и управляй аватаром так, будто ты сам бегаешь и машешь руками. Ощущение ускорения можно получать добавив в ткани вестибулярного аппарата магниточувствительные примеси. Тогда сильное магнитное поле вполне создаст ощущение реальных движений.
Я искренне надеюсь, что это не предупреждающий таймаут для антиГМОшного лобби, чтобы они успели подогнать борзых щенков, которые натолкнут нужных людей на идею выбора более «актуальной» темы для меморандума.
Надеюсь меморандума, всё же будет про ГМО. Верю в здравый смысл и торжество науки. Даёшь хайпу, и чтоб никто не ушел в неведении!
Во-первых, надо понимать, насколько адекватно у нас заданы условия. Это, я считаю, важно отметить в описнии задачи. Если характеристики случайных величин верны (например случайные величины специально генерируются с указанными параметрами), то онлайн регулирование не требуется, или требуется, но исключительно калибровочное. Мы можем немножко менять скорость выписывания коров или изредка просто сливать лишних как исключение. Для реального мира эти величины скорее всего взяты из статистики и нам постоянно грозят черные лебеди, неучтенные ошибки и изменения на рынке. В этом случае надо более агрессивно держать оптимальный запас.
В любом случае эти параметры тонкой настройки не гарантируют ничего. Это просто рандомная ставка на риски, те или иные — не важно.
Мои ожидания по поводу потока клиентов основаны на данных из условий задачи. Это вектор l. Если эти ожидания не оправдываются на долгосрочной перспективе, то это значит лишь, что исходные данные (тот самый вектор) не описывает распределение событий. В этом случае мы должны корректировать вектор (например, уточнять его статистикой), или агрессивно подстраивать поток заказов. Но это уже не будет исходной задачей.
Да и на счет "лишних коров", почему вы однобоко подходите к возможным рискам? А если «неоправдавшиеся ожидания» привели к обратной ситуации и коров не хватило, отчего мы потеряли хороших клиентов и недополучили прибыль? Если скорость пополнения буффера и его размер выбраны верно, а «ожидания» соответствуют характеристикам случайной величины, то риски в ту и другую сторону одинаковы.
Ну а вы в данном случае поддались классическому когнитивному искажению отдавая в плане рисков незаслуженный приоритет тому, что имеете по отношению к тому, что могли бы иметь.
Подчеркну для ясности.
Я не говорил, что это нужно как-то учитывать онлайн-управлением. Это должно быть учтено автоматически в скорости заказа коров из деревни на основе вероятностных зарактеристик потока покупателей.
Вернее как… вероятность того, что между приходами покупателей пройдёт нулевое время — тоже нулевая.
Первое, что нам нужно для себя решить — это оптимальный размер буфера коров, который мы будем держать в резерве (S*). Очевидно, что оно будет зависеть от всех параметров этой задачи. Давайте отложим нахождение этой величины.
Итак, у нас для каждого случая (прихода покупателя; пронумеруем их по i) есть текущий запас коров S_i. Нам нужно:
1. решить, продавать корову этому покупателю или нет;
2. решить, сколько заказать коров из деревни (может быть 0, заказ-то бесплатный и, как я понял из задания, асинхронный? Поправьте меня, автор, если ошибаюсь).
По поводу второго пункта следует заметить, что акт заказа коров, строго говоря, не должен быть привязан к событиям прихода покупателей, то есть не обязательно должен происходить по факту прихода кого-то из них или по факту продажи. Похоже это тоже будет пуассоновский поток событий, параметр которого будет вычисляться из вероятностей потока покупателей. Если вероятности прихода покупателей рассчитаны (даны) верно, то процесс стационарный и, возможно, не придется даже динамически управлять параметром потока заказов. Вернее эффективнее будет не управлять.
Итак. Декомпозиция выявила три вопроса:
1. Каков оптимальный размер буфера (S*)?
2. Продавать ли корову i-му покупателю?
3. С каким интервалом дозаказывать коров?
Забавно, что в случае идеального пуассоновского процесса нам, скорее всего, можно вообще в самом начале определить какие классы обслуживать, а какие нет. И в начале же определить четко интервал времени дозаказа коровы. Очевидно, что при бесплатном асинхронном заказе нет смысла заказывать больше одной за раз.
Ок. С формулами я сейчас уже не осилю, да и тестовый стенд писать уже лень, но предположу, что мы просто откинем некоторые классы покупателей по рентабельности резервирования для них коровы с учетом среднего времени их появления. Остальным продаём корову из буфера, размер которого будет зависеть от вероятного количества обслуживаемых клиентов за время T.
Возможно следует еще оценить вероятностные характеристики убытка при потере клиента и как-то сравнить их с вероятностными характеристиками убытка от over-резервирования. Но это заметно усложнит формулу расчета глубины резерва.
Резюме. Задача похоже стационарна и не требует онлайн-управления процессом.
Насчет негласного получения информации. По логике вещей, если обычный телефон умеет незаметно записывать звук и он не признаётся устройством негласного получения информации, хотя имеется у каждого первого, то устройство на воротничке с явной пиктограммой микрофона на корпусе (или с корпусом в форме декоративного микрофончика), предназначенное для личных целей аудиофиксации… Короче докопаться можно до чего угодно. Будем надеяться на здравый смысл, иначе самый главный прибор негласного сбора информации — это мозг. За его использование тоже скоро будут сажать?
Речь не о том, чтобы иногда записывать что-то. Речь о том, чтобы весь звук вокруг вас был записан.
Звук записывается непрерывно не для того, чтобы потом его слушать, монтировать или анализировать. 99.99% этого звука никто никогда не будет слушать. Представьте, что у вас идеальная память и вы можете вспомнить всё, что слышали; можете порыться в памяти поиском по тегам, можете быстренько вернуться к вчерашнему разговору и вытащить из него номер телефона или адрес, которые не собирались запоминать или использовать. Нет, смартфон не годится.
Смысл в том, чтобы сделать диктофон, который не требовалось бы включать. То есть он постоянно ведет запись и складывает зашифрованные файлики на флешку. Во время зарядки через USB накопленные данные сливаются в облако. Теги, голосовые метки, индексация распознаванием, текстовый поиск по записям, гистограмма на шкале времени. Думаю на счет BT на борту девайса, чтобы сёрфить по его памяти с телефона в путешествии.
Хочу, чтобы ничего из происходящего вокруг не забывалось и не терялось. Особенно в путешествиях.
Но тема, кстати,. интересная и полезная. Развивать экономичную электронику надо. Кстати, наши специалисты, похоже, именно этот принцип применили ещё в 1960. Та история про эндовибратор
В итоге получается своеобразная экспертная система, которая на выходе даст шорт-топ-лист подходящих вариантов. И вот тут самое интересное. Пользователю надо этот шортлист в виде ссылочки на смартфон или для печати, чтобы с ним зайти по пути в магазин и взять те лампы, которые по его списку будут как можно выше.
Нужно сделать возможность пользователям показывать какие лампочки из представленных где они видели (с гео-меткой). Крупные магазины сразу обрастут флажками и можно будет как-то скорректировать маршрут, чтобы закупиться нормальными лампами. Пусть не идеальными, но нормальными.
Автору спасибо за большое и важное дело.
ТРИЗ же уже подключили, и комплексное решение, в общем-то, есть. Это упрощенный отзыв транзакции банком, камера на банкомате, двухфакторная авторизация. Из сего этого самое главное — это отмена транзакций. Безопасность таких вещей должна быть проблемой банка, а не пользователя. Нельзя требовать от простого человека, извиняюсь, жопой чуять аутентичность сорта пластика и пропорции щели терминала.
Надеюсь меморандума, всё же будет про ГМО. Верю в здравый смысл и торжество науки. Даёшь хайпу, и чтоб никто не ушел в неведении!