Precisamos seguir nossos sonhos segundo a vontade de Deus! Apesar de estarmos com um comparecimento muito baixo (média de 2,5 pessoas por competição), nós não desistiremos, pois não podemos fazer pelos outros, mas também ninguém fará por nós, ou seja, cada um tem consciência do que precisa treinar caso queira algum dia ter um resultado melhor nessas competições. Novamente, fizemos uma prova em equipe, comparecendo somente 2 componentes da Absurdo Clássico e nada mais.

Mid-Atlantic Regional 2010

Como já foi dito aqui, as provas da América do Norte são muito boas para quem está começando a treinar, pois possuem um nível intermediário, ou seja, simula aproximadamente a primeira fase da Maratona de Programação aqui no Brasil. Essa prova possuía 8 questões e nosso desempenho foi um pouquinho melhor do que a passada, pois conseguimos resolver 4 questões em tempo de prova e mais 1 depois, totalizando 5/8 (cinco oitavos) da prova analisados para vocês.

• Problem A: Palindrometer

LA ID: 4868. Link: Palindrometer. Dificuldade (0 a 10): 2. Assunto: Matemática Básica.

Esse problema foi um dos mais fáceis da prova, senão o mais fácil. Ele consistia em encontrar qual era o menor palíndromo maior ou igual do que um número dado. Esse tarefa parece ser bem simples logo de cara, contudo pode se tornar traiçoeira caso você queira ir incrementando o número de 1 em 1 e verificando se ele tornou-se palíndromo, afinal temos limite de N < 10^10 e essa solução lhe daria um belo Time Limit Exceeded. Todavia, não se desespere! Que tal você seguir a ideia de gerar todos os palíndromos de antemão e depois só percorrer a lista e ver qual é o primeiro encontrado maior ou igual ao N dado? Como os números só podem ir até 9 dígitos, então um for simples até 10^4 geraria todos os palíndromos necessários (com casos especiais para uma quantidade ímpar de dígitos). Gostou da explicação? Mande suas dicas e dúvidas!

• Problem B: Balloons

LA ID: 4863. Link: Balloons. Dificuldade (0 a 10): 3. Assunto: Guloso.

Agora chegamos no segundo mais fácil. Um problema de otimização, ou seja, devemos procurar qual o menor valor que satisfaz determinada condição (muito comum em competições de programação). Nesse caso, ele gostaria de saber qual a menor distância a ser percorrida para entregar os balões em uma competição dada a necessidade de cada time e a distância para cada uma das salas (eram 2). Logo de cara, percebe-se que a ideia é gulosa, no entanto podemos cair na armadilha de pensar que o que deve ser observado é a menor distância para as salas, ou seja, ordenar os times pelo mínimo entre a distância para a sala A e a distância para a sala B. Pense em um contra-exemplo para essa ideia! Quase desistíamos de fazer o problema quando vimos que essa ideia falhava, mas percebemos que ainda era guloso, contudo deveríamos ordenar pela diferença entre as distância para as salas, ou seja, entrega primeiro para as equipes que possuem uma maior diferença entre as distâncias. Deu para entender ou a ideia ficou confusa? Leia mais sobre algoritmos gulosos e dê também a sua dica!

• Problem C: Selling Cells

LA ID: 4916. Link: Selling Cells. Dificuldade (0 a 10): ? Assunto: Geometria.

Não conseguimos fazer esse problema. Qualquer dica, nos envie um comentário.

• Problem D: Not One Bit More

LA ID: 4864. Link: Not One Bit More. Dificuldade (0 a 10): 5. Assunto: Matemática, Representação Binária.

Acredito que esse foi o problema que fiquei mais feliz em ter conseguido fazer! Graças a Deus, a ideia foi vindo de pouco em pouco (estávamos eu e Zailton fazendo juntos) e no final tínhamos uma bela resolução. Logo de cara, eu tenho medo de problemas que colocam limites muito altos, como o 10^18 que ele coloca, no entanto dá para perceber que esses limites são realmente para assustar. Como ele conta a quantidade de bits acesos, então em 1 passo o número estaria em, no máximo, 64, pois 10^18 < 2^64. Nesse caso, calculamos a função dada no problema para todos os valores até 64 e, depois fazíamos um for, chamando a nossa função para cada número que tivesse K = X – 1, sendo X o valor passado, pois iríamos calcular os números que em 1 passo chegaria no nosso teste (confuso né?). Nessa nossa função principal (que fazia praticamente todo o cálculo do problema) nós contávamos quantos números menores do que nosso parâmetro possuíam exatamente N bits acesos e deixamos como exercício para você pensar. Para cada chamada, a quantidade de números entre LO e HI com N bits acesos seria f(HI + 1) – f(LO), tratando apenas os casos em que aparece o número 1 na contagem… Será que você também consegue fazer? Tente e depois nos passe suas dúvidas e dicas!

• Problem E: Abstract Extract

LA ID: 4917. Link: Abstract Extract. Dificuldade (0 a 10): ? Assunto: ?

Não conseguimos fazer esse problema. Qualquer dica, nos envie um comentário.

• Problem F: Roller Coaster

LA ID: 4870. Link: Roller Coaster. Dificuldade (0 a 10): 5. Assunto: Programação Dinâmica.

Bem, e esse foi o problema que só conseguimos fazer depois de a competição ter terminado. Na verdade, fiz somente um pouco antes de escrever esse post. Ele é um problema bem interessante e essencial para quem quer se dar bem em competições e aprender algoritmo em si, pois envolve a técnica de Programação Dinâmica (PD), a qual não é trivial de se dominar. De início, havia pensado em uma PD sobre a seção e o enjôo (dizziness), maximizando a diversão que se conseguia, contudo vi que o limite de enjôo era 300.000, enquanto que o de diversão, embora não explicitado na questão, é calculado facilmente como sendo 20.000. Dessa forma, a PD mais tranquila para se fazer, na minha opinião, seria sobre a seção e a diversão alcançada, minimizando o enjôo, ou seja, teríamos uma “recursão” (mas na verdade é preciso fazer essa PD bottom-up, pois não há como armazenar a tabela como um todo, devendo armazenar apenas 2 linhas) em que d(i, j) seria o menor enjôo que poderia se conseguir ao chegar na seção “i” com uma diversão total de “j”, deu para entender? Pense um pouquinho em como implementar essa ideia de forma rápida e, qualquer coisa, mande-nos suas dúvidas!

• Problem G: Spy Cam

LA ID: 4918. Link: Spy Cam. Dificuldade (0 a 10): ? Assunto: ?

Não conseguimos fazer esse problema. Qualquer dica, nos envie um comentário.

• Problem H: Underground Cables

LA ID: 4872. Link: Underground Cables. Dificuldade (0 a 10): 3. Assunto: Grafos, Árvore Geradora Mínima.

Quando comecei a ler esse problema me animei, pois percebi logo que era uma clássica Árvore Geradora Mínima, todavia li um pouco depois “os cabos não podem se cruzar” e pensei: minha ideia foi por água abaixo! Como adaptar o algoritmo de MST para que não haja cruzamento de arestas? Simples: não precisa fazer nada! É possível ver intuitivamente (não tentei provar) que se houver um cruzamento, então haveria outra forma melhor de ter ligado essas arestas, já que o grafo aqui é um grid cartesiano. Portanto, esse problema é muito simples ao ser reduzido para um caso clássico de grafos. Não entendeu a explicação? Mande-nos sua dúvida!

