Так же развлекался в детстве) если хотите немного углубиться и улучшить подходы в этом то я бы посоветовал бы углубиться в паттерны автотестирования - можно взять очень много идей и настройку боту сделать гораздо более удобной. как минимум уйдете от попиксельных перемещений мышки
какое-то время тоже так считал, пока не проскочили мимо меня сеньоры которые не умели кодить. т.е у них был настолько прокачан скилл проходить интервью, что они прошли входное интервью, фит интервью в аккаунт, фит интервью от иностранного клиента. и только через месяц на проекте выяснилось что человек то код писать и не умеет. ]]если думаете что слишком много интервью то вы ошибаетесь. после первого его приняли в компанию и остальные были в качестве сотрудника.
не задаю такие вопросы т.к. уровень освоения знания после книг очень маленький. иногда проверяю читал ли человек документацию и в каком объеме по очень попсовым вещам.
давайте возьмем коэффициенты при б\м 4.5 фактически коэффициенты равные и букмекеры дают равные вероятности на эти исходы и имеют свою маржу в 5 процентов. вот эти 5 процентов и есть допустимая погрешность модели букмекера, при которой он не получит убытка. другими словами - ваша модель должна быть минимум на 5 процентов лучше чем модель букмекера. в современном мире это практически невозможно) это с одной стороны с другой стороны - в ход идет балансировка коэффициентов в зависимости от загрузки на каждую группу коэффициентов - это уже элементы рискменджмента, вплоть до того что фавориты могут поменяться.
касаемо предположения о том что ваш подход на расстоянии уйдет в ноль.минус - дерзайте, если ваша модель лучше то, у меня были случаи, что просто модель игрока выкупали и внедряли к себе, или нанимали автора на работу)
работал со стороны букмекера над этим. Автор - молодец, и рассказал в принципе все так как и есть в реальности. единственно что могу сказать что бороться системно с букмекером не имеет смысла. Модель у букмекера практически всегда примерно равна модели у игрока, но у букмекера есть его маржа - фактически допустимая ошибка в своих предсказаниях. Мой совет - используйте букмекеров не для заработка, а для того чтобы с большим удовольствием смотреть спорт. и ставьте на команду за которую не болеете - если проиграете то вы будете счастливы что ваша команда победила. если выиграете - то хоть пиво с горя купите из-за того что ваша команда проиграла)
Давно на смотрел на практические либы в этой теме но их развитие вполне предсказуемо - вместо того чтобы сложным образом строить метки - готовим сразу, предрасчитваем и потом осуществляем просто детектирование.
А вы сами пробовали переопределять метки, алгоритмы детекции, описания итд?
Обожаю такие задачи, а самое главное они дают гигантский value компании, которые заказали и используют такие. я попробую описать проблемы, с которыми я сталкивался решаю такие задачи:
1) иллюзия что программа должна работать быстро — на самом деле если время расчета программы будет несколько дней, но это поможет рассчитать более оптимальные маршруты то смело используйте это время
2) четко сформулируйте в математических терминах что дано на входе, и что вы хотите получить. для каждой NP задачи существуют свои пути оптимизации и приемы, как нужно думать для решения. Вы же пошли стандартным путем, который дал неплохие результаты, но, готов поспорить, не идеальные результаты. для меня меня задача звучит следующим образом: Разбиение графа на подграффы с ограниченной суммой ребер. и это уже не коммивояжер. Или зайти в геометрию и искать начало фигур, чтобы их длина соответствовала условиям задачи, что тоже нас приводит к другой задаче
3) Метрики — на первый взгляд у вас все хорошо, а на второй — думать надо))
4) не стесняйтесь применить методы со случайностями — вероятностные методы, метод монте-карло
5) проделайте составление рассписания руками — это помогает зачастую нащупать правильную идею для успешного решения.
p.s. я бы для решения такой задачи брал бы около 4-5 месяцев на небольшую команду, но мог бы гарантировать дотаточно хорошее приближение к идеальному решению.
адекватно расписали) сохраню и буду показывать нанимателям, когда они будут возмущаться моей ставке на фрилансе, которой больше моей постоянной рабочей в 2.5 раза.
При просмотре кода в статье такие же мысли возникли) смысл того, что назвали «некрасивым, плохо расширяемым итд», дошел сразу, а то как предложили оптимизировать — пришлось напрячься
немного намудрили, но по сути вы используете устоявшийся практики, которые я опишу чуть нижу:
1) merge strategy — классическая стратегия для многих проектов
2) rebase strategy — у вас под 5 пуктом идет
используете стратегии которые прописаны прямо в документации
3) feature-branch — известный всем подход, только вы немного добавляете в него наименования… я бы посоветовал ветки называть в соответсвии с именованием тасков в жире или другой системе.
4) использование tag для минорных и мажорных версий — тоже стандартный подход.
Есть несколько вопросов:
1) сколько по времени от начала и до завершения проекта? и если есть возможность то временные рамки этапов (сбор данных, разметка, итд)
2) система банит автоматом или подсовывает оператору видео и тот уже принимает решение?
Являюсь research lead и впринципе согласен практически со всем что написано. Но есть у меня личные наработки:
1) дважды в неделю команда рассказывает подробно свои успехи за период. На этой мини конфе мы фактически заполняем квадрат, только это делает команда целиком
2) исследования в ширину — на каждую задачу формируется список научных работ и проверяются все методы описанные в работах. Потом к первому пункту обращаемся и делаем вполне себе точный прогноз на решение задачи
3) приоритет на алгоритмы, а не на нейронки. Всё-таки нейронки пока являются жутким черным ящиком и предсказать их результат можно только по верхней границе( не лучше чем разметка). Плюс если решение на алгоритмах то есть техники которые позволяют делать очень тонкие настройки.
У меня такое ощущение что вы переоткрываете Gherkin
Так же развлекался в детстве)
если хотите немного углубиться и улучшить подходы в этом то я бы посоветовал бы углубиться в паттерны автотестирования - можно взять очень много идей и настройку боту сделать гораздо более удобной. как минимум уйдете от попиксельных перемещений мышки
1) вы пропустили букву "т"
2) с вашей формулировкой тоже норм - гейкипер занимается тем чтобы разные нехорошие люди в компанию не попали
какое-то время тоже так считал, пока не проскочили мимо меня сеньоры которые не умели кодить. т.е у них был настолько прокачан скилл проходить интервью, что они прошли входное интервью, фит интервью в аккаунт, фит интервью от иностранного клиента. и только через месяц на проекте выяснилось что человек то код писать и не умеет.
]]если думаете что слишком много интервью то вы ошибаетесь. после первого его приняли в компанию и остальные были в качестве сотрудника.
не задаю такие вопросы т.к. уровень освоения знания после книг очень маленький. иногда проверяю читал ли человек документацию и в каком объеме по очень попсовым вещам.
Это только затравочная статья. в дальнейшем разберу уровни сложности вопросы, как правильно их составлять итд.
Готов поспорить что по факту задания ну очень простые, которые требуют адекватности совсем чуть-чуть.
И самое удивительное что такой подход в глазах общественности неимоверно усложняет процесс
В программировании есть концепция акторов. на мой взгляд эта идея акторов и EventModeling перекликаются чуть менее чем полностью.
давайте возьмем коэффициенты при б\м 4.5 фактически коэффициенты равные и букмекеры дают равные вероятности на эти исходы и имеют свою маржу в 5 процентов.
вот эти 5 процентов и есть допустимая погрешность модели букмекера, при которой он не получит убытка.
другими словами - ваша модель должна быть минимум на 5 процентов лучше чем модель букмекера. в современном мире это практически невозможно)
это с одной стороны
с другой стороны - в ход идет балансировка коэффициентов в зависимости от загрузки на каждую группу коэффициентов - это уже элементы рискменджмента, вплоть до того что фавориты могут поменяться.
касаемо предположения о том что ваш подход на расстоянии уйдет в ноль.минус - дерзайте, если ваша модель лучше то, у меня были случаи, что просто модель игрока выкупали и внедряли к себе, или нанимали автора на работу)
работал со стороны букмекера над этим.
Автор - молодец, и рассказал в принципе все так как и есть в реальности.
единственно что могу сказать что бороться системно с букмекером не имеет смысла. Модель у букмекера практически всегда примерно равна модели у игрока, но у букмекера есть его маржа - фактически допустимая ошибка в своих предсказаниях.
Мой совет - используйте букмекеров не для заработка, а для того чтобы с большим удовольствием смотреть спорт. и ставьте на команду за которую не болеете - если проиграете то вы будете счастливы что ваша команда победила. если выиграете - то хоть пиво с горя купите из-за того что ваша команда проиграла)
Давно на смотрел на практические либы в этой теме но их развитие вполне предсказуемо - вместо того чтобы сложным образом строить метки - готовим сразу, предрасчитваем и потом осуществляем просто детектирование.
А вы сами пробовали переопределять метки, алгоритмы детекции, описания итд?
1) иллюзия что программа должна работать быстро — на самом деле если время расчета программы будет несколько дней, но это поможет рассчитать более оптимальные маршруты то смело используйте это время
2) четко сформулируйте в математических терминах что дано на входе, и что вы хотите получить. для каждой NP задачи существуют свои пути оптимизации и приемы, как нужно думать для решения. Вы же пошли стандартным путем, который дал неплохие результаты, но, готов поспорить, не идеальные результаты. для меня меня задача звучит следующим образом: Разбиение графа на подграффы с ограниченной суммой ребер. и это уже не коммивояжер. Или зайти в геометрию и искать начало фигур, чтобы их длина соответствовала условиям задачи, что тоже нас приводит к другой задаче
3) Метрики — на первый взгляд у вас все хорошо, а на второй — думать надо))
4) не стесняйтесь применить методы со случайностями — вероятностные методы, метод монте-карло
5) проделайте составление рассписания руками — это помогает зачастую нащупать правильную идею для успешного решения.
p.s. я бы для решения такой задачи брал бы около 4-5 месяцев на небольшую команду, но мог бы гарантировать дотаточно хорошее приближение к идеальному решению.
в данном случае метрика должна быть определена следующим образом:
сумма выигрышей/сумма поставленных денег
1) merge strategy — классическая стратегия для многих проектов
2) rebase strategy — у вас под 5 пуктом идет
используете стратегии которые прописаны прямо в документации
3) feature-branch — известный всем подход, только вы немного добавляете в него наименования… я бы посоветовал ветки называть в соответсвии с именованием тасков в жире или другой системе.
4) использование tag для минорных и мажорных версий — тоже стандартный подход.
новое что предлагаете?
1) сколько по времени от начала и до завершения проекта? и если есть возможность то временные рамки этапов (сбор данных, разметка, итд)
2) система банит автоматом или подсовывает оператору видео и тот уже принимает решение?
Являюсь research lead и впринципе согласен практически со всем что написано. Но есть у меня личные наработки:
1) дважды в неделю команда рассказывает подробно свои успехи за период. На этой мини конфе мы фактически заполняем квадрат, только это делает команда целиком
2) исследования в ширину — на каждую задачу формируется список научных работ и проверяются все методы описанные в работах. Потом к первому пункту обращаемся и делаем вполне себе точный прогноз на решение задачи
3) приоритет на алгоритмы, а не на нейронки. Всё-таки нейронки пока являются жутким черным ящиком и предсказать их результат можно только по верхней границе( не лучше чем разметка). Плюс если решение на алгоритмах то есть техники которые позволяют делать очень тонкие настройки.