EternalRain,
Цитата (EternalRain @ 9.2.2019)
БиллиУбили, а почему у тебя не полная колода?
Почему не полная? Какая в данном раскладе осталась, такая и гоняется. В общем случае она равна (полная колода - карты игроков)
Цитата (EternalRain @ 9.2.2019)
И еще один вопрос: почему ты сразу пишешь прогу, не имея полной и четкой схемы алгоритма?
Ну...потому что есть набор методов, которые надо реализовать. Как только получится понять, что они приемлемой сложности(а, значит, обеспечивают приемлемое быстродействие) - можно отладить их на ошибки и переходить к реализации блок-схемы.
По ходу разработки я уже столкнулся с тем, что алгоритм полного, НО ТУПОГО перебора реализовать не удастся(конкретно на моём компе, может супер-комп его и осилит).
Да, можно было прикинуть на бумажке до начала программирования, но я не обладаю достаточной квалификацией. Приходится раз за разом переписывать методы(а в конечном итоге и алгоритмы) в надежде сильно сократить варианты перебора.
2ALL забавный случай произошёл с
и
. Когда я искал руки с конечным вэлью > 0 я предполагал, что в мидл будет максимум 2 пары, ну самый максимум тройка. Однако кол-во комбинаций всё возрастало и возрастало. И тут во время отладки я обнаружил стрит...захотелось протереть глаза, ведь это могло означать, что до этого написанный алгоритм подсчёта очков руки работает с ошибкой(он ошибочно позволяет класть стрит с нарушением старшинства комбинаций снизу вверх). Начал проверять...и буквально сразу наткнулся на...КАРЕ двоек внизу. Что лишний раз доказало,
дельфины умнее людей что прожка не рефлексирует, а действительно считает.
И ещё вопрос по быстродействию/оптимизации. Вот имею я код с 10 сортировками N элементов и 100*N арифметическими операциями. Сложность сортировки - NlogN. Так что оптимизировать в первую очередь?
а) снижать сложность алгоритма сортировки(например, до N)
б) уменьшать кол-во сортировок
в) уменьшать N
А что с арифм. операциями? Они блекнут на фоне сортировки? Или они тоже занимают время, но линейны по N и по этому ими можно пренебречь?
50К готовых рук и 3 подьёма считаются за чуть менее 2 мин. Но кол-во рук доходит до 500К, поэтому таки имеет смысл переписать алгоритм для целых чисел. Чем и занимаюсь
c00l0ne, сейчас на асме вообще почти отпала необходимость писать (за исключением редких случаев), т.к. современные компиляторы достаточно круто оптимизированы.