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

Luisito99, ладно будет время, на стриме обьясню

Сейчас режим суровый работа  дом работа сон ... 

Рекомендую просто довериться и доделать)

Luisito99 @ 04.04.23 

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

Ты маленько пропустил основы и тервер и не понимаешь как это работает:

Вот почитай :

29 млрд умножить 820

Это 25 триллионов умножений

И соответственно миллионы функции макс() 

А человек хотя бы два умножения делает когда ставит карты стартера?) 

Я тебе скажу такую вещь, что некоторые реги когда играют 2 стола, на одном столе не считают ауты) 

По шаблону шпилят, короли наверх, а туз в середину и бац оказалось он поставил туза а аутов давно нет... Кекв

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

Jak, насчёт мультипоточности, оч слабый баланс, некоторые потоки быстренько завершаются, а некоторые:, сейчас сидел ждал Посл поток) минут 5) ну такое

Да, это больная проблема.

Тут не угадаешь, анализировать структуру стола? 

Самый длинный первый поток. Его можно разбить на неск потоков. Тогда самым длинным будет второй ((, разбить его, самым будет третий и т.д.

Есть три варианта стартера:

1. Нет флешей. 13 разных циклов. (Твой вариант расчетов).

2. Один флеш, внизу или в миде. 13+карт на флеш (от 9 до 12) = 22..25 циклов.

3. Два флеша. 13+(9..12)+(9..12)=31..37.

Упрощенная схема расчетов.

Считаем 2 вложенных цикла, всего N разных карт.

for i:=0 to N-1

  for j:=i to N-1

     расчет этого подъема.

Чтобы разбить первый подъем надо сделать N*(N-1)+N потоков с начальными данными (i(x), j(y)) x=0..N-1, y=i..N-1.

Вопрос: сколько макс потоков можно/необходимо сделать? Вроде хоть сколько. Пока есть память, делай сколько хочешь. Но на каждый поток надо свой стек, мин 1 Мб. И память для потока. + если сделать много потоков ~100, комп сильно занят, на нем невозможно ничего делать. Точнее сильно медленно можно что-то делать.

1. Можно разбить на 91 поток. Разбить все циклы на отдельные. 13*12/2+13=91. Нет проблем, я раньше так делал.

2. Пусть будет 23 цикла. 23*22/2+23=432 потока! Надо нам это? Даже на организацию одного потока надо время. Пусть это будет 0,01 мс. А работать каждый поток будет тоже 1 мс. Только создал его, запустил и он закрылся.

3. Тут вообще мрак. Время создания потока будет сравнимо со временем работы потока. Особенно последних. 

Т.к. разбитием первого подъема на 2 карты, мы фактически разбиваем первый подъем на отдельные потоки. Но остальных три потока останутся.

Значит надо разбить несколько первых циклов. Можно конечно поэкспериментировать. Разбить первых 10% циклов, остальные не трогать. Или разбить 20%, 30% ...

Причем желательно сделать разбивку на потоки универсальной, независимой от вариантов 1,2,3.

Надо какое-то разумное разбиение на потоки.

ЗЫ. А вообще-то это нормальное развитие событий.

В начале хочется хоть как, пусть медленно что-то посчитать. Сделали. Эйфория!!!

Теперь хочется 2-й уровень, посчитать то же, но побыстрей, лень ждать... Да и добавить еще что-то охота.

Потом будет уровень 3,4,5...

c00l0ne, 

мне кажется ты неправ. Если взять и добавить штраф за скуп где-нибудь -20 или даже больше (понятно, что это слишком много, просто для наглядности) и дать сыграть программе в режиме максимально приближенном к реальной ситуации, то ее показатели, вероятно, будут хуже показателей человека, потому что программа будет играть слишком тайтово с минимальным кол-м фантазий и не важно сколько там умножений проводится.

И еще вопрос. Добавление штрафа за скуп перестраивает игру программы при расчете стартера? 

Например у нас такая ситуация: 

Пятерка      

Первая тройка    

Если мы рассматриваем стартер

A

2

K Q J

При расчете стартера с штрафом за скуп -1, возможно (расчеты не проводил) выгоднее поставить 9 9 в середину, а вот со скупом например -20 возможно уже программа должна перестроиться и поставить стрит. 

Как ведет себя программа в таких ситуациях? Важно именно при расчете стартера, т.е. первых троек будет Х кол-во.

Или программа считает как со скупом 0, а уже в конце за мертвые руки добавляет -1 или -20 в зависимости от заданного значения.

Luisito99, не понимаю тебя сорямба

Конечно скуп влияет на общую стратегию

Как и оценка пустой руки

Да бл любая цифра в формулу ев внесенная влияет

Luisito99 @ 04.04.23 

считает как со скупом 0

Конечно нет, в конце собирая мёртвую руку получаем -6 и они пробрасываются через сотни умножений на вероятности в ходы выше по дереву, и в стартере учитываются так

Соответственно если скуп большой то программа играет больше от снизу, стараясь не рисковать , если скуп не большой рискует лишь бы роялти собрать

При скупе равным нулю, программа начинает у вас собирать 6-7 наверх ради куша роялти кекв в ситуациях :

Сдача 745

Доска:

A7

565

ТТВВ9

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

Что является грубой ошибкой в Н кушей

вот про что я : 

представь ситуацию что оппонент уже завалил руку и мы за его скуп можем получить +6 кушей

а софт рискует, потому что скуп = 0, но если мы добавим хотя бы единичечку , он быстро свои "ручки" убирает от скупов ради херни : 

поэтому изучайте сами игру и пользуйтесь инструментом для расчетов от Jak'a ...

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

начатый билли убилли 7 января 2019 года  ... но он только смог привлечь внимание оч сильных программистов ... сам он в "стрингах" программировал в то время... ) 

а дальше пришлось мне немного посидеть подумать ... как на писишках туповатых и тормозных, кто не понимает со времен пентиума 166 в принципе ничего в архитектуре х86 не изменилось ... гигагерцы и ядры тока вырасли ... а в целом программирование осталось на том же уровне , так вот как на этом целочисленном калькуляторе ( архитектура х86) посчитать игру в которой оч много состояний... была рождена мной идея , упростить это все, залетела она от программиста гугловца, который мощный , элита так сказать ... 

но он совсем в другом направлении работает... нейросети все дела ... а я такое не умел ... пришлось фергуса вспомнить и классически решить деревьями... 

какие перспективы: считать стартера , делать ближе к идеалу ... выводить цифры правильные .... снова считать еще по кругу так раз 10 и вуаляляля решенный китайский... год два и готово ... велкоме

кто не понимает : 

в теории китайский уже решили: 

осталось do it 

считаем стартера , сохраняем стартер + первую сдачу, это самая трудоемкая часть ... 

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

например с весом 0.3 у нас 229/A/K, с весом 0.3 5678/J и с весом 0.4 там 89/56/A

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

теперь мы можем посчитать симуляцией реальную игру 

например нам раздают стартер 

A

23

555

вот мы и считаем симуляцией против упрощенки 

в 0.3 против нас 229/A/K в 0.3 5678 и т.д. (за основу игры берем сохраненные стартера и первый ход , а второй третий досчитываем ... на это писюки еще способны ,но я не уверен что компы среднии вывезут , скорее только 64 ядра  + ) 

и вот можем реальное НАСТОЯЩЕЕ АБСОЛЮТНО ТОЧНОЕ ев получать без позиции 

гг брошки

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

а что если Jak и это сделает ?)

