C99 - placa 3x3 em 0,084s
Editar: refatorei meu código e fiz uma análise mais profunda dos resultados.
Edições adicionais: Poda adicionada por simetrias. Isso faz 4 configurações de algoritmo: com ou sem simetrias X com ou sem poda alfa-beta
Edições mais distantes: Adicionado memorização usando uma tabela de hash, finalmente alcançando o impossível: resolver uma placa 3x3!
Recursos principais:
- implementação direta do minimax com poda alfa-beta
- muito pouco gerenciamento de memória (mantém dll de movimentos válidos; O (1) atualizações por filial na pesquisa em árvore)
- segundo arquivo com poda por simetrias. Ainda obtém atualizações O (1) por filial (tecnicamente O (S), onde S é o número de simetrias. Isso é 7 para placas quadradas e 3 para placas não quadradas)
- terceiro e quarto arquivos adicionam memorização. Você tem controle sobre o tamanho da hashtable (
#define HASHTABLE_BITWIDTH
). Quando esse tamanho é maior ou igual ao número de paredes, não garante colisões e O (1) é atualizado. As hashtables menores terão mais colisões e serão um pouco mais lentas.
- compilar com
-DDEBUG
para impressões
Potenciais melhorias:
corrigir pequeno vazamento de memória corrigido na primeira edição
poda alfa / beta adicionada na 2ª edição
remover simetrias adicionadas na 3ª edição (observe que as simetrias não são tratadas pela memorização, portanto isso permanece uma otimização separada.)
memorização adicionada na 4ª edição
- atualmente a memorização usa um bit indicador para cada parede. Uma placa 3x4 possui 31 paredes; portanto, esse método não pode lidar com placas 4x4, independentemente das restrições de tempo. a melhoria seria emular números inteiros de bits X, onde X é pelo menos tão grande quanto o número de paredes.
Código
Devido à falta de organização, o número de arquivos ficou fora de controle. Todo o código foi movido para este repositório do Github . Na edição de memorização, adicionei um script makefile e testing.
Resultados
Notas sobre complexidade
As abordagens de força bruta para pontos e caixas explodem em complexidade muito rapidamente .
Considere um quadro com R
linhas e C
colunas. Existem R*C
quadrados, R*(C+1)
paredes verticais e C*(R+1)
paredes horizontais. Isso é um total de W = 2*R*C + R + C
.
Como Lembik nos pediu para resolver o jogo com o minimax, precisamos atravessar as folhas da árvore do jogo. Vamos ignorar a poda por enquanto, porque o que importa são ordens de magnitude.
Existem W
opções para o primeiro movimento. Para cada um deles, o próximo jogador pode jogar qualquer uma das W-1
paredes restantes, etc. Isso nos dá um espaço de pesquisa de SS = W * (W-1) * (W-2) * ... * 1
, ou SS = W!
. Os fatoriais são enormes, mas isso é apenas o começo. SS
é o número de nós folha no espaço de pesquisa. Mais relevante para nossa análise é o número total de decisões que tiveram que ser tomadas (ou seja, o número de ramos B
na árvore). A primeira camada de ramificações tem W
opções. Para cada um deles, o próximo nível tem W-1
, etc.
B = W + W*(W-1) + W*(W-1)*(W-2) + ... + W!
B = SUM W!/(W-k)!
k=0..W-1
Vejamos alguns tamanhos pequenos de tabela:
Board Size Walls Leaves (SS) Branches (B)
---------------------------------------------------
1x1 04 24 64
1x2 07 5040 13699
2x2 12 479001600 1302061344
2x3 17 355687428096000 966858672404689
Esses números estão ficando ridículos. Pelo menos eles explicam por que o código de força bruta parece pendurar para sempre em uma placa 2x3. O espaço de pesquisa de uma placa 2x3 é 742560 vezes maior que 2x2 . Se 2x2 levar 20 segundos para ser concluído, uma extrapolação conservadora prevê mais de 100 dias de tempo de execução para 2x3. Claramente, precisamos podar.
Análise de poda
Comecei adicionando podas muito simples usando o algoritmo alfa-beta. Basicamente, para de procurar se um oponente ideal nunca lhe daria suas oportunidades atuais. "Ei, olhe - eu ganho muito se meu oponente me deixar ganhar todos os quadrados!"
edit Também adicionei poda com base em placas simétricas. Não uso uma abordagem de memorização, caso algum dia eu adicione memorização e queira manter essa análise separada. Em vez disso, funciona assim: a maioria das linhas tem um "par simétrico" em outro lugar da grade. Existem até 7 simetrias (horizontal, vertical, rotação 180, rotação 90, rotação 270, diagonal e a outra diagonal). Todos os 7 se aplicam a placas quadradas, mas os últimos 4 não se aplicam a placas não quadradas. Cada parede tem um ponteiro para o seu "par" para cada uma dessas simetrias. Se, entrando em um turno, o tabuleiro é horizontalmente simétrico, então apenas um de cada par horizontal precisa ser jogado.
editar editar Memoização! Cada parede recebe uma identificação única, que eu convenientemente defini como um indicador; a enésima parede tem o id 1 << n
. O hash de um tabuleiro, então, é apenas o OR de todas as paredes jogadas. Isso é atualizado em cada filial no tempo O (1). O tamanho da hashtable é definido em a #define
. Todos os testes foram executados com tamanho 2 ^ 12, por que não? Quando há mais paredes do que bits indexando a hashtable (12 bits neste caso), os 12 menos significativos são mascarados e usados como índice. As colisões são tratadas com uma lista vinculada em cada índice de hashtable. O gráfico a seguir é minha análise rápida e suja de como o tamanho da hashtable afeta o desempenho. Em um computador com RAM infinita, sempre definiríamos o tamanho da tabela para o número de paredes. Uma placa 3x4 teria uma hashtable 2 ^ 31 de comprimento. Infelizmente, não temos esse luxo.
Ok, voltando à poda. Ao interromper a pesquisa no alto da árvore, podemos economizar muito tempo não descendo às folhas. O 'fator de poda' é a fração de todos os ramos possíveis que tivemos que visitar. A força bruta tem um fator de poda de 1. Quanto menor, melhor.