Пилю программку по обсчёту китайского покера

В качестве факультатива учу с++, выше видели, ох как сложно тестироваться, компиляторы выкидывают просто не используемый код... отсюда непонятные результаты... 

У кого есть intel современный и возможность потратить часок два, приблизительно в это время... погонять тест...

visual studio 2022 нужна будет а дальше подскажу...

интересует 11-12 поколение

не обязательно топовые i9

Ну чего то тема стухла, на чем там остановились, индексацию надо , надо любой борд, любую ситуацию в игре научиться отображать в уникальный индекс. Как вариант лукап табличку сделать гигантскую, так же предлагайте ваши варианты господа программисты...

Почему это сложно, допустим верх представим в битовом пространстве 39 битным числом, где первые 13 бит первая карта, вторые тринадцать бит вторая и с 26-39 бит третья. Это ламерский способ, предлагайте варианты, у кого есть какие мысли. Цель, сэкономить максимум памяти, например чтобы хранить хистори игровые...

Основная проблема 39 бит в том что используется только три бита за раз а остальные "простаивают"

c00l0ne @ 28.10.22 

Основная проблема 39 бит в том что используется только три бита за раз а остальные "простаивают"

Потому можно использовать 4 бита на карту вместо 13ти.

А если с мастями, то 6 бит охватит всю колоду. ( в 6 бит влазит число от 0 до 63, колода + джокеры)

Jak, получается чтобы сохранить стартера нужно индекс стартера и номер хода ,  пусть четыре байта храним на стартер, то понадобится , на стартер нужно 4бита*5 карт

8 мегабайт кек

Ну это уже хорошие новости

Для джокеров: 9 гб

Это без учёта мастей

Jak @ 28.10.22 

А если с мастями, то 6 бит охватит всю колоду. ( в 6 бит влазит число от 0 до 63, колода + джокеры)

Тоже есть минусы, порядок карт учитывает данный способ хранения, а он не нужен и работать в таком представлении сложно

Самый плотный метод получается 13 бит, далее 2 бита это пара от 1 карты младшей или 2 карты старшей и ещё 1 бит сет наверху

Получим 16 бит на верх

Для пятерки 13 бит и пять на пару, ещё пять на трипс, и пять на карэ

Получим 27 бит 

Проблема кучи нулей остается

Как ещё ужать кек

Джака вариант понял принял, верх 12 бит, пятерка 20 бит

Ещё нужны, оптимальное компактное пространство для хранения хендов, лукап табличкой если, получим матрицу переходов допустим , мне кажется она все ещё велика будет

Если действовать по Джаку то терминальные узлы требуют 

8 пета байт памяти для всей игры

В моём случае ещё больше

Лукап табличка даст 15 гб, если по байту тратить на узел

Напрямую не решить получается)

Надо думать о представлении, вот в холдеме им там проще две карты и вес это префлоп

С флопами тяжелее но три карты и вес флопа

Пиосолвер пакует это все в букеты или монкейсолвер чтобы обойти огромное пространство терминальных состояний

Ну давайте брутальным методом пойдём:

Пусть верх 222 это первый вариант

Кодируем как

0001

223 это 0010

224 это 0011

225 это 0100

Найдите закономерность ) 

Тест на iq кек

226 это 0101

227 это 0110

228 это 0111

Как видим это просто расстояние 

От 222

Что это даст

Если преобразовать в число  и в лукап табличку заглянуть то вот и вся кодировка

С этим понятно вроде

Теперь как все это распараллелить

c00l0ne @ 28.10.22 

Теперь как все это распараллелить

Так вот в чем проблема, допустим у нас есть тысяча компьютеров в сети) 4-6-8-12-16-32 ядерных) и вот это огромное пространство игры необходимо вычислять оптимально ,  распределить вычисления  на них , типа торрент сети только вычислительная)

Вроде просто: делаем бенчмаркинг

Да выделяем определённую область для вычислений, потом все частичные результаты синхронизируем на сервере и записываем результат в базу данных

Процесс синхронизации понятно убер сложный , кто то будет отваливаться , кто то присоединяться к сети... Какие ещё подводные камни...

Думай кот думай кек

Ушёл катать

Гл

Пс все решаемо, просто огромный процесс надо запускать, это вычислительную сеть создавать, солвер кодить, софт для синхронизации и думаю за недельку все стартера считаются...

Если кто то это уже сделал готов стартера приобрести за пятизнак) в ананас/прогрессив... Телега @coulant