Nessa competição, já pudemos utilizar o BOCA para simular o ambiente da Maratona de Programação e foi um sucesso! A partir de agora, tentaremos sempre utilizar o sistema, a fim de testarmos seu uso e nos acostumarmos mais com a situação. Espero que vocês tentem fazer a prova e obtenham um bom resultado!

Posts interessantes:

• North America – East Central Regional 2010
• Waterloo Contest 2009 – Fall 2
• Computação e Matemática
• Não é apenas o emprego dos sonhos!
• Programando Melhor

E você, tentou fazer a prova do Mid-Atlantic Regional 2010? Conseguiu fazer todas essas questões? Fez alguma das que não conseguimos? Deixe como comentário as suas dúvidas e as suas dicas!

Helton de Melo Duarte

“Purificando a vossa alma na obediência à verdade, para amor fraternal, não fingido, amai-vos ardentemente uns aos outros, com um coração puro” 1 Pe 1.22

Venho aqui para falar da nossa segunda competição de treinamento para a Maratona de Programação. Novamente, compareceram somente os componentes das equipes “Absurdo Clássico” e “Score Limit Exceeded”, da UFRN, apesar de saber que ainda existem alguns que querem mas não estão podendo comparecer. Como já foi dito, quem não pôde ir, tire  5 horas em algum local com sua equipe reunida e tente refazer essa prova, pois irá trazer muito mais conhecimento para vocês.

East Central Regional 2010

Bem, as provas das regionais dos Estados Unidos e Canadá são sempre de um enorme proveito para treinamento, pois consistem de problemas com dificuldade interessante, porém não dos mais difíceis, sendo ideal para equipes que estão começando um treinamento mais pesado, como as nossas equipes da UFRN. Essa prova possuiu 8 questões e nós a fizemos em equipe (na verdade, foram equipes de 2 pessoas, pois só compareceram 4 dessa vez e ainda 2 tiveram que sair mais cedo), conseguindo resolver, ao final, 4 problemas, sendo 3 na hora mesmo da competição e 1 depois do término do tempo. Vejamos como eles são!

• Problema A: Cut it out!

LA ID: 4900. Link: Cut it out! Dificuldade (0 a 10): ? Assunto: ?

Não conseguimos fazer esse problema. Qualquer dica, mande um comentário!

• Problema B: Flip it!

LA ID: 4901. Link: Flip it! Dificuldade (0 a 10): 3 Assunto: Pilhas, Simulação

Esse problema era o segundo mais fácil da prova, acredito eu, pois envolvia somente a manipulação de um tabuleiro de pilhas. É um problema simples de simulação, o qual tem como dificuldade somente o fato de ter que manter cada quadrado do grid como uma pilha, a fim de facilitar as operações descritas no enunciado. Outro cuidado que deve-se tomar é na leitura da linha de operações, a qual é uma string, mas antes foi feita leitura de inteiros, portanto deve fazer um getline() antes, apenas para pegar o ‘\n’ que ainda está no buffer. Mais informações sobre essa limpeza necessária no buffer pode ser encontrado no texto do Shahriar Manzoor. Deu para entender a explicação? Qualquer dúvida, mande um comentário!

• Problema C: Maze

LA ID: 4902. Link: Maze. Dificuldade (0 a 10): ? Assunto: ?

Não conseguimos fazer esse problema. Qualquer dica, mande um comentário!

• Problema D: Photo Shoot

LA ID: 4903. Link: Photo Shoot. Dificuldade (0 a 10): ? Assunto: ?

Não conseguimos fazer esse problema. Qualquer dica, mande um comentário!

• Problema E: Polar Bear

LA ID: 4904. Link: Polar Bear. Dificuldade (0 a 10): 3 Assunto: Grids

Esse problema é de Grids e, aparentemente, bem complexo. Logo que você abre o problema, tem medo do grid circular que aparece, com uma divisões estranhas, contudo esse tipo de grid é para ser tratado praticamente igual a um grid quadrado, o qual nós estamos mais acostumados a lidar. Não entendeu? Se você prestar atenção, vê que cada célula (sem contar as centrais e as de borda) possuem exatamente 8 vizinhos, como em um grid quadrado, mudando somente o fato de que é circular, ou seja, a última “coluna” é vizinha da primeira. Nesse caso, é só preciso tratar os casos especiais, que são descritos no próprio enunciado! Depois de montar o grid, é só fazer a simulação de um Jogo da Vida, assim como nós aprendemos a fazer em OCaml, no 1º semestre do curso (para o pessoal que entrou até 2010, como o meu caso). Alguma dúvida na minha explicação? Mande um comentário!

• Problema F: Pro-Test Voting

LA ID: 4905. Link: Pro-Test Voting. Dificuldade (0 a 10): ? Assunto: ?

Não conseguimos fazer esse problema. Qualquer dica, mande um comentário!

• Problema G: Vampires!

LA ID: 4906. Link: Vampires!. Dificuldade (0 a 10): 2 Assunto: Grids

Esse é o problema mais fácil do contest, envolvendo um grid simples (quadrado) e alguma ideia de como percorrê-lo. Acredito que a única confusão que pode ser feita no problema é tentar partir de cada espelho para chegar nos vampiros e ir armazenando esses encontros nos espelhos, pois deixa a codificação mais complexa e a eficiência do algoritmo menor. A melhor abordagem, pelo menos na minha opinião, é a de partir de cada vampiro até os espelhos e verificar para quais direções ele teria problemas. Fácil, não? Se tiver dúvidas, nos mande comentários!

• Problema H: We’ve Got Chemistry, Babe

LA ID: 4907. Link: We’ve Got Chemistry, Babe. Dificuldade (0 a 10): 7 Assunto: Sitemas lineares, Eliminação de Gauss-Jordan

Esse é certamente o problema mais trabalhoso da competição, tanto é que somente os 2 primeiros lugares da regional que conseguiram resolvê-lo. No entanto, como não estávamos com ideias para os demais problemas, partimos logo para o que a codificação seria mais demorada. A ideia inicial desse problema é conseguir entender como o balanceamento de uma equação química pode ser reduzido a resolução de um sistema linear e esse fato deve a tratar cada coeficiente a ser encontrado como uma variável e cada elemento como uma equação diferente. Além disso, como o problema pede somente os casos de balenceamento único, deve-se considerar somente as situações em que há apenas uma variável livre no sistema e também ignorar os casos em que são encontrados coeficientes não-positivos. Depois de toda essa ideia (e um código já bem extenso), esse problema ainda possui uma leitura de dados bem complexa e trabalhosa, fazendo com que o código cresça mais um bocadinho… Conseguiu fazer? Qualquer dúvida, pode nos perguntar!

E foi esse nosso segundo encontro de treinamento para a Maratona de Programação 2011! Espero que tenham gostado dos comentários e nos vemos na próxima terça-feira, para mais uma competição! (lembrando que agora que o BOCA foi instalado nos servidores do LCC, graças a Edwyn, nossas competições poderão ficar ainda mais realísticas).

Posts interessantes:

• Waterloo Contest 2009 – Fall 2
• Computação e Matemática
• Não é apenas o emprego dos sonhos
• Segmentation Fault – a memória do PC pede ajuda!
• Programando Melhor

E você, fez a competição do East Central Regional 2010? Conseguiu fazer quais questões? Deixe seu comentário com algumas dicas ou dúvidas!

