| Re: Самое быстрое определение покерной комбинации — Часть 2 ID:25248 ответ на 25243 |
Пт, 26 октября 2007 12:32 [#] |
|
| Sharky |
|
 (иконки IM)
Форумы CasinoGames
|
|
| Korovin писал пт, 26 октября 2007 02:05 | | не хочется флудить в такой ветке, всеже спрошу: для рук из 6 и 7 карт все аналогично? массивы 13^X для разных правил формируются на лету или заранее? |
Фишка в том, что массивов 13^X я более не использую вообще. Их у меня уже нет. Логика всего алгоритма заключается в подсчете разнотипных карт по рангу, для этого служит маска по OR. То есть, например у нас K282A. Каждому рангу назначен свой бит. Эти биты объединяются по OR и получаем для K282A: 1100001000001. Очевидно, что сумма битов = 4. Значит, это пара. Для суммы в 3 бита — две пары или тройка, для суммы в 2 бита — фулл или коре. Сумма с 1 битом не может быть никогда. Это все справедливо для руки в 5 карт.. Для рук в 6 и 7 используются другие функции, на аналогичном алгоритме, но много сложнее.
Для подсчета количества битов нет ассемблерной команды (по крайней мере документированной), для этого использую таблицу BIT_COUNT16. И еще одна таблица CMB_DETECT нужна для определения AK и стрейтов (их может быть три: тигр-стрейт, круговой и обычный).
| Korovin писал пт, 26 октября 2007 02:05 | | У меня была идея унификации всех возможных рук в больших таблицах а затем определения параметров руки по ее уникальному ноиеру из маленькой таблицы в зависимоти от правил (круговые стриты, ТК играет, 3 пары, двойные комбинации, . т.п.). На счолько % использование функций на ассемблере повышает производительность против кода на си или паскале? (я пробовал, у меня получается ХУЖЕ). |
ASM применил в основном для того, чтобы организовать безифовые переходы (так я их называю).
Например, JMP @Vector.Pointer[EBX * 4]
Это аналог
[code]
case BitCount of
0,1: goto ..
2: goto ..
3: goto ..
4: goto ..
5: goto ..
end;
[/ code]
Естественно, что на ASM это будет и в разы быстрее и меньше кода.. Таких переходов здесь несколько.
| Korovin писал пт, 26 октября 2007 02:05 | | И еще замечание по подходу вообще. Нам требуется супербыстродействие при многократных вызовах данной функции. Многократные вызовы органеизуются в функциях более высого уровня, и очевидно что это функции перебора карт, в циклах. Используя этот факт мы можем уменьшить число выполняемых операций в данной функции если вынесем формирование адреса в таблице для каждой перебираемой карты за пределы этой функции в те циклы, где эта карта перебирается, там же можно отслеживать и флаг масти (так же поэтапно), в этом случае от самой функции отсанется только выборка значения из таблиц. |
Я думаю по другому, применительно к моему методу, можно организовать предобработку и юстировку... Предобработка рассчитывает промежуточные значения (по 4 картам), а юстировка 1 пермутируемую карту с промежуточными значениями. Но это практически не нужно, так как есть более элегантное решение — предсказание (аналог твоего сжатия мастей).
|
|
|