Работал у меня лет 15 назад один парень. Молодой.

Постоянно разговоры про девок. Вот эту бы я отодрал. А вот эту бы я вот так, а ту вот так. В общем на словах такой Мачо! С большой буквы.

Пошли мы всех толпой в сауну отметить новый год. Позвали девчонок. Ну и ему, ну давай, Мачо!!, вот он твой шанс!

А он, нееее, не могу у меня жена, любовь и тд....

В общем прозвали его ё.арь-теоретик.

c00l0ne @ 28.10.22 

Пс все решаемо, просто огромный процесс надо запускать, это вычислительную сеть создавать, солвер кодить, софт для синхронизации и думаю за недельку все стартера считаются...

Вот ты пишешь, что все херня, нет только железа.

Ты напиши хоть какой вариант, пусть он считает неделю, пусть месяц!!! Не важно. Вот когда будет такая прога, вот ее можно уже распараллелить.

Ты говоришь о мегапроекте, и вроде даже знаешь как его решить. Осталось только процессоры купить. А сам только начал С++ читать.

Ты - теоретик, не практик. Никогда ты не напишешь такую прогу.

Jak, байтишь знатно

Jak @ 28.10.22 

начал С++ читать

Дочитал уже

Jak @ 28.10.22 

не практик

Как сказал один из великих программистов нашего времени, который это прочитает

"Даже лёжа в ванной - программирую" (с)

Пс терпение терпение, запасайтесь им и ещё процами мощными)

Jak @ 28.10.22 

пусть он считает неделю, пусть месяц

Пс2 прошёл месяц всего, а тут уже идут разговоры про вычислительную сеть, проведу пару тестов и скажу приблизительно за сколько считается более точно и какими вычислительными мощностями.

Неделя крайний срок

c00l0ne @ 14.09.22 

Jak, шмонте Карло, 

Берутся все возможные варианты стартера, далее составляют все возможные состояния на первом ходу для каждого варианта, далее второй ход и так до конца

Когда рука собрана считаем роялти и обратно раскидываем в родительские узлы евшку до корневого. Задача решается полным просчетом такого дерева и выбором лучших вариантов. А такой объем расчётов требует сотни ядер.

Вот самый "легкий" вариант.

Дошли до конца. Последний подъем.

Имеем 8436 С(38,3) вариантов. Получили 8436 разных роялти от "застрел" до ~90. Какое ЕВ запишем в родительский узел?

Среднееарифметическое? Или по весам, сколько застрелов, сколько 12, 20 и т.д?

Не надо тут сотни ядер. Пусть одно ядро потихоньку посчитает. У нас же нет задачи решить за 1 сек?

Гипотетический вариант.

Внизу фулл - роялти 6.

В миде пара королей, 5 карт. Все занято.

В топе одна дама.

Пришли три туза - скуп.

Пришли дама+2 карты - роялти 7+6=13

Пришли разные другие - роялти пониже, либо только 6.

Что писать в родительский узел?

Jak @ 28.10.22 

Что писать в родительский узел?

Jak, сумму вероятность прихода *роялти

Насчёт контингента прогеров

Есть сильные программисты , есть сильные математики

Но есть универсалы... Велкоме ту универсальный мир кек

В твоём примере про молодого парня, чел просто не универсал)

Вы сильные программисты и сильно жгете процы, имхо

Jak @ 28.10.22 

решить за 1 сек

Наша задача решить оптимально в реальное время, не через 10 лет, не через месяц, а в течении ну там недели .... Посмотрим... Нужны тесты и выяснить объём работы, предварительная подготовка тут проведена

И решить не тратя год два личной жизни на супер алгоритмы как некоторые сделали, а в качестве хобби проекта, имхо потому что ничего может не получится

Jak @ 28.10.22 

Вот самый "легкий" вариант.

Это лёгкий вариант для дорешивания, но когда ты столкнешься с пространством всех стартеров и порождаемых ими узлов , ты поймёшь что это как звёзд на небе, а долететь мы можем за жизнь к одной только... Слишком медленно к сожалению...

Поэтому нужны сотни кораблей, желательно тысячи

По аналогии такое же кол-во ядер нужно

Продолжим теоризировать 

Вообще обычно на бумаге 90 процентов пишется

Короче лукап табличка, это ядро 

Вокруг неё крутится все

Как её представить 

int lookup_table_global_index[top_index][mid_index][bot_index]

По 4байта да

МИД индексы +-20к бот такие же, ну и верх 1000