Helton de Melo Duarte

“Mas estende a tua mão, e toca-lhe em tudo quanto tem, e verás se não blasfema de ti na tua face! [...] Em tudo isto Já não pecou, nem atribuiu a Deus falta alguma.” Jó 1.11,22

Eu venho aqui, depois de um tempo enorme, para anunciar uma série de posts que serão feitos aqui no blog, como parte do treinamento das equipes da UFRN para a Maratona de Programação 2011. Nosso treinamento consistirá de diversas reuniões no LCC para simular competições passadas dos mais variados locais do mundo, tanto individuais quanto em equipe e, sempre que possível, no mesmo dia à tarde eu irei fazer um post com algumas dicas para os problemas que conseguirmos fazer. Além das dicas, terá o nível de dificuldade (variando de 0 a 10) e o assunto abordado. O que vocês acharam da novidade?

Começaremos hoje, com uma competição que fizemos individualmente, que é o Waterloo ACM Programming Contest 2009 – Fall 2! Tivemos um comparecimento bem baixo, de apenas 5 pessoas (eu, Edwyn, Lucas, Zailton e Argus), esperando que esse número cresça, mas entendo que algumas pessoas gostariam de estar lá e não puderam, como os calouros de Cien Comp, que tinham aula no horário, além de Álvaro e Leon, que ainda estão em aulas no IFRN. Para vocês que queriam ir e não puderam, tirem 3 horas em casa mesmo e tentem fazer os problemas dessa competição, sem olhar as dicas abaixo; quando terminar o tempo, venha olhar ou dar alguma dica aqui no blog.

Waterloo Contest 2009 – Fall 2

Bem, as competições desenvolvidas pela Universidade de Waterloo, no Canadá, sempre consistem de 5 problemas, para serem resolvido em 3 horas. Desse modo, sempre que formos refazer essas provas, nós iremos competir individualmente, para testar como está o empenho de cada um. Durante a nossa competição, cada competidor só conseguiu fazer o problema E, todavia logo que ela acabou nós nos reunimos para tentar entender a solução do problema C. No final, quando cheguei em casa, pensando mais um bocadinho, consegui ter uma ideia para o problema A. Curtam as dicas:

• Problem A: Rooks

UVa ID: 11699. Link: Rooks. Dificuldade (0 a 10): 5. Assunto: Bitmasks.

Uma ideia interessante para o problema é perceber que com 15 torres você com certeza pode ter todos os quadrados do tabuleiro ocupados, pois você precisa no máximo de uma torre por linha. Dessa forma, podemos testar todos os possíveis subconjuntos das linhas, pois é um total de 32768. Para ver os subconjuntos, pensamos neles como os números de 0 a 32767, pois temos 15 bits “acesos” ou “apagados”, os quais representarão as linhas com ou sem torres. Para cada subconjunto, percorre-se somente as linhas que não possuem torres e verifica-se quantas colunas existem com hashes. Caso o número de colunas seja menor do que ou igual ao de torres, então pode-se colocar uma torre em cada uma dessas colunas (nas linhas “acesas”) e atacar todos os quadrados necessários. Deu para entender? Qualquer dúvida, mande um comentário!

• Problem B: Pipes

UVa ID: 11700. Link: Pipes. Dificuldade (0 a 10): ? Assunto: ?

Não conseguimos fazer esse problema. Qualquer dica, mande um comentário!

• Problem C: Cantor

UVa ID: 11701. Link: Cantor. Dificuldade (0 a 10): 4. Assunto: Sistemas numéricos.

O problema parece simples à primeira vista. Depois de levar o primeiro Wrong Answer, você pensa que ele está errado. Depois descobre que era besteira! Em problemas em que limita-se o número de casas decimais do número para algo baixo (como 6 nesse exemplo), normalmente é muito mais fácil você trabalhar com o número como inteiro, ao multiplicar pela potência de 10 adequada. A ideia é pré-calcular todos os membros e depois fazer somente uma consulta em um vetor. Primeiramente, deve-se calcular os números que no primeiro passo para transformar ele em base 3, já gera um dígito 1. Coloque esses números em uma fila. Além disso, você deve ter uma lista “reversa” para cada número N, indicando de quais números você chegará em N com 1 passo da mudança de base. Assim você marcará cada elemento colocado na fila como NON-MEMBER, e enfileirará aqueles que estão na lista “reversa” dele mas ainda não foram marcados. Deu para entender? Qualquer dúvida, mande um comentário!

• Problem D: Meltdown

UVa ID: 11702. Link: Meltdown. Dificuldade (0 a 10): ? Assunto: ?

Não conseguimos fazer esse problema. Qualquer dica, mande um comentário!

• Problem E: sqrt log sin

UVa ID: 11703. Link: sqrt log sin. Dificuldade (0 a 10): 2. Assunto: Recursão + Memoization.

Esse problema é o mais fácil do contest. E é realmente fácil. Nele, só é preciso implementar a recursão exatamente como é descrito no enunciado, sem alterações, e utilizar um memoization, ou seja, ter um vetor que irá armazenar o valor de Xi para cada 0 <= i <= 1000000, assim que ele for calculado a primeira vez, para que não haja cálculo repetido. Deu para entender? Qualquer dúvida, mande um comentário!

É isso aí, pessoal! Esse foi nosso primeiro treino para a Maratona de Programação 2011 e espero que eu possa ter ajudado vocês com essas dicas!

Posts interessantes:

• Computação e Matemática
• Não é apenas o emprego dos sonhos
• Segmentation Fault – a memória do PC pede ajuda!
• Programando Melhor

E você, como foi no Waterloo Contest 2009 – Fall 2? Gostou das dicas ou estavam meio confusas? Conseguiu resolver qual(is) problema(s)? Faça seu comentário e deixe sua opinião!

Helton de Melo Duarte

“E disse o SENHOR a Satanás: Observaste tu a meu servo Jó? Porque ninguém há na terra semelhante a ele, homem sincero, e reto, e temente a Deus, e desviando-se do mal.” Jó 1.8

Venho treinando nos últimos dias com o foco na OBI 2010 e, quem sabe, na IOI 2010 (se Deus quiser!), no site de treinamento da equipe dos Estados Unidos, mais conhecido como USACO Training Program e percebi que é uma fonte impressionante de treinamento para competições de programação, especialmente as citadas acima. Durante algumas resoluções de problemas me deparei com um erro chamado “Segmentation Fault” quando eu tentava executar o programa e resolvi pesquisar a respeito para esclarecer melhor na minha mente e poder passar a todos, já que não é um erro tão raro de ocorrer em programas.

Quando se tem um irmão expert em C++ e amante de competições de programação assim como eu tenho, é bem mais fácil tirar as dúvidas, portanto segue a explicação (adaptada) que Herbert Duarte deu para esse problema.

Segfault, como também é conhecido, ocorre quando um programa está tentando acessar uma área de memória protegida, ou seja, que não faz parte de seu endereçamento (espaço da memória revervado pelo Sistema Operacional para cada um dos programas que estão sendo executados), ou quando tenta acessar um local de forma inapropriada, como por exemplo, tentando escrever em um espaço que é de somente-leitura. As causas mais comuns para esse tipo de erro são as seguintes:

