Здесь, по-видимому, сыграл роль принцип работы рекрутинговых агентств: создаётся несколько вакансий, таргетирующих какой-то определённый стек. Эти вакансии в свою очередь приводят к одному и тому же заданию, в котором стек обозначен как свободный.
Благодарю за ответ. Интересно было бы узнать о результатах эксперимента, если вдруг решите попробовать. Интуитивно кажется, что данных ваших выборок должно было бы хватить для обучения с нуля.
Спасибо за статью. Возможно, задам глупый вопрос, но интересно, какую роль играет «предобученность» модели в вашем дообучении? Не будут ли результаты похожими, если обучать шахматам модель с аналогичной архитектурой с нуля?
Если убрать предположение о том, что игроки будут считать секунды, и добавить возможность ходить по очереди и передвигать чужие карты на столе, то можно выработать алгоритм, когда игроки будут перекладывать свою карту перед чужой «100 — N — R» раз, где R — ранг карты, а N — количество оставшихся в руке карт.
Например, у меня есть карты H1 = 10, H2 = 50 и H3 = 90.
У оппонента карты O1 = 20, O2 = 40 и O3 = 95.
Я выбираю минимальную карту H1 и кладу на стол.
Оппонент кладёт карту O1 перед моей H1 (это действие необходимо, и говорит мне о том, что O1 <= 97).
Я снова переклаываю H1 перед O1, сообщая ему, что H1 <= 96.
Таким образом мы поочерёдно меняем местами H1 и O1 суммарно ещё 76 раз. К этому моменту H1 окажется перед O1, что скажет моему оппоненту, что H1 <= 20.
На этот раз вместо перестановки H1 и O1 оппонент кладёт новую карту O2, что говорит мне о том, что O1 = 20.
Я кладу H2 перед O2, давая понять оппоненту, что H2 <= 98.
Мы снова поочерёдно меняем местами H2 и O2 49 раз, и последний ход оппонента говорит мне о том, что O2 < 50.
Это означает, что я должен положить H3.
Оппонент кладёт O3 перед H3. Это значит, что O3 <= 99.
Мы перекладываем карты еще 5 раз, после чего мой оппонент понимает, что H3 < 95 и объявляет о завершении игры.
Это был абстрактный пример. Всё сильно зависит от конкретной задачи и многих факторов, например, публичный ли это API или внутренний. Разные версии могут быть определены ветками или тегами, это не принципиально. Prestable это чаще всего не «прод», а staging. В каких-то случаях это может быть alpha или beta. Стратегии релизов и поддержки обратной совместимости также специфичны для разных проектов.
Именно поэтому как раз очень важно нахождение спецификации рядом с кодом и совместное версионирование, вкупе с CI.
Большого количества версий быть не должно. В общем случае оно должно соответствовать количеству доступных для пользателей версий API, и обычно их не так много: например, stable и prestable. Хранятся эти версии обычно в разных ветках, так что сложностей не возникает.
Дело не только в необходимости как-то сгенерировать документацию. Наличие спецификации как таковой даёт большое количество плюсов в разработке и тестировании, примеры которых приводятся в статье.
Генерироваться из чего? Если имеется ввиду сам код, то на практике это вряд ли реализуемо, учитывая возможную специфику реализации компонентов (роутов, экшнов и т.п.), а также всё множество различных технологий и фреймворков.
Вообще первичной должна быть все же спецификация, которая затем «имплементируется» в виде кода.
А какие проблемы вы видите с версионированием? В нескольких реальных проектах в течение продолжительного времени используем этот подход без каких-либо проблем.
Смотря, о какой проблеме вы говорите. О том, что Swagger сложный или о том что «GraphQL лучше REST»? Во втором случае, боюсь, мы скатимся к очередной религиозной дискуссии, чего бы не хотелось.
Я вроде бы всегда слышал, что продвигать можно только одновременно с запуском, и что Apple считает инсталлы в первые три дня после релиза. Это разве не так?
Кстати на счёт графика. За 1 этап «предрелизная подготовительная работа» вы набрали ~10K установок. Это как понимать? То есть релиз уже был, но рекламную кампанию вы начинали не сразу?
Здесь, по-видимому, сыграл роль принцип работы рекрутинговых агентств: создаётся несколько вакансий, таргетирующих какой-то определённый стек. Эти вакансии в свою очередь приводят к одному и тому же заданию, в котором стек обозначен как свободный.
Благодарю за ответ. Интересно было бы узнать о результатах эксперимента, если вдруг решите попробовать. Интуитивно кажется, что данных ваших выборок должно было бы хватить для обучения с нуля.
Кстати, ваш сайт https://chess.meanotek.ru/ недоступен, просьба вернуть :)
Спасибо за статью. Возможно, задам глупый вопрос, но интересно, какую роль играет «предобученность» модели в вашем дообучении? Не будут ли результаты похожими, если обучать шахматам модель с аналогичной архитектурой с нуля?
Например, у меня есть карты H1 = 10, H2 = 50 и H3 = 90.
У оппонента карты O1 = 20, O2 = 40 и O3 = 95.
Я выбираю минимальную карту H1 и кладу на стол.
Оппонент кладёт карту O1 перед моей H1 (это действие необходимо, и говорит мне о том, что O1 <= 97).
Я снова переклаываю H1 перед O1, сообщая ему, что H1 <= 96.
Таким образом мы поочерёдно меняем местами H1 и O1 суммарно ещё 76 раз. К этому моменту H1 окажется перед O1, что скажет моему оппоненту, что H1 <= 20.
На этот раз вместо перестановки H1 и O1 оппонент кладёт новую карту O2, что говорит мне о том, что O1 = 20.
Я кладу H2 перед O2, давая понять оппоненту, что H2 <= 98.
Мы снова поочерёдно меняем местами H2 и O2 49 раз, и последний ход оппонента говорит мне о том, что O2 < 50.
Это означает, что я должен положить H3.
Оппонент кладёт O3 перед H3. Это значит, что O3 <= 99.
Мы перекладываем карты еще 5 раз, после чего мой оппонент понимает, что H3 < 95 и объявляет о завершении игры.
Именно поэтому как раз очень важно нахождение спецификации рядом с кодом и совместное версионирование, вкупе с CI.
Большого количества версий быть не должно. В общем случае оно должно соответствовать количеству доступных для пользателей версий API, и обычно их не так много: например,
stableиprestable. Хранятся эти версии обычно в разных ветках, так что сложностей не возникает.Генерироваться из чего? Если имеется ввиду сам код, то на практике это вряд ли реализуемо, учитывая возможную специфику реализации компонентов (роутов, экшнов и т.п.), а также всё множество различных технологий и фреймворков.
Вообще первичной должна быть все же спецификация, которая затем «имплементируется» в виде кода.
А какие проблемы вы видите с версионированием? В нескольких реальных проектах в течение продолжительного времени используем этот подход без каких-либо проблем.
github.com/Homebrew/homebrew/issues/29763
Кто-нибудь сталкивался?
Подскажите, пожалуйста, это за какой период? За тот же день?