ахахаха а ведь он может )

пс байчу байчу, я пробайчер) ))  но если серьзено это все стоит где то 50-100к $

вот такая работа кто сделает ... стоимость включает в себя : аренда сервера + труд + человеко часы + интеллектуальная состовляющая...

c00l0ne @ 04.04.23 

начатый билли убилли 7 января 2019 года ... но он только смог привлечь внимание оч сильных программистов ... сам он в "стрингах" программировал в то время... )

вот моя программка апрель 2014г.

тогда только ананас появился, был просто китай по 1 карте и играть могли до 4 челов, был турбо, когда давали по 4 карты...

потом я ее забросил, так что, билли просто напомнил мне...

Jak, больше похоже на кабину пилота, ну да ладно)

За каждой кнопкой какой-то способ решения какой-то задачи

Jak @ 04.04.23 

За каждой кнопкой какой-то способ решения какой-то задачи

крутотень!

стартера досчитаются , покажу как надо ) еще месяц - два

не уменьшает время увеличение потоков.

Если ядер больше чем кол-во карт в первом цикле, тогда может имеет смысл.

Вот примеры, кол-во потоков сейчас при МАХ, время выполнения каждого потока.

Тут есть флеш в миде.

6,539460, 652,0c, <2s 2h Ks | 9c | Ad >, P -3

0,  429,891          1,  420,141          2,  408,828          3,  397,063          4,  386,344          5,  373,297

6,  347,875          7,  346,500          8,  334,500          9,  321,781          10,  503,687        11,  239,406

12,  412,375        13,  308,906        14,  283,343        15,  257,296        16,  234,328        17,  202,187

18,  174,797        19,  144,500        20,  114,063        21,  79,546          22,  43,593

а вот я первую половину циклов разбил на 2 потока:

6,539460, 700,7c, <2s 2h Ks | 9c | Ad >, P -3

0,  154,969          1,  274,969          2,  180,969          3,  248,265          4,  171,141          5,  250,688

6,  181,063          7,  229,391          8,  169,141          9,  229,469          10,  178,734        11,  205,703

12,  161,672        13,  199,890        14,  176,625        15,  184,797        16,  162,875        17,  184,968

18,  171,922        19,  162,000        20,  258,297        21,  268,938        22,  143,078        23,  117,875

24,  235,562        25,  259,438        26,  352,906        27,  320,110        28,  299,141        29,  275,313

30,  248,250        31,  219,109        32,  184,672        33,  152,234        34,  140,359        35,  121,047

36,  70,578

каждый поток по времени меньше раньшего, но сумма не поменялась. У меня 12 потоков мах, 6 ядер.

Было бы у меня проц 40 потоков, тогда в первый раз время=504 сек, во второй=353 сек.

Тут без флешей.