• Ponteiros não inicializados ou com valores inválidos, pois quando o programa tenta acessá-lo provavelmente irá cair em algum lugar aleatório da memória que o programa não tem acesso;
• Acessar uma posição inválida de matrizes ou vetores, já que o programa irá calcular a posição como se ela existisse e provavelmente irá cair em um local sem acesso (ocorrendo frequentemente quando o programa calcula, em alguma situação, uma posição para ser acessada, porque, se houver qualquer erro nesse cálculo, a posição acessada será inválida);
• Tentar alterar um caracter de uma string que foi inicializada como “Somente leitura”.

Bem, dessa forma, espero que cuidem melhor de seus programas para não caírem nesse mesmo erro, lembrando apenas que Segmentation Fault não é um erro de compilação de código, mas um erro de execução de programa.

Fonte para auxílio: Segmentation Fault – Wikipedia

Posts interessantes:

• Treinando para a OAH 2009
• Google Code Jam 2009: uma nova oportunidade
• Categoria: Programando Melhor

Mais algum erro está perturbando vocês? Comente e nos conte que procuraremos sempre ajudá-lo!

Helton de Melo Duarte

“Eu, porém, estou aflito e necessitado; apressa-te por mim, ó Deus; tu és o meu auxílio e o meu libertador; SENHOR, não te detenhas.” Salmos 70.5

“Por ti tenho sido sustentado desde o ventre; tu és aquele que me tiraste do ventre de minha mãe; o meu louvor será para ti constantemente.” Salmos 71.6

Bem, pessoal, como alguns já devem saber, próxima sexta-feira acontece em todo o Brasil a primeira fase da III Olimpíada de Algoritmo Hostnet e estarei participando mais um ano, em busca do bicampeonato =D. A fim de treinarmos para essa competição, resolvi fazer esse post, dando umas dicas e um exercício, como exemplo, para vocês tentarem fazer. OBS: Quem quiser saber se resolveu corretamente, faça um comentário dizendo isso que entrarei em contato por e-mail, ok?

Dicas

Tirando como base as dicas do site da Maratona de Programação e o artigo do Shariar Manzoor na revista Crossroads, pensei em umas dicas básicas:

• Não há nada pior do que gastar muito tempo fazendo e passando a limpo um algoritmo para, depois, descobrir que ele está errado. Na OAH, esse erro é fatal, já que o tempo é sempre um grande adversário. Por isso, apesar de a pressa ser necessária, procure sempre certificar-se da corretude do algoritmo ANTES de escrevê-lo!
• A escolha de seu time é essencial. Um bom time de programação precisa que cada componente tenha um conhecimento de algoritmos básicos (ordenação, encontrar n-ésimo número primo, calcular MDC/MMC, etc.), além da capacidade de criar novos para situações diversas.
• Ao treinar, certifique-se de que cada membro do time sabe fazer o básico, como escrever procedimentos e fazer “debug” de um algoritmo. Um time bem-sucedido terá membros com algumas especialidades, como aquele que resolve problemas com busca, ou aquele bom em matemática, ou aquele que encontra erros facilmente. Todos os membros devem saber as qualidades e defeitos dos outros para saber quem ficará responsável por cada questão.
• Todos devem estar aptos para realizar Pair-Programming, ou seja, resolver uma das questões juntamente com outro membro, principalmente as mais difíceis. Não aconselho que fiquem os 3 membros pensando sobre o mesmo problema, a não ser em casos extremos.
• Faça treinos de simulação, pois é a melhor forma de fazer a prova em um bom tempo. Treinar nas mesmas condições da competição é uma ótima dica, ou seja, fazer uma prova passada com o tempo cronometrado e depois pedir para um professor da instituição corrigí-la.
• Faça muitas questões daqui para sexta-feira!

Exercício

Coleta de Lixo Ecológica (traduzido e adaptado de “Ecological Bin Packing”, do UVa Online Judge)

O Problema

Reciclar vidro requer que ele seja separado por cor em uma das três categorias: vidro marrom, vidro verde e vidro transparente. Nesse problema você terá 3 latas de lixo, cada uma contendo um número específico de garrafas marrom, verde e transparente. No intuito de serem recicladas, as garrafas terão de ser movidas a fim de cada lata de lixo conter apenas garrafas de uma cor.

O problema é minimizar o número de garrafas que serão movidas. Você deve assumir que o único problema é minimizar o número de movimentos entre os cestos de lixo. Para a proposta desse problema, cada lixo tem a capacidade de armazenar infinitas garrafas e a única restrição é movê-las para cada cesto conter garrafas de uma única cor.

A Entrada

A entrada que seu programa irá ler consiste em uma linha contendo nove inteiros. Os primeiros três inteiros representam o número de garrafas marrons, verdes e transparentes (respectivamente) na lata 1, os segundos três inteiros representam o número de garrafas marrons, verdes e transparentes (respectivamente) na lata 2, os últimos três inteiros representam o número de garrafas marrons, verdes e transparentes (respectivamente) na lata 3. Por exemplo, a linha 10 15 20 30 12 8 15 8 31, indica que há 20 garrafas transparentes na lata 1, 12 garrafas verdes na lata 2 e 15 marrons na lata 3.

A Saída

A saída indicará as garrafas de que cores que estarão em cada lata para minimizar o número de movimentos. Você também deve escrever o número mínimo de movimentos com as garrafas para que isso ocorra.

O programa deverá escrever uma string com três letras maiúsculas ‘M’, ‘V’ e ‘T’ (representando as cores marrom, verde e transparente) representando a cor associada a cada lata de lixo.

O primeiro caracter representa a cor relacionada com a primeira lata, o segundo caracter representa a cor relacionada com a segunda lata e o terceiro caracter representa a cor relacionada com a terceira lata. Além disso, o inteiro representando o menor número de movimentos a serem feitos deverá vir seguido da string, separados com um espaço.

Se mais de uma ordem de latas marrom, verde e transparente produzir o número mínimo de movimentos, então a string que vier primeiro alfabeticamente deverá ser escrita.

Exemplo de Entrada 1

1 2 3 4 5 6 7 8 9

Exemplo de Saída 1

MTV 30

Exemplo de Entrada 2

5 10 5 20 10 5 10 20 10

Exemplo de Saída 2

TMV 50

Com isso, nossas dicas para a OAH 2009 estão dadas, então eu desejo a todos os competidores, desde já, boa sorte! Mostrem a todos que vocês são capazes, mas não esqueçam, Deus é o único responsável por qualquer conquista sua.

Posts interessantes:

• Categoria: Cursos – Programando Melhor
• Google Code Jam 2009: uma nova oportunidade
• Top Coder Marathon Matches
• OAH 2008

Vamos lá, treine bem para mais essa competição! Comente e diga qual colégio estará representando, além do mais, tire qualquer dúvida!

Helton de Melo Duarte

“O justo se alegrará no SENHOR e confiará nEle; e todos os retos de coração se regozijarão.” Salmos 64.10

“Bendito seja Deus, que não rejeitou a minha oração, nem desviou de mim a sua misericórdia.” Salmos 66.20

Hoje teremos a última parte da aula de grafos (foi dividida em 3), sendo também nossa aula final antes da 2ª fase da OBI. Contudo, o curso Programando Melhor não irá terminar, ele continuará presente no blog, com a apresentação futura de tópicos sobre Programação Dinâmica e alguns assuntos interessantes, conforme eu for descobrindo, ok? Além disso, o blog voltará a ter posts sobre assuntos variados, envolvendo a área de TI em geral, não sendo focado apenas para a parte de Programação (contudo a maioria ainda será de programação, por ser minha “especialidade”).

