Неужели есть такие, кому это было не очевидно после дочитывания условий разводчика? Элементарно же. Играют на математической неграмотности и «неинтуитивности» роста экспоненты. Хотя любому, закончившему хотя бы 9 классов, вроде уже должно быть понятно, как растёт экспонента.
Несколько замечаний по поводу алгоритма: всё таки интересно получить более менее реальное «среднее» значение угаданных карт. И да — реальное != максимальное, т.е. не надо пытаться максимизировать эту цифру. У вас совершенно необоснованный критерий со счётчиком, который вряд ли адекватно оценивает вероятность выбора.
Мне видится такой алгоритм: изначально есть множество, состоящее из 52 карт. Будем на каждом шаге извлекать некую случайную карту из множества (в множестве только те карты, которые остались). Можно, например, извлекать всегда первую карту, предварительно случайно переставляя карты (нетрудно понять, что от этого ничего не измениться). Так мы получим равномерное распределение выбора цвета карты. Чтобы было проще написать алгоритм, лучше перейти к эквивалентной задаче — будем идти с конца, каждый раз генерируя равномерную случайную перестановку на префиксе. Будем считать, что последний элемент на префиксе (обозначим его номером K) мы выбираем. Посчитаем, сколько карт мы угадали, сравнивая, что стоит K-ой позиции колоды (колоду, естественно, тоже нужно предварительно перемешать). Получился лаконичный и красивый алгоритм:
1. Перемешиваем множество из 52 карт случайным образом — назовём это «колодой».
2. Создаём новое множество, состоящее из 52 карт — назовём это «множество A».
3. Делаем цикл по элементам множества A (массиву, фактически). Пусть мы на I-том шаге. Нам нужно, чтобы на префиксе A[0..I] была случайная перестановка. Это элементарно делается алгоритмом Фишера-Йетса. Скажем, что мы вибираем карту номер I (нетрудно заметить, что она будет случайной). Сравниваем цвет I-ого элемента из A и из «колоды».
И последнее: для таких задач лучше не пользоваться стандартными функциями вроде shuffle. Вполне вероятно, что там хороший алгоритм, а что если нет? Это ведь может сказаться на результате. Я бы не стал доверять shuffle, и реализовал метод Фишера-Йетса, благо пишется он в 3 строчки.
Да, это же теория графов, она частенько бывает полезна. Ее даже можно назвать теоретическим минимумом для программиста. Я же говорю про теоретико-числовые алгоритмы, которые вообще непонятно как применять на практике. Можно решать только специально выдуманные задачи, т.е. «задача ради задачи».
Ну а в целом я с вами согласен, алгоритмы нужно знать и уметь применять.
По мне, так это как раз не очень показательный пример :) Многие скажут: «Как мне это пригодиться на практике?», т.к. вряд ли большинство программистов сталкивается с реализацией теоретико-числовых алгоритмов (за исключением людей, которые занимаются криптографией). Гораздо лучше смотрелась бы задачка на нестандартную структуру данных.
А вообще, программирование — частный случай алгоритмистики, которая, в свою очередь, частный случай дискретной математики.
Просто работать надо было с большими перерывами. Например: 1 день работает, неделю отдых. И по ночам не работать (зачем?). В остальные промежутки других людей нанимать. И психологическую разгрузку давать.
Конкретно в этом случае, вряд ли тот, кому это нравится, будет работать лучше. Чем больше «двинут» человек, тем сложнее ему будет определять грань между плохим контентом и хорошим.
Вывод 1. Родив ребёнка, вы становитесь предком всего человечества.
Это утверждение не совсем верно. Верно так:
Вывод 1. Родив ребёнка, вы становитесь предком всего человечества, при условии, что хотя бы один потомок на каждом уровне родства продолжит свою линию.
Как бы мне не хотелось это говорить, но вы абсолютно правы :) Особенно обидно, когда качественные статьи из хаба алгоритмы не могут и 20 голосов набрать, а вот такие вот спокойно набирают 50+. Печально всё это. Скоро уже начнут тупые паблики из контакта постить.
> Надежнее точно не будет.
Практика показывает обратное.
> Вы же не думаете что ваш велосипед кому то будет приятнее читать чем код STL?
Никто и не будет читать, кроме тех, кто разрабатывал непосредственно сам велосипед. Ведь команда пишет велосипед только для себя.
> может(но только при корректной реализации) быть быстрее за счет удаления неиспользуемых уровней абстракции.
Да, причём значительно быстрее в отдельных местах.
Потому что я заранее знаю, для каких задач будет использоваться велосипед, и пишу так, как надо мне, в отличие от разработчиков библиотек, которые стараются угодить большинству. Я реализовываю ровно то, что мне нужно. Даже если в моём велосипеде будет больше багов, сама система в целом будет работать надёжнее, за счёт того, что все функции используются по назначению. Само собой, если я годами пользовался какой-то библиотекой и она на все 100% удовлетворяет моим потребностям, я буду пользоваться ей, свой велосипед писать было бы глупо.
Вот поэтому я и не люблю stl. Когда все написано самостоятельно, таких проблем не возникает. Главное хорошо документировать свои велосипеды, и все будет в шоколаде.
И ещё:
тут я имел в виду, что мы будем не извлекать карты из множества, а наоборот, добавлять.
Несколько замечаний по поводу алгоритма: всё таки интересно получить более менее реальное «среднее» значение угаданных карт. И да — реальное != максимальное, т.е. не надо пытаться максимизировать эту цифру. У вас совершенно необоснованный критерий со счётчиком, который вряд ли адекватно оценивает вероятность выбора.
Мне видится такой алгоритм: изначально есть множество, состоящее из 52 карт. Будем на каждом шаге извлекать некую случайную карту из множества (в множестве только те карты, которые остались). Можно, например, извлекать всегда первую карту, предварительно случайно переставляя карты (нетрудно понять, что от этого ничего не измениться). Так мы получим равномерное распределение выбора цвета карты. Чтобы было проще написать алгоритм, лучше перейти к эквивалентной задаче — будем идти с конца, каждый раз генерируя равномерную случайную перестановку на префиксе. Будем считать, что последний элемент на префиксе (обозначим его номером K) мы выбираем. Посчитаем, сколько карт мы угадали, сравнивая, что стоит K-ой позиции колоды (колоду, естественно, тоже нужно предварительно перемешать). Получился лаконичный и красивый алгоритм:
1. Перемешиваем множество из 52 карт случайным образом — назовём это «колодой».
2. Создаём новое множество, состоящее из 52 карт — назовём это «множество A».
3. Делаем цикл по элементам множества A (массиву, фактически). Пусть мы на I-том шаге. Нам нужно, чтобы на префиксе A[0..I] была случайная перестановка. Это элементарно делается алгоритмом Фишера-Йетса. Скажем, что мы вибираем карту номер I (нетрудно заметить, что она будет случайной). Сравниваем цвет I-ого элемента из A и из «колоды».
И последнее: для таких задач лучше не пользоваться стандартными функциями вроде shuffle. Вполне вероятно, что там хороший алгоритм, а что если нет? Это ведь может сказаться на результате. Я бы не стал доверять shuffle, и реализовал метод Фишера-Йетса, благо пишется он в 3 строчки.
Ну а в целом я с вами согласен, алгоритмы нужно знать и уметь применять.
А вообще, программирование — частный случай алгоритмистики, которая, в свою очередь, частный случай дискретной математики.
Это утверждение не совсем верно. Верно так:
Вывод 1. Родив ребёнка, вы становитесь предком всего человечества, при условии, что хотя бы один потомок на каждом уровне родства продолжит свою линию.
Практика показывает обратное.
> Вы же не думаете что ваш велосипед кому то будет приятнее читать чем код STL?
Никто и не будет читать, кроме тех, кто разрабатывал непосредственно сам велосипед. Ведь команда пишет велосипед только для себя.
> может(но только при корректной реализации) быть быстрее за счет удаления неиспользуемых уровней абстракции.
Да, причём значительно быстрее в отдельных местах.