7,857561, 115,8c, <2s 2h | Ad 9c | Ks >, P -3 754c

0,  115,734                                          1,  102,203                                          2,  96,156

3,  89,516                                            4,  83,625                                            5,  76,297

6,  69,688

7,  58,563             8,  51,312             9,  42,015             10,  32,485          11,  19,203          12,  10,047

7,857561, 92,8c, <2s 2h | Ad 9c | Ks >, P -3 926c

0,  76,781             1,  69,500             2,  65,313             3,  62,797             4,  65,375             5,  52,594

6,  54,688             7,  52,735             8,  54,735             9,  41,906             10,  44,000          11,  41,813

12,  38,828          13,  30,313

14,  48,781          15,  40,187          16,  33,875          17,  26,359          18,  18,250          19,  8,844

Jak, ууу скока цифорок 

нужен код посмотреть 

а так конечно очень длинный потоки

обычно их короче делать удобнее

смотреть на пул , смотреть на загрузку CPU если просела добавлять новые потоки ... 

GPT рисует такой алг: 

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

а дальше просто следите за потоками чтобы они CPU >90 % загружали , добавляйте потоки ... 

потоки должны быть мелкие ... но не слишком ...

в итоге такой код должен получиться : 

if cpu_load >90 то

    считаем не отдельным потоком, а родительским ... 

иначе 

   создаем отдельный поток и считаем в потоке...

Как получить загрузку проца, за интервал : 

function GetCpuUsage(Interval: DWORD): Int64; var  IdleTime1, KernelTime1, UserTime1: FILETIME;  IdleTime2, KernelTime2, UserTime2: FILETIME; begin  GetSystemTimes(@IdleTime1, @KernelTime1, @UserTime1);  Sleep(Interval);  GetSystemTimes(@IdleTime2, @KernelTime2, @UserTime2);  Result := Round((1 - ((IdleTime2.dwLowDateTime - IdleTime1.dwLowDateTime) +    (IdleTime2.dwHighDateTime - IdleTime1.dwHighDateTime) +    (KernelTime2.dwLowDateTime - KernelTime1.dwLowDateTime) +    (KernelTime2.dwHighDateTime - KernelTime1.dwHighDateTime) +    (UserTime2.dwLowDateTime - UserTime1.dwLowDateTime) +    (UserTime2.dwHighDateTime - UserTime1.dwHighDateTime)) /    ((KernelTime2.dwLowDateTime - KernelTime1.dwLowDateTime) +    (KernelTime2.dwHighDateTime - KernelTime1.dwHighDateTime) +    (UserTime2.dwLowDateTime - UserTime1.dwLowDateTime) +    (UserTime2.dwHighDateTime - UserTime1.dwHighDateTime))) * 100); end;

Увеличил кол-во потоков, появилась галка "Gyper". Галка работает только, если выбран режим "Max". 

Можно оценить до вычислений сколько будет потоков.

Добавил строку, "Сколько сделано %%" во время вычислений, чтобы было видно, что прога считает. Внизу видно сколько потоков работает...

c00l0ne @ 04.04.23 

А человек хотя бы два умножения делает когда ставит карты стартера?) 

Я тебе скажу такую вещь, что некоторые реги когда играют 2 стола, на одном столе не считают ауты) 

По шаблону шпилят, короли наверх, а туз в середину и бац оказалось он поставил туза а аутов давно нет... Кекв

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

На мой взгляд это ошибка.

Установи премию за фантазию +0 и скуп -3  и дай программе сыграть в позиции 1 из 3 в режиме максимально приближенной к реальной ситуации и вероятно ее показатели после нескольких тысяч игр будут хуже чем показатели человека на этой же позиции.

Или взять  премию за фантазию +9,75 и скуп  -30 и аналогичную проверку.

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

Поэтому возникает вопрос: какие значения фантазии и скупа наиболее оптимальны в обычном ананасе и как ты это определил и как проверил если мы рассматриваем позицию 1 из 3?

c00l0ne @ 04.04.23 

Конечно скуп влияет на общую стратегию

Дело в том, что скуп можно добавлять не только для всех подъемов при расчете стартера, а например только для предпоследнего подъема. По крайней мере в моей ситуации так сделать можно. Получится, что первая и вторая тройка считаются о скупом = 0, а следующие тройки  уже со скупом -Х и это все при расчете стартера. Но как сделать лучше - сложный вопрос. Только проверка может дать ответ на вопрос. А проверить можно только дав программе сыграть в режиме максимально приближенном к реальному и сравнив результаты. Других способов проверки  я не знаю.

Luisito99 @ 05.04.23 

например только для предпоследнего подъема. По крайней мере в моей ситуации так сделать можно. Получится, что первая и вторая тройка считаются о скупом = 0, а следующие тройки  уже со скупом -Х и это все при расчете стартера

Luisito99, моя твою не понимать

Приведи пример

Jak, круто

Luisito99 @ 05.04.23 

любая программа всегда будет лучше человека.

Ну не любая и важно насколько лучше, 0.01 куш, 0.1 куш, 0.5 куша, 1 куш 

Это всё разница огромная

И скорость стала побыстрей