Aula 8 – Grafos III

Conteúdo: Apresentação de mais alguns conceitos da teoria dos grafos, assim como algoritmos para resolução da Árvore Geradora Mínima e do menor caminho em um grafo valorado.

Teoria dos grafos é o estudo das propriedades das estruturas feitas com grafos. Com ela (a teoria) é possível ter uma linguagem comum ao tratar desse assunto, sendo a chave para resolver muitos problemas o fato de identificar esses conceitos fundamentais e implementar algoritmos clássicos para resolvê-los.

Propriedades dos graus

A propriedade mais simples de um vértice é seu grau, ou seja, a quantidade de arestas que incidem sobre ele. Existem diversas propriedades importantes do grau de um vértice, como a soma de todos os graus ser igual ao dobro do número de arestas, pelo fato desta contribuir para o grau de vértices adjacentes. Uma consequência disso é que qualquer grafo possui um número par de vértices com grau ímpar.

Árvores são grafos indiretos que não contém ciclos. Os graus dos vértices são importantes para a análise de árvores. A folha de uma árvore é um vértice com grau 1. Cada grupo de n vértices, contém n-1 arestas, portanto uma árvore possui no mínimo duas folhas. Ao retirar uma folha diminui-se a árvore, sem disconectá-la.

Uma árvore geradora de um grafo G = (V, E) é um subconjunto de arestas E’ contido em E, tal que E’ é uma árvore com os vértices V. Esse tipo de árvore existe para qualquer grafo conexo (com todos os vértices ligados entre si por algum caminho) e é visto pela relação estabelecida no vetor parent[ ], em buscas em largura e profundidade.

Árvore Geradora Mínima

Utilizada em grafos valorados, a árvore geradora mínima consiste em buscar a árvore geradora que possui a menor soma dos valores de suas arestas. São a resposta ao tratarmos de problemas sempre que precisarmos ligar um conjunto de pontos pela menor quantidade de canos, fios, etc.

Há dois algoritmos principais para tratar de árvores geradoras mínimas, o de Kruskal e o de Prim, contudo irei abordar aqui apenas o segundo, por ser mais simples e nos dar uma ótima base para enterder o menor caminho de Dijkstra, a seguir.

Primeiramente, generalizaresmos a estrutura de grafos implantada nas aulas anteriores, para utilizarmos grafos valorados.

typedef struct {

int v;            /* vértice adjacente */

int valor;    /* valor da aresta */

} aresta;

typedef struct {

edge edges[MAXV+1][MAXGRAU];    /* informação de adjacência */

int grau[MAXV+1];                                    /* grau de cada vértice */

int nvertices;                                                /* número de vértices no grafo */

int narestas;                                                  /* número de arestas no grafo */

} grafo;

OBS: lembrando também de ajeitar a inicialização e as buscas apropriadamente, o que não é trabalho complicado.

O algoritmo de Prim começa de um vértice inicial e a cada iteração é adicionado um novo vértice na árvore geradora, ligando sempre o menor valor de um vértice dentro da árvore para um vértice fora. A implementação abaixo mantém todas as arestas dos vértices já inclusos na árvore para vértices não-inclusos, sendo o menor incluído na próxima iteração.

prim (grafo *g, int start)
{
int i;      /* contador */
bool intree[MAXV];           /* esse vértice está na árvore? */
int distance[MAXV];          /* distância do vértice ao start */
int v;                       /* vértice atual para ser processado */
int w;                       /* candidato para próximo vértice */
int weight;                  /* valor da aresta */
int dist;                    /* menor distância atual */

for (i=1; i<g->nvertices; i++)
{
intree[i] = FALSE;
distance[i] = MAXINT;
parent[i] = -1;
}

distance[start] = 0;
v = start;

while (intree[v] == FALSE) {
intree[v] = TRUE;

for (i=0; i<g->nvertices; i++)
{
w = g->edges[v][i].v;
weight = g->edges[v][i].weight;

if ((distance[w] > weight) && (intree[w] == FALSE))
{
distance[w] = weight;
parent[w] = v;
}
}

v = 1;
dist = MAXINT;

for (i=2; i<=g->nvertices; i++)
{
if ((intree[i] == FALSE) && (dist > distance[i]))
{
dist = distance[i];
v = i;
}
}
}
}

Algumas alterações nesse método podem (e normalmente devem) ser feitas, de acordo com a necessidade do problema, como imprimir cada aresta, à medida que são encontradas ou armazenar o valor da soma de todas as arestas da árvore, para retornar no final. Ou seja, foi dado o queijo e a faca para vocês, resta saberem cortá-lo. Algumas variações são, por exemplo, a árvore geradora máxima (sendo preciso apenas deixar os valores das arestas negativos), árvore com menor produto possível das arestas (substituindo o valor da aresta pelo seu logaritmo).

Menor caminho

O problema de encontrar o menor caminho em grafos não-valorados, já foi discutido na aula anterior, sendo apenas necessário o uso de uma busca em largura, no entanto hoje iremos mostrar um algoritmo básico (e eficiente) para tratar desses “novos tipos de grafos”:  Dijkstra.

Floyd-Warshall é outra opção, mas já fora tratado no aula de Revisão para a primeira fase da OBI, nesse blog, com a aplicação no problema Batuíra, da seção pratique do site da Olimpíada Brasileira de Informática e, portanto, não será mais abordado (deem uma olhada no post de Revisão para entender o código).

O algoritmo de Dijkstra é um método para encontrar o menor caminho entre dois vértices de um grafo valorado. Dado um vértice particular s, ele encontrará o menor caminho de s para qualquer outro vértice do grafo, incluindo o seu destino t.

A idéia é praticamente igual a de Prim, na árvore geradora mínima. A diferença entre eles é como comparar se o próximo vértice é o desejável. No menor caminho nós buscamos o vértice em que a distância até o atual MAIS o seu valor será menor do que o comparado, ou seja:

if (distance[w] > (distance[v]+weight)) {

distance[w] = distance[v] + weight;

parent[w] = v;

}

Ao contrário do algoritmo de Prim, Dijkstra não pode trabalhar com valores negativos, porém esse problema é insignificante, já que não há aplicação prática para tais valores. Não se esqueça de exercitar:

• Freckles – Nível 2
• The Necklace – Nível 3
• Fire Station – Nível 2
• Railroads – Nível 3
• War – Nível 3
• Tourist Guide – Nível 3
• The Grand Dinner – Nível 4
• The Problem With the Problem Setter – Nível 3

PS: Todo o conteúdo desse post e de todo o curso “Programando melhor” é baseado no livro Programming Challenges, de autoria de Miguel Revilla e Steve Skiena e foi permitido o “resumo” e tradução do mesmo pelos próprios autores para a criação desse curso. Além disso os exercícios estão todos disponibilizados no site UVa Online Judge.

Com isso, terminamos nossas dicas antes da 2ª fase da OBI, o que posso fazer agora é desejá-los boa prova e que Deus vos abençoe. Atentem principalmente para os assuntos dos posts recomendados a seguir:

Posts interessantes:

• Programando melhor: Revisão
• Programando melhor: Aula 5 – Backtracking
• Programando melhor: Aula 6 – Grafos I
• Programando melhor: Aula 7 – Grafos II

Vamos lá, estamos na reta FINAL! Comentem e tirem suas dúvidas!

Helton de Melo Duarte

