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

c00l0ne @ 15.09.22 

Чтобы Дж Дж   

Был равен коду рояля

Тут есть проблема. 

Данный вариант предполагает замену джокеров на карты по-максимуму.  Это годится только для нижней линии.

Для мида и верха, джокеры надо заменять на максимально сильную комбу, но все же меньше низа и мида (для верха).

Прощу перебирать четыре или три известных карты в HR5 и HR3 и к ним добавлять все 52 карты и смотреть максимум.

Пусть низ      и мид      , хочется  (Дж) заменить на  или  , но лучше до стрита на  , (кроме черв  ).

А в принципе сделать такой максимассив не проблема. Я делал такой же для короткой колоды, легко. Будет не 52 карты, а 54.

Jak, а ты запускал глобальную симуляцию максимально приближенную к реальной ситуации за столом?

Можешь написать какие средние результаты получаются на 100 игр (сколько: очков/фантазий/мертвых рук/рук без очков)

И вообще кто-нибудь знает показатели сильных игроков в китайский покер? Если кто-то знает, напишите хотя бы приблизительно. По моим прикидкам на сотню игр это 500+ очков, фантазий 25+, но многое зависит от позиции и количества игроков за столом.

c00l0ne @ 17.09.22 

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

Что ж смотрю никто не загорелся

Если гора не идёт к Кулону придётся гору облететь)

Но в реальности без индексации работы в принципе быть не может

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

Где то видел этот приём индексирования в книге, в главе где альфа зеро сетку там запускали

Ждём на рынке дешманскмй прожаренных видеокарт, майнинг перешёл 0 отметку, становится не выгодным ну и майнеры вывалят на рынок кучу видюх, на них можно сети считать как минимум

Ждём так же выхода 7000 райзена с ддр5, народного проца всех времён и поколений

Вообщем думаю нас ждут интересные события в ближайший год в компьютерном мире

Jak @ 18.09.22 

замену джокеров на карты по-максимуму.  Это годится только для нижней линии.

Ну, можно HashRate сделать для среднего лайна с указанием комбы низа

Аля выпрямленный массив вида:

HR6(combo+kickers, c1, c2, c3, c4, c5)

Не вижу в этом проблемы

Для верха то же самое

Jak @ 18.09.22 

Прощу перебирать четыре или три известных карты в HR5 и HR3 и к ним добавлять все 52 карты и смотреть максимум.

Бро, это слоууук, медленно 

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

Научитесь экономить проц уже

Я кстати в своё время не умел это делать и в итоге на олимпиаде второе место занял вместо первого )

Потому что не уложился мой алгоритм в отведенное время, а у оппонента  уложился

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

Не в стрингах же программировать как БиллиУпокойУбилли буу

План такой пока есть немного времени:

1. посчитать кол-во терминальных НОД без учёта флешей

2. Подумать над бинарной симуляцией игры

3. Индексация

П1 поставил считаться , где то 10 мин займет

Код такой:

 

Результат:

15 846 284 740 терминальных НОД на всю игру

7 минут считало

Описание алгоритма: 

Симулируем колоду массивом "о" в котором храним кол-во аутов: двоек троек четвёрок и так до туза(0 это двойки, 1 тройки и 12 это тузы)

А далее циклами перебираем все возможные варианты расстановки карт с учётом того что карты в Лайне изоморфны

Ставте visual studio, вбивайте в консольный проект visual basic и все должно работать.

Учесть флеши надо,

Тут вариантов не много , низ фл мид нефл

низ фл мид фл

низ нефл мид фл

Низ нефл мид нефл

4 варианта

Итого терминальных НОД будет приблизительно 16 млрд *4=  64млрд

Соответственно лукап табличка будет занимать 64*8 млрд байт  , 512 гб ого

Но это все ноды, понятно что в памяти с ними всеми работать не возможно, да и не нужно

Плюс отбросить можно все ноды которые приводят к скупу 

Потом это посчитать можно

П2

В чем смысл игры

Игрок делая ходы перемещает карты в определённые лайны

Собственно это движок игры

Лайны пусть будут у нас 2 байтовыми числами 

Бинарной игра для компьютера выглядит так:

top = top or bit_c1

mid = mid or bit_c2

bot = bot or bit_c3

Карты сброса ещё:

drop = drop or bit_c4

Но битовая информация хранит только информацию о наличии карт в лайне, а повторы и тройные и четверные необходимо хранить отдельно 

topx2 topx3 midx2 midx3 midx4

botx2 botx3 botx4 dropx2 dropx3 dropx4

Ну и галочка флеш не флеш

Вроде бы вся игра описана, ещё можно порядок хранить ходов

Лучше пока не придумывается

Интересно насколько это быстрее интегеров

Вот можно свой рум делать на базе движка

Допустим в руме играют 1000 человек в китайский , вся информация о их ходах укладывается в 100 байт * 1000 человек

Итого памяти надо 100кбайт для поддержания игры 1000 игроков плюс колоды

