O Sloane publicou uma sequência que eu inventei no OEIS! A sequência é "a quantidade de caminhos de n passos feitos por um rei que começa no canto de um tabuleiro de xadrez infinto". O link é https://oeis.org/A300665
A história da sequência é assim: a gente sabe que o melhor método para resolver puzzles é o exact cover, mas ele só funciona para puzzles tipo sudoku (cada quadrado pode ter só um número), e não funciona em puzzles tipo akari (cada quadrado pode estar iluminado por mais de uma lâmpada).
Mas no começo do ano o Knuth publicou uma variação do exact cover que funciona com todos os puzzles, de fato, funciona com qualquer problema que possa ser descrito como constraint programming.
É claro que a primeira coisa que passou pela minha cabeça foi: "serve para o Torto Reverso?" (*) Quer dizer, é claro que serve, mas é um bom algoritmo na prática? Antes de codificar, eu resolvi estimar qual seria o tamanho da matriz de cover, e de cabeça ela tem que ser mais ou menos da ordem do número de caminhos que um rei por fazer no tabuleiro de xadrez (já que os movimentos do rei são os mesmos movimentos do torto reverso).
Usar os métodos do post de ontem (**) não funciona porque os caminhos não podem repetir casas. Então tem que ser a força bruta mesmo. Fiz um scriptinho em python e damn, a(7)=60215, isso não vai convergir nunca, a matriz é muito grande.
De curiosidade, eu peguei a sequência e coloquei no OEIS para ver se tinha assintótico, e uepa! ninguém tinha calculado essa sequência ainda! Fiz uma implementação em Mathematica para conferir as contas e submeti a sequência.
O povo do OEIS adorou, mas achou pouco. Com o python eu consigo ir até a(12) só e eles queriam mais. Então eu apelei e reimplementei em C++, aí deu para ir até a(15). Mesmo com a cpu em 100% não dá para ir muito além.
Mas eu não me preciso me limitar a 100% de cpu né? Reimplementei em Go e usando 800% de cpu eu consegui o a(16). Depois eu reparei as sequencias são simétricas em relação ao eixo de 45 graus, então só preciso calcular metade delas. Aí cheguei no a(17). Depois disso todas as minhas heurísticas falharam, mas eu ainda não desisti. (Quer dizer, é só deixar o computador ligado uma semana direto que eu pego mais números, mas eu queria um jeito que dê para computar rapidamente).
(*) Se você não conhece o torto reverso, o prêmio ainda não teve ganhadores -> http://blog.ricbit.com/2011/05/torto-reverso.html
(**) Se você perdeu o post de ontem sobre otimização em grafos, ainda dá tempo -> http://blog.ricbit.com/2018/03/a-marcha-dos-lemmings.html
A história da sequência é assim: a gente sabe que o melhor método para resolver puzzles é o exact cover, mas ele só funciona para puzzles tipo sudoku (cada quadrado pode ter só um número), e não funciona em puzzles tipo akari (cada quadrado pode estar iluminado por mais de uma lâmpada).
Mas no começo do ano o Knuth publicou uma variação do exact cover que funciona com todos os puzzles, de fato, funciona com qualquer problema que possa ser descrito como constraint programming.
É claro que a primeira coisa que passou pela minha cabeça foi: "serve para o Torto Reverso?" (*) Quer dizer, é claro que serve, mas é um bom algoritmo na prática? Antes de codificar, eu resolvi estimar qual seria o tamanho da matriz de cover, e de cabeça ela tem que ser mais ou menos da ordem do número de caminhos que um rei por fazer no tabuleiro de xadrez (já que os movimentos do rei são os mesmos movimentos do torto reverso).
Usar os métodos do post de ontem (**) não funciona porque os caminhos não podem repetir casas. Então tem que ser a força bruta mesmo. Fiz um scriptinho em python e damn, a(7)=60215, isso não vai convergir nunca, a matriz é muito grande.
De curiosidade, eu peguei a sequência e coloquei no OEIS para ver se tinha assintótico, e uepa! ninguém tinha calculado essa sequência ainda! Fiz uma implementação em Mathematica para conferir as contas e submeti a sequência.
O povo do OEIS adorou, mas achou pouco. Com o python eu consigo ir até a(12) só e eles queriam mais. Então eu apelei e reimplementei em C++, aí deu para ir até a(15). Mesmo com a cpu em 100% não dá para ir muito além.
Mas eu não me preciso me limitar a 100% de cpu né? Reimplementei em Go e usando 800% de cpu eu consegui o a(16). Depois eu reparei as sequencias são simétricas em relação ao eixo de 45 graus, então só preciso calcular metade delas. Aí cheguei no a(17). Depois disso todas as minhas heurísticas falharam, mas eu ainda não desisti. (Quer dizer, é só deixar o computador ligado uma semana direto que eu pego mais números, mas eu queria um jeito que dê para computar rapidamente).
(*) Se você não conhece o torto reverso, o prêmio ainda não teve ganhadores -> http://blog.ricbit.com/2011/05/torto-reverso.html
(**) Se você perdeu o post de ontem sobre otimização em grafos, ainda dá tempo -> http://blog.ricbit.com/2018/03/a-marcha-dos-lemmings.html
Gostei. Provavelmente daria para fazer o mesmo com outras peças com movimento indiscriminado (podem atingir todas as casas do tabuleiro) e limitado (não podem mover a uma distância infinita num tabuleiro infinito). Ou seja Rei e Cavalo.
ResponderExcluirO cavalo deve gerar outro OEIS!
Talvez já tenha, só computando para ver.
ExcluirE se ao invés do rei começar no canto do tabuleiro ele começar numa posição qualquer? Vai gerar uma sequência diferente. Será que ela já está no OEIS?
ResponderExcluir