“Os preceitos do SENHOR são retos e alegram o coração; o mandamento do SENHOR é puro e alumia os olhos.” Salmos 19.8

Como esperado por muitos, o resultado da OBI saiu completamente ontem. Para o RN o resultado foi bom na categoria iniciação (mais de 100 aprovados), porém deixou a desejar na de Programação, tendo 2 aprovados em Júnior, 1 no nível 1 e 5 no nível 2. Como continuação do nosso preparo para a segunda fase da competição, teremos hoje a segunda aula sobre Grafos!

Aula 7 – Grafos II

Conteúdo: Aprofundamento com as buscas em largura e profundidade em um grafo, além do menor caminho em grafos não-valorados.

A operação básica na maioria dos grafos é percorrê-lo completamente e sistematicamente. É preciso visitar cada vértice e cada aresta exatamente uma vez em uma ordem pré-definida. Existem dois tipos primordiais de algoritmos para realizar essa atividade: Busca em Largura (BFS, do inglês Breadth-First search) e Busca em Profundidade (DFS, do inglês Depth-First search). A diferença entre não é nem percebida em certos problemas, pois eles compartilham uma idéia fundamental: marcar os vértices já explorados para não repetir ações.

Busca em Largura

A Busca em Largura é apropriada se nós não precisarmos de uma ordem específica para a busca ou se nós estamos interessados no menor caminho entre dois vértices para grafos não-valorados. A sua implementação utiliza duas vetores Boolean para manter o conhecimento sobre todos os vértices. Um vértice é descoberto a primeira vez que o visitamos. Um vértice é considerado processado depois de passarmos por todas as arestas provenientes dele.

Uma vez que o vértice é descoberto, ele é colocado em uma fila, sendo processados na ordem de chegada, pois os vértices mais antigos na fila são os mais próximos da raiz (local de partida para a busca). Para não encher o post somente com código, colocarei diversos links falando sobre BFS, para vocês darem uma olhada neles, depois voltarem para a continuação do post.

• Busca em largura – Wikipédia
• Busca em largura – IME/USP
• Busca em largura – IME/USP – outra explicação
• Breadth-first search – Wikipedia

O comportamento exato da BFS depende das funções de processar o vértice e processar a aresta, sendo essa a forma de personalizar a busca, podendo imprimí-los ou contar o número de arestas. Outra forma de personalizar é na função Boolean de validar a aresta, ignorando as não existentes. Ao retornar sempre true, percorreremos todas arestas, sendo uma BFS completa.

Encontrando caminhos

O vetor parent utilizado na bfs( ) é muito útil para encontrar caminhos em um grafo. O vértice que descobriu i é denominado parent[i]. Essa relação define uma árvore de descobertas com o nó inicial como a raiz da árvore.

Pelo fato dos vértices serem descobertos em ordem crescente de distância da raiz, essa árvore tem uma propriedade muito importante. O caminho da raiz até x (um dos vértices) utiliza o menor número de arestas possível para esse caminho.

Ele pode ser reconstruído seguindo os “ancestrais” de x até a raiz, pelo vetor parent[ ], contudo será um caminho do fim para o começo. Nós podemos “consertá-lo” ao guardá-los em uma pilha. É preciso lembrar de dois pontos cruciais na utilização de BFS: só é possível descobrir o menor caminho entre x e y, se x for a raiz do grafo; além disso, essa ação só é realizada com eficiência em grafos não-valorados.

Busca em Profundidade

Busca em profundidade utiliza a mesma idéia do Backtracking, mostrado na Aula 5 desse curso. Ambos envolvem a busca de todas as possibilidades ao avançar quando for possível e recuar quando não houver nada inexplorado à frente, sendo mais facilmente entendíveis como algoritmos recursivos. Essa busca pode ser pensada como BFS com uma pilha ao invés de fila. A parte bela dessa implementação é que a recursividade elimina a existência explícita de uma pilha, contudo não irei mostrar aqui o algoritmo completo, novamente sugerindo sites para vê-lo:

• Busca em Grafos – UFSC
• Busca em profundidade – Wikipédia
• Busca em profundidade – IME/USP
• Busca em Grafos

Com essa abordagem, chegamos ao final de mais uma aula de grafos, faltando apenas a abordagem de algoritmos como o de Dijkstra e da Árvore Geradora Mínima, os quais serão abordados próxima semana. Abaixo estão dispostos os exercícios a respeito das aulas 6 e 7:

• Bicoloring – Nível 1
• Playing With Wheels – Nível 2
• The Tourist Guide – Nível 3
• Slash Maze – Nível 2
• Edit Step Ladders – Nível 3
• Tower of Cubes – Nível 3
• From Dusk Till Dawn – Nível 3
• Hanoi Tower Troubles Again! – Nível 3

PS: Todo o conteúdo desse post e de todo o curso “Programando melhor” é baseado no livro Programming Challenges, de autoria de Miguel Revilla e Steve Skiena e foi permitido o “resumo” e tradução do mesmo pelos próprios autores para a criação desse curso. Além disso os exercícios estão todos disponibilizados no site UVa Online Judge.

Posts interessantes:

• Divulgação OBMEP
• Programando melhor: Aula 6 – Grafos I
• Programando melhor: Aula 5 – Bracktracking
• Programando melhor: Revisão
• Programando melhor: Aula 2 – Estrutura de Dados

Vamos lá pessoal! Essas últimas aulas serão cruciais para a segunda fase da OBI, preparem-se! Qualquer dúvida ou dica, COMENTEM!

Helton de Melo Duarte

“Os céus manifestam a glória de Deus e o firmamento anuncia a obra das suas mãos.” Salmos 19.1

“A lei do SENHOR é perfeita e refrigera a alma; o testemunho do SENHOR é fiel e dá sabedoria aos símplices.” Salmos 19.7

Hoje iniciaremos um assunto pedido a muito tempo por meus conhecidos: os tão temidos grafos! Contudo, eu já posso adiantar que eles não são complicados como vocês pensam, pelo menos o nível cobrado na OBI. Os conceitos principais podem ser vistos em diversos locais, como nos sites da UFSC e USP, sendo essa uma área muito ampla da computação, recebendo muitas vezes uma disciplina completa nos cursos de Ciência e Engenharia da Computação. Para quem gosta de matemática, há também uma oportunidade de estudá-la, como no curso de iniciação científica da OBMEP.

Aula 6 – Grafos I

Conteúdo: introdução aos conceitos, juntamente com as formas de utilizá-los no campo da computação.

Grafos são um dos temas mais interessantes da ciência da computação – uma representação abstrata que descreve a organização de sistemas de transporte, circuitos elétricos, linhas de telecomunicações, etc. Tantas estruturas diferentes podem ser modeladas utilizando esse conceito, tornando-o uma grande fonte de resolução de problemas. Será vistos hoje apenas o elementar dessa teoria, pela sua vasta abrangência, deixando os algoritmos mais específicos para as próximas aulas.

Tipos de Grafos

Um grafo G = (V, A) é definido por um conjunto de vértices V e um conjunto de arestas A, as quais consistem em pares de vértices contidos em V. Há diversas propriedades fundamentais dos grafos que influenciam na escolha de estruturas de dados  utilizadas para representá-los e os algoritmos para analisá-los. Vamos determinar quais são essas propriedades:

• Indireto vs. Direto - Um grafo G = (V, A) é indireto se a aresta (x, y) pertencer a A e isso implicar que (y, x) também pertence. Se não, é tido como grafo direto. Ex: Ligações por estradas entre cidades são tipicamente indiretas, porque as estradas são de mão-dupla.
• Valorado vs. Não-Valorado - Em grafos valorados, cada aresta (ou vértice) de G é assinalada com um valor numérico, ou peso. Uma aplicação típica são estradas, as quais são valoradas com a distância ou o tempo para percorrê-la. A diferença entre esses tipos é basicamente para encontrar o menor “caminho” entre dois vértices.
• Simples vs. Não-Simples – Certos tipos de arestas complicam a tarefa de trabalhar com grafos. Um laço é uma aresta (x, x) envolvendo somente um vértice. Uma aresta (x, y) é múltipla se ocorre mais de uma vez no mesmo grafo. Um grafo que não possui nenhum desses tipos de aresta é chamado Grafo Simples.

Estrutura de Dados para Grafos

Há muitas formas possíveis de representar um grafo, por isso nos focalizaremos nas mais comuns e úteis. Será assumido o grafo G = (V, A) contendo n vértices e m arestas.

• Matriz de adjacência – Nós podemos representar G usando uma matriz M n x n, onde o elemento M[i,j] é 1 se (i, j) é uma aresta de G e 0 (zero) se não for. Isso permite respostas rápidas para a questão “(i,j) está em G?” e atualizações rápidas para inserir ou deletar arestas. Todavia, esse tipo de representação pode usar espaço excessivo na memória, ao ter muitos vértices e poucas arestas.
• Listas de adjacência – Uma forma mais eficiente de representar é usando listas encadeadas para guardar os adjacentes a cada vértice. Esse tipo requer ponteiros mas não tenha medo se já passou por experiências desagradáveis com eles. Listas de adjacência dificulta para saber se (i, j) está em G, contudo é MUITO mais econômico com memória.
• Listas de Adjacência em Matrizes – Listas de adjacências podem estar embutidas em matrizes, eliminando a necessidade de ponteiros. Nós podemos representar a lista em um vetor (ou na linha de uma matriz) mantendo um contador k de quantos elementos há e colocando-os nos primeiros k elementos do vetor. Agora é possível visitar os elementos do primeiro ao último da mesma forma deuma lista, mas incrementando o índice em um loop ao invés de ponteiros. Esse forma é particularmente importante no caso de grafos estáticos, os quais não mudam após sua construção e será sempre utilizada nos exemplos seguintes.

Nós representamos um grafo usando a seguinte estrutura de dados: para cada grafo nós contabilizamos o número de vétices e os assinalamos de 1 a nvertices. As arestas estão em uma matriz MAXV x MAXGRAU, para cada vértice poder ser adjacente a outros MAXGRAU. Podemos definir MAXGRAU como MAXV, contudo isso seria desperdício em casos de grafos com graus baixos.

#define MAXV 100;              /* máximo número de vértices */

#define MAXGRAU 50;       /* máximo grau de um vértice */

typedef struct {

int arestas [MAXV+1][MAXGRAU];       /* informação de adjacência */

int grau[MAXV+1];            /* grau de cada vértice */

int nvertices;                        /* número de vértices no grafo */

int narestas;                        /* número de arestas no grafo */

} grafo;

Para demonstrar o uso dessa estrutura de dados, nós mostraremos como ler um grafo, tendo uma linha inicial o número de vértices e arestas no grafo, seguido por uma lista de arestas com um par de vértices por linha.

ler_grafo (grafo *g, bool direto)

{

int i;          /* contador */

int m;       /* número de arestas */

int x, y;   /* vértices em uma aresta (x, y) */

inicializar_grafo (g);

scanf (“%d %d”, &(g->nvertices), &m);

for (i = 1; i <= m; i++) {

scanf (“%d %d”, &x, &y);

inserir_aresta (g, x, y, direto);

}

}

inicializar_grafo (grafo *g)

{

int i;            /* contador */

g->nvertices = 0;

g->narestas = 0;

for (i = 1; i <= MAXV; i++) g->grau[i] = 0;

}

O método principal é o inserir_aresta. O parâmetro Boolean direto é utilizado para identificar quando é preciso inserir duas cópias de cada aresta ou só uma. Preste atenção no uso da recursão para resolver o problema.

inserir_aresta (grafo *g, int x, int y, bool direto)

{

if (g->grau[i] > MAXGRAU)

printf (“Atenção: a inserção (%d, %d) excede o grau máximo\n”, x, y);

g->arestas[x][g->grau[x]] = y;

g->grau[x] ++;

if (direto == FALSE) inserir_aresta(g, y, x, TRUE)

else g->narestas ++;

}

Agora, a tarefa de imprimir o grafo é um trabalho bem simples:

imprimir_grafo (grafo *g)

{

int i, j;                 /* contadores */

for (i = 1; i <= g->nvertices; i++) {

printf (“%d:  “, i);

for (j = 0; j <= g->grau[i]; j++) {

printf (” %d”, g->arestas[i][j]);

}

printf (“\n”);

}

}