Итого размер 20к*20к*1к= 400ккк это 4*10^11 , 400 гб однако по байту , по 4байта 1.6 тбайта

Таких таблиц необходимо две держать в памяти чтобы переходить от улицы к улице

Итого память 3.2тб на вскидку

За день писюк такую табличку пересчитает

Дней за 5 посчитает до стартеров

Но это слишком брутально , оптимизейшн нужен

Выпрямить её как в HR и сжать , поменьше будет

Какие ещё мысли...

Напрямую на ssd хранить и туда писать-читать

Ещё мысли нужны

Мы в универе такие большие не решали)

Надо посмотреть алгоритмы сжатия и индексации , может есть что нибудь толковое

По индексации есть лса и влси

Есть ещё алги кластеризации

Ну и сжатия алгоритмы:

Вот и весь солвер, запихиваем громадину эту в память считаем евшки, делаем шаг назад считаем евшки, еще пару шагов назад и вот уже считаем евшки стартеров, сохраняем все стартера и первый ход(по времени неделя-месяц), далее вашим любимым Монте Карло бегаем по этому готовому дереву и уточняем для конкретных ситуаций(3макс, ху, против фантазий, с разными дропами аутов) (пару секунд)

Как душе угодно

Пс Кто сделает маякните )

Бенч нужен, i/o ssd и скорость обмена 

Допустим мы открываем файл размером 1тб на ssd и записываем со смещением случайным 1 млрд байт, так же читаем 

Кому интересно вот памятка

Через какие winapi и с какими флагами открывать

Можно конечно и напрямую с SSD работать ) но думаю winapi достаточно

Jak, шмонте Карло,

Берутся все возможные варианты стартера, далее составляют все возможные состояния на первом ходу для каждого варианта, далее второй ход и так до конца

Когда рука собрана считаем роялти и обратно раскидываем в родительские узлы евшку до корневого. Задача решается полным просчетом такого дерева и выбором лучших вариантов. А такой объем расчётов требует сотни ядер.

Написал такой вариант.

Имеем: некий стартер 5 карт.

Формально имеем 232 варианта расклада стартера.

Посчитаем один вариант упрощенно.

Имеем 4 подъема по 3 карты.

Т.к. все равно кладем 2 карты, можно считать, что пришли 2 карты (хотя это упрощает дерево и уменьшает ЕВ, тк из трех мы бы выбрали лучшую пару, а тут имеем, что имеем).

ТЕ, я считаю, что пришли 2+2+2+3 карты.

В последнем подъеме считаю все 100% рук. Сначала по 2 карты, запоминаю, и уже потом для каждой тройки выбираю лучшую пару и пишу роялти (возвращаю ответ) в родительский узел.

Первые три подъема ничем не отличаются по смыслу, потому пока у нас не 11 карт, считается рекурсивно. Всего пару десятков строк. Тупо кладу все варианты пар по очереди и вызываю себя еще раз и тд.

Последний подъем самый важный, тк  вызывается макс число раз. Написал отдельно, все по максимуму быстро. Этот подъем считаю весь 100% всегда. Довольно быстро.

Запустил на ночь, до утра не посчитало...

По совету сделал вариант с М-К. Теперь задаю %% каждого уровня (поднятия) и считаю. Т.е. при 100% на первом поднятии 1081 пар, потом 990, 903 в конце 820.

Значит при 5% на первом поднятии беру 54 пары, потом 50 и т.д. На последнем (где роялти и скупы) все 820 пар. 

1% - решает ~13 сек. 2% - 105 сек, 3% - уже 340сек, 4% - 820 сек, 5% - 1650 сек, почти 27 минут. Результаты примерно одинаковы.

Щас буду распараллеливать. Думаю раз в 6-10 будет быстрей.

===========================================

Важные начальные данные от которых зависит результат.

Скуп - пока беру -12. Можно поиграть с циферками.

Бонус за пару дам, королей и тд в топе за будущую фанту. Щас взял 9,78. Тоже не понятно сколько брать.

Какие мысли?

## если добавить еще 10 карт, мы третьи, то считает в 10 раз быстрей.

Jak @ 09.11.22 

Какие мысли?

Первая респект

Вторая

Jak @ 09.11.22 

Запустил на ночь, до утра не посчитало...

Нужно смотреть код, с хорошей оптимизацией на с++ где то 1-2 минуты считает, проверено💩

В один поток минут 20-30

Алгоритм не понял распиши по полочкам 

1. 

2.

3.

4.

Как получаешь решение итоговое

Где то жгешь проц