О каких лагах сервера пд может вообще идти речь кек, пентиума III хватит все это обработать

П3

c00l0ne @ 22.09.22 

16 млрд *4=  64млрд

Теперь весь этот зоопарк надо проиндексировать, да так чтобы CPU вывозил и в RAM влазило

Какие мысли, очевидно игра не решается вся за "один присест", не влазит просто в память, да и времени займёт бесконечно много

Последовательно стартер за стартером придется

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

Точность упадёт но это копейки

А стартера и ходы до посл можно в принципе оставить на прямую , но это спорно

Но думаю вот такой вариант уже можно закодить 

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

П4 : надо решить насколько сложную абстракцию делать и тестировать производительность, где будет bottleneck , там уже и расширять

Желающих нет попилить дальше?)

c00l0ne @ 22.09.22 

П4 : надо решить насколько сложную абстракцию делать и тестировать производительность, где будет bottleneck , там уже и расширять

Ок продолжу мысль

Допустим мы абстрагируемся до комб на посл ходу, а на предпоследнем у нас полное дерево, тут возникает проблема перехода к абстракции, банально как это считать. 

Возьмём пример

AKQ

2233

TTJJ

Задача посчитать ев на посл ходу, без учёта сброшенных карт и досок оппонента, но используя на посл ходу абстракцию до комб.

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

Тут у нас четыре основных узла:

1. Фх низ нефх МИД

2. Фх низ фх МИД

3. Нефх низ фх мид

4. Нефх нефх

Наша цель какая, сделать алгоритм минимально затратный для перехода к данным узлам.

Вот такой алгоритм получается:

Описание: цикл по полному отображению включает в себя все допустимые ходы

В этом цикле мы через лукап табличку переходим к упрощенным нодам

От обычного алгоритма отличается доп вычислениями : HR и обращением в лукап табличку и тд, но сэкономили кучу памяти.

П5 алгоритм общий, проход по дереву, тут думаю ничего сложного нет, бегаем по узлам считаем евшку в каждом узле напрямую, а не как делают Jak Galax симуляциями кек, сорри брос

И раскидываем по родительским узлам и так до корневой ноды

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

Пс сейчас плотная серия на две недели, после неё возможно закодим это фсе...

А возможно и во время серии закодим)

Пс

Сразу говорю что мой рабочий язык , это самый популярный язык в мире: 

Visual Basic (да начнется холивар)кекеке

Никаких тут паскаледелфей и сисиплусплус и даже сишарп не будет, питонов тоже душить не будем

Но учитывая что vb и сшарп компилятся в итоге в один код, думаю ничего страшного

Поэтому если хотите вникать в код, то изучайте Visual Basic .NET

c00l0ne @ 27.09.22 

П5 алгоритм общий, проход по дереву, тут думаю ничего сложного нет, бегаем по узлам считаем евшку в каждом узле напрямую, а не как делают Jak Galax симуляциями кек, сорри брос

А с чего ты решил, что мы делаем симуляцию?

Два последних подъема вообще полным перебором за доли секунды. Последние 4 карты. Что там считать?

Второй подъем тоже полным перебором, неск. сек. Есть вариант с Монте-К, там быстрей, тоже доли сек.

Ты не заметил, что Galax писал, что мои и его данные совпадают полностью, это может быть ТОЛЬКО при полном переборе. При Монте - результат примерный.

Jak, ага продолжай, ну а первый и стартер

терминологию еще маленько уточним

полный перебор

это по всем ветвям 

а монтекарло это частично по какой то границе , лучшие ев и тд

я правильно понял

но получается и там и там симуляции проводятся игры

мне кажется это утопичный путь, времени нету на эти все симуляции, повторюсь дерево огромно 512 гб терминальных нод, к ним соединяются ну допустим 200гб нод посл хода к ним соединяются допустим 150 гб третьего и второго хода и первого хода 25 гб и стартеры гигабайт 10

у нас 1тб дерево, методы которые симулируют игры в этом дереве будут сотнями лет считать 

Jak @ 27.09.22 

Galax писал, что мои и его данные совпадают полностью, это может быть ТОЛЬКО при полном переборе

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

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

Нет.

МК - это не полный перебор.

Пусть надо посчитать 1000000 (1кк) вариантов.

Полный перебор - это когда посчитано все 1000000=1кк вариантов, а МК - это когда посчитано << 1кк. Ну пусть 100000=100к. В 10 раз меньше.

c00l0ne @ 22.09.22 

П1 поставил считаться , где то 10 мин займет

 

Код такой:

Твой код (15 вложенных циклов) на дельфи считается 50сек.

Ответ совпал.

Вот твой VB против Delphi.

Jak, я там в debug mode запускал

СПС что провёл проверку

Так и я в debug mode.

Jak @ 27.09.22 

Так и я в debug mode.

Ок проверю, верится с трудом, но сейчас не до этого .

А что проверять?

Бейсик никогда не будет быстрей Дельфи

Jak @ 27.09.22 

А что проверять?

Бейсик никогда не будет быстрей Дельфи

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