Bem pessoal, por hoje é só. Infelizmente, os algoritmos de manipulação mais específica de um grafo ficarão para a próxima aula, ok? E, como foram dados apenas conceitos, excepicionalmente hoje não haverá seção de exercícios. =(

Posts interessantes:

• Programando melhor: Aula 5 – Backtracking
• Programando melhor: Revisão
• Programando melhor: Aula 4 – Ordenação
• Programando melhora: Aula 3 – Strings

O que vocês acharam de grafos? Qualquer dúvida é só Comentar! Para treinar, façam os exercícios da apostila de grafos da iniciação científica da OBMEP, indicada no início, pois são muito bons. Além do mais, qualquer erro, principalmente na parte de código, porque é frequente o WordPress deixar estranho, é só avisar por comentário, ok?

Helton de Melo Duarte

“A minha alma disse ao SENHOR: Tu és o meu SENHOR; não tenho outro além de ti.” Salmos 16.2

Para quem estava com saudades das aulas do “Programando melhor”, venho anunciar a volta com tudo do curso! Estive parado durante um tempo para resolver a migração do blog, além de estabelecer a parceria com a Hostnet, empresa a qual hospeda esse site. No entanto, tenho a alegria de informá-los que mais uma aula está pronta!

Aula 5 – Backtracking

Conteúdo: Explicação a respeito de algoritmos de Backtracking, técnica facilitadora em casos de problemas pesados.

A força bruta pode ser eficiente na resolução de problemas simples na área de computação, devido ao grande poder já presente nos computadores atuais, com média de 2GHz de clock do processador, ou seja, realizando 2 bilhões de operações por segundo! Contudo, existem casos em que a complexidade da situação exige técnicas mais sofisticadas, sendo uma delas o Backtracking!

Backtracking é um método para iterar (percorrer) todas as possíveis configurações em um espaço qualquer. É um algoritmo geral que poderá ser personalizado para cada tipo de aplicação. De modo geral, a solução será um vetor a = (a1, a2, …, a-n), sendo cada elemento a-i selecionado de um conjunto Si. Os exemplos mais comuns, os quais serão mostrados posteriormente, são a criação de permutações e de subconjuntos.

A cada passo do algoritmo, começa-se com uma solução parcial, diga-se a = (a1, a2, …, a-k), e tenta-se aumentá-la, adicionando outro elemento ao seu fim. Após adicioná-lo, é preciso testar se há uma solução completa – se sim, deve-se imprimí-la, contá-la ou qualquer ação necessária. Se não é necessário checar se essa solução parcial é ainda expansível para alguma completa. Se for, continue testando, se não então apague o último elemento de a e teste outra possibilidade para aquela posição. O código é mostrado abaixo:

bool finished = FALSE;          /* Já encontrou todas as soluções? */

backtrack (int a[], int k, data input)

{

int c[MAXCANDIDATES];       /* Candidatos para a próxima posição */

int ncandidates;                         /* Número de candidatos para a próxima posição */

int i;            /* Contador */

if (is_a_solution(a, k, input))

process_solution(a, k, input);

else {

k = k + 1;

construct_candidates (a, k, input, c, &ncandidates);

for (i = 0; i<ncandidates; i++) {

a[k] = c[i];

backtrack(a, k, input);

if (finished) return;             /* Terminar mais cedo */

}

}

}

As sub-rotinas utilizadas no algoritmo serão especificadas abaixo:

• is_a_solution(a, k, input) – Esse função booleana testa se os primeiros k elementos do vetor a são uma solução completa. O último argumento, input, permite-o utilizar informações proveitosas para essa rotina.
• construct_candidates(a, k, input, c, &ncandidates) – Preenche um vetor c com todos os candidatos possíveis para a k-ésima posição de a, dado o conteúdo das primeiras k-1 posições. O número de candidatos retornado é ncandidates e a variável input é novamente para alguma função auxiliar necessária.
• process_solution(a,k) – Esse método apenas imprime, conta ou faz algo necessário para o determinado problema, quando uma solução completa está pronta. A variável auxiliar, input, é desnecessária nessa situação.

Backtracking assegura o acerto por enumerar todas as possilidades sem visitar nunca o mesmo estado, sendo também eficiente. A recursividade promove a elegância e a fácil implementação desse algoritmo, porque o vetor de novos candidatos, c, é alocado com um procedimento recursivo.

As principais aplicações do backtracking são da criação de todos os subconjuntos de um conjunto S e na criação de todas as suas permutações. Os links foram colocados para o Wikipédia para que o post não fique muito grande, ok?

Abaixo seguem os exercícios para o treinamento do assunto (confesso que estão difíceis dessa vez):

• Little Bishops – Nível 2
• 15-Puzzle Problem – Nível 3
• Queue – Nível 2
• Servicing Stations – Nível 3
• Tug of War – Nível 2
• Garden of Eden – Nível 2
• Color Hash – Nível 3
• Bigger Square Please… – Nível 3

PS: Todo o conteúdo desse post e de todo o curso “Programando melhor” é baseado no livro Programming Challenges, de autoria de Miguel Revilla e Steve Skiena e foi permitido o “resumo” e tradução do mesmo pelos próprios autores para a criação desse curso. Além disso os exercícios estão todos disponibilizados no site UVa Online Judge.

Posts interessantes:

• Programando melhor: Revisão
• Programando melhor: Aula 4 – Ordenação
• OBI vem aí!
• Programando melhor: Aula 3 – Strings

Vamos lá, pessoal! Não desistam porque estamos em preparação para a segunda fase da OBI, agora é pra valer! Comentem sobre o que vocês acharam do post e tirem suas dúvidas!

Helton de Melo Duarte

“O SENHOR prova o justo, mas a sua alma aborree o ímpio e o que ama a violência.” Salmos 11.5

Como a prova da primeira fase da OBI é amanhã resolvi fazer esse post para uma revisão rápida de vocês sobre algumas questões importantes.

Primeiramente, quero avisá-los para termos bastante atenção com a quantidade de loops feitos, pois diversos loops encadeados podem fazer você não passar em alguns dos testes feitos (normalmente passará nos mais simples, contudo não conseguirá a pontuação completa).

Segundo vim trazer mais um assunto possível para a prova, o qual explicarei posteriormente na aula sobre grafos, no entanto colocarei um exemplo de fácil entendimento da seção pratique da OBI, do nível 2, Batuíra (código resolvido abaixo):
#include

#define INF 1000000;

int main()
{
/* Batuíra */
int num = 1; /* Número do teste */
int n, x, y, z; /* Quantidade de pontos e variáveis para distância */
int dist[110][110]; /* Grafo para distância dos pontos */
int i, j, k; /* Contadores para loop for */

/* O Grafo dist[110][110] representa as distâncias entre os pontos de
repouso. Por exemplo, o valor de dist[i][j] é a distância entre os pontos
i e j */

/* Entrada do número de pontos */
scanf (“%d”, &n);

while (n != 0)
{
/* Coloca a distância padrão entre os pontos */
for (i = 1; i <= n; i++)
{
for (j = 1; j <= n; j++)
{
if (i == j)
{
dist[i][j] = 0; /* A distância para o próprio
ponto de repouso é zero */
}
else
{
dist[i][j] = INF; /* Diz que a distância entre os pontos
é “infinita”, ou seja, não há ligação entre eles */
}
}
}

/* Lê os pontos e a distância entre eles */
scanf (“%d %d %d”, &x, &y, &z);
/* A distância do ponto x ao ponto y é igual a z */

while (x != 0) /* Quando qualquer valor for zero é o fim da
entrada dos pontos */
{
/* Coloca as distâncias nas duas direções */
dist[x][y] = z;
dist[y][x] = z;

/* Lê os pontos e a distância entre eles */
scanf (“%d %d %d”, &x, &y, &z);
}

/* Algoritmo de Floyd-Warshall */
for (k = 1; k <= n; k++)
{
for (i = 1; i <= n; i++)
{
for (j = 1; j <= n; j++)
{
/* Se houver um ponto de repouso entre i e j com uma
menor distância, então o valor de pontos[i][j] é
substituído pelo de (dist[i][k] + dist[k][j]) */
if ((dist[i][k] + dist[k][j]) < dist[i][j])
{
dist[i][j] = dist[i][k] + dist[k][j];
dist[j][i] = dist[i][k] + dist[k][j];
}
}
}
}

/* Depois desse laço principal o valor de dist[1][n] é a menor
distância entre o ponto inicial e o final, a qual representa o valor
pedido pelo problema */

/* Saída de dados */
printf (“Teste %d\n%d\n\n”, num, dist[1][n]);

/* Incremento para o próximo caso de teste */
num++;

/* Entrada para o próximo caso de teste */
scanf (“%d”, &n);
}

return (0);
}

Fiquem bem atentos a parte de grafo, além do famoso algoritmo de Floyd-Warshall, o qual é suficientemente eficiente para esse problema.

Serão colocados comentários com dicas para os problemas “The Trip”, em Exercícios 1 (Parte I) e “Jolly Jumpers”, na Aula 2, pois foram resolvidos por mim no site do UVa Online Judge (finalmente).

Por fim, boa sorte a todos os que irão participar da competição amanhã (OBI), tomara que seja uma boa prova! Eu também participarei, esperando um bom resultado, se Deus quiser.

Posts interessantes:

• Programando melhor: Aula 4 – Ordenação
• OBI vem aí!
• Programando melhor: Aula 3 – Strings
• Programando melhor: Aula 1 – Começando

E você, como se preparou para a OBI? Ah, quando a prova terminar, postem suas opiniões aqui e vamos discutir as questões! Comentem!

Helton de Melo Duarte

“Entrega o teu caminho ao Senhor, confia nEle e Ele tudo fará.” Salmos 37.5

“O meu escudo está com Deus, que salva os retos de coração.” Salmos 7.10