Ontem, no período da tarde, foi aplicada a prova da primeira fase da OBI2006, modalidade Programação Nível 2. Já que nem todos os colégios submeteram as soluções de seus alunos, ainda não vou publicar os meus códigos nem o enunciado dos problemas, mas apenas escrever sobre o que achei da prova (assuntos separados em tópicos).

Tempo de Prova

O caderno foi composto por cinco questões, para serem resolvidas em cinco horas. Na minha opinião, foi tempo até demais para o nível dos problemas. Acabei a prova em pouco mais de três horas (depois de criar outros casos de teste, ver a complexidade dos algoritmos e tudo…).

Dificuldade da Prova

Embora no começo eu sempre leve um susto, no fim achei a prova fácil. Fiz as cinco questões, acho que acertei todas e a complexidade de nenhum dos meus algoritmos ficou muito pesada (mas também nunca se sabe…). Espero tirar uma nota superior a 400 (de 500) e acho que é possível até eu ter gabaritado.

Complexidade

Neste ano, o pessoal deixou a parte de tempo bem fácil. Ao invés de ser um conjunto de teste em cada entrada, foi apenas um teste por entrada. A conseqüência é que, além da questão de tempo ficar mais fácil, também não precisamos nos preocupar em zerar as variáveis a cada loop.

Problema mais difícil

O melhor problema da prova foi, na minha opinião, o Escada Perfeita. Infelizmente, não posso comentar muito a respeito dele até todos submeterem suas soluções, mas esse problema foi muito bom.

No meio de um problema de grafos (Museu), dois de coisas básicas tipo entrada/saída (Truco e Jogo de Cartas) e um problema para mostrar que sabemos mexer com matrizes (Colheita de Caju); o sistema de equações que dava pra montar neste problema (Escada Perfeita) baseado na fórmula de soma de PAs (aquela lenda do Gauss quando tinha cinco anos…) e depois um algoritmo guloso, fizeram com que eu ficasse mais de uma hora tentando encontrar a solução (que ficou com complexidade O(n)). Depois crio um post para comentar mais a respeito!

Enfim… Não posso entrar em muitos detalhes por enquanto e nem tenho certeza de como fui. A fase pós-prova/pré-nota é sempre complicada… Mas, se não cometi erros que [se existirem] devo perceber e comentar nos próximos artigos, rumo a segunda fase!

Pessoal que participou também, comentem aí dizendo como foram!

Anunciada a OBI2006! E temos novidades…

Copiado de: Site da OBI

Vamos participar, né? Estou ensinando meu amigo Ivo a programar e estou disposto a ajudar a quem quiser; para mim é um prazer ensinar coisas que eu gosto a quem está disposto a aprender.

E sobre a IOI…

Fiquei mais de um mês sem postar (ando sem inspiração). Desculpem-me por deixar a Série Algoritmos parada e não noticiar alguns fatos legais que aconteceram enquanto eu não postei (eu parei de escrever, mas comecei a ler mais). Vou voltar de leve agora…

Tenho estudado bastante matemática e física… pras olimpíadas, pro vestibular do ITA, pra desenvolver minha mente, etc. No fundo, é só porque eu gosto mesmo! :) Além disso, o ano letivo começou. Estou com um monte de coisa pra fazer (ainda não estou acostumado com o ritmo), mas vou voltar a postar ativamente.

De qualquer maneira, a pausa foi boa para uma reflexão pessoal e político-filosófica. Essas mudanças meus leitores provavelmente perceberão nos próximos artigos [ou talvez não].

Resolvi fazer uma pausa nos algoritmos de ordenação para mostrar como podemos usar os conhecimentos já adquiridos de maneira prática. Vamos neste artigo resolver o problema Mini-Poker, que caiu na prova da Programação Nível 2 (categoria para pessoas até 19 anos ou primeiro ano da faculdade) da Olimpíada Brasileira de Informática de 2005.

Esse post ficou gigante, mas é muito simples. Leia com atenção e acho que você não terá problemas… ;)

Objetivos

Com esta resolução de problema, espero treinar com vocês o conceito de:

• Interpretação do Probema
• Entrada e Saída
• Ordenação por Inserção
• Pseudocódigo

Acho que será legal para pôrmos em prática o que já estudamos sobre algoritmos.

O problema é bem simples, mas é só pra iniciar.

Enunciado

Mini-Poker é o nome do jogo de cartas que é uma simplificação de Poker, um dos mais famosos jogos de cartas do mundo. Mini-Poker é jogado com um baralho normal de 52 cartas, com quatro naipes (copas, paus, espadas e ouro), cada naipe compreendendo treze cartas (Ás, 2, 3, 4, 5, 6, 7, 8, 9, 10, Valete, Dama, Rei).

No início do jogo, cada jogador recebe cinco cartas. O conjunto de cinco cartas vale um certo número de pontos, de acordo com as regras descritas abaixo. Diferentemente do jogo de Poker normal, em Mini-poker o naipe das cartas é desconsiderado. Assim, para simplificar a descrição do jogo, vamos utilizar os números de 1 a 13 para identificar as cartas do baralho, na ordem dada acima. Uma outra diferença é que pode ocorrer empate entre mais de um vencedor; nesse caso os vencedores dividem o prêmio.

As regras para pontuação em Mini-Poker são as seguintes:

1. Se as cinco cartas estão em seqüência a partir da carta $x$ (ou seja, os valores das cartas são $x$, $x+1$, $x+2$, $x+3$ e $x+4$), a pontuação é $x+200$ pontos. Por exemplo, se as cartas recebidas são 10, 9, 8, 11 e 12, a pontuação é 208 pontos.
2. Se há quatro cartas iguais $x$ (uma quadra, ou seja, os valores das cartas são $x$, $x$, $x$, $x$ e $y$), a pontuação é $x+180$ pontos. Por exemplo, se as cartas recebidas são 1, 1, 1, 10 e 1, a pontuação é 181 pontos.
3. Se há três cartas iguais $x$ e outras duas cartas iguais $y$ (uma trinca e um par, ou seja, os valores das cartas são $x$, $x$, $x$, $y$ e $y$), a pontuação é $x+160$ pontos. Por exemplo, se as cartas recebidas são 10, 4, 4, 10 e 4, a pontuação é 164 pontos.
4. Se há três cartas iguais $x$ e duas outras cartas diferentes $y$ e $z$ (uma trinca, ou seja, os valores das cartas são $x$, $x$, $x$, $y$ e $z$), a pontuação é $x+140$ pontos. Por exemplo, se as cartas recebidas são 2, 3, 2, 2 e 13, a pontuação é 142 pontos.
5. Se há duas cartas iguais $x$, duas outras cartas iguais $y$ ($x \neq{} y$) e uma outra carta distinta $z$ (dois pares, ou seja, os valores das cartas são $x$, $x$, $y$, $y$ e $z$), a pontuação é $3 \times{} x + 2 \times{} y + 20$ pontos, em que $x > y$. Por exemplo, se as cartas recebidas são 12, 7, 12, 8 e 7, a pontuação é 70 pontos.
6. Se há apenas duas cartas iguais $x$ e as outras são distintas (um par, ou seja, os valores das cartas são $x$, $x$, $y$, $z$ e $t$), a pontuação é $x$ pontos. Por exemplo, se as cartas recebidas são 12, 13, 5, 8 e 13, a pontuação é 13 pontos.
7. Se todas as cartas são distintas, não há pontuação.

Tarefa

Escreva um programa que, fornecidas as cartas dadas a um jogador, calcule a pontuação do jogador naquela jogada.

Entrada

A entrada é composta por vários casos de teste, cada um correspondendo a uma jogada. A primeira linha da entrada contém um número inteiro $N$ que indica o número de casos de teste ($1 \leq{} N \leq{} 100$). Cada uma das $N$ linhas seguintes contém cinco números inteiros $C\_{1}$, $C\_{2}$, $C\_{3}$, $C\_{4}$ e $C\_{5}$, representando as cinco cartas recebidas por um jogador ($1 \leq{} C\_{1}, C\_{2}, C\_{3}, C\_{4}, C\_{5} \leq{} 13$).

A entrada deve ser lida do dispositivo de entrada padrão (normalmente o teclado).

Saída

Para cada caso de teste da entrada, seu programa deve produzir três linhas na saída. A primeira linha deve conter um identificador do caso de teste, no formato “Teste n”, onde n é numerado seqüencialmente a partir de 1. A segunda linha deve conter a pontuação do jogador considerando as cinco cartas recebidas. A terceira linha deve ser deixada em branco. A grafia mostrada no Exemplo de Saída, abaixo, deve ser seguida rigorosamente.

A saída deve ser escrita no dispositivo de saída padrã (normalmente a tela).

Restrições

$1 \leq{} N \leq{} 100$ $1 \leq{} C\_{1}, C\_{2}, C\_{3}, C\_{4}, C\_{5} \leq{} 13$

Exemplo de Entrada

2
12 3 10 3 12
1 2 3 5 4

Saída para o Exemplo de Entrada

Teste 1
62

Teste 2
201

Comentários sobre os problemas de olimpíadas

Todos os problemas passados em competições de programação tem um enunciado parecido com o desse. São especificados todos os limites (restrições), é dito exatamente como será a entrada e como deve ser a saída e geralmente tem uma historinha no começo… :D

Bom… Todos esses dados são fundamentais. Alguns limites nem vamos usar, não tem importância para a nossa solução, mas pode ter importância para outra pessoa que queira implementar um algoritmo diferente. A sintaxe da entrada e da saída são extremamente importantes. Na prova da Seletiva IOI do ano passado, eu quase perdi 60 pontos (6 casos de teste) na solução de um problema simples porque meu programa desprezava um espaço no início de uma frase quando imprimia uma saída. E mesmo a historinha do começo é fundamental. Ela sempre dá boas dicas e algumas vezes até ilustra o problema (às vezes a gente nem lê o enunciado e já sabe que é um problema de grafos!)

Mas vamos a solução deste problema…

Por onde começar?

Com o tempo você pode decidir fazer um caminho diferente, mas eu sugiro começar sempre pelo recebimento da entrada. Aliás, acho que isto é atípico, porque a maioria das pessoas prefere ler bastante o problema e desenvolver todo o algoritmo a mão antes de botar a mão na massa. Eu acho que depois que a gente recebe a entrada, fica bem mais fácil fazer o resto e a gente pode ir pensando enquanto a gente recebe a entrada! Então, depois que lemos o problema e já entendemos tudo o que ele quer, vamos fazer a entrada!

O problema fala que começa nos dando um número N que será o número de casos de teste que teremos que receber depois. Sem dificuldade podemos escrever o _pseudo_código a seguir:

recebe N
para nteste $\leftarrow{}$ 1 até N, faça
fim-para

Já chamo a variável que loopa como nteste, porque já li a saída do problema e sei que vou precisar imprimir o número de caad caso de teste… ;)

Aí o enunciado diz que Cada uma das $N$ linhas seguintes contém cinco números inteiros $C\_{1}$, $C\_{2}$, $C\_{3}$, $C\_{4}$ e $C\_{5}$, representando as cinco cartas recebidas por um jogador ($1 \leq{} C\_{1}, C\_{2}, C\_{3}, C\_{4}, C\_{5} \leq{} 13$). Então, vamos receber os cinco números em cada iteração e colocá-los num vetor, é claro!

recebe N
para nteste $\leftarrow{}$ 1 até N, faça
 recebe $C_{1}, C_{2}, C_{3}, C_{4}, C_{5}$
fim-para

E a entrada está pronta.

Desenvolvimento

O programa se baseia em encontrarmos valores iguais nos elementos do vetor. O que podemos fazer para facilitar essa tarefa?

Isso mesmo: A ordenação! :D Se os elementos estiverem ordenados, ficará bem mais fácil para procurarmos quatro números iguais, porque eles não poderão ser qualquer uma das possibilidades, mas somente $C_{1}, C_{2}, C_{3}, C_{4}$ ou $C_{2}, C_{3}, C_{4}, C_{5}$.

Aí que algoritmos devemos implementar para ordenar? Isso é uma conclusão que vamos chegar no final de nossa série, mas para este algoritmo não tem solução melhor que a Ordenação por Inserção. É um caso pequeno (n=5) e a Ordenação por Inserção é mais rápida que a por Seleção, porque o seu melhor caso é uma função linear. Então, vamos implementar o Insertion Sort no nosso algoritmo:

recebe N
para nteste $\leftarrow{}$ 1 até N, faça
 recebe $C_{1}, C_{2}, C_{3}, C_{4}, C_{5}$
 // início da ordenação por inserção
 para j $\leftarrow{}$ 2 até 5
  elemento $\leftarrow{}$ $C_{j}$
  i $\leftarrow{}$ j-1
  enquanto i > 0 e $C_{i}$ > elemento, faça
   $C_{i+1}$ $\leftarrow{}$ $C_{i}$
   $i$ $\leftarrow{}$ $C_{i-1}$
  fim-enquanto
  $C_{i+1}$ $\leftarrow{}$ elemento
 fim-para
 // fim da ordenação por inserção
fim-para

O bom desses algoritmos de ordenação é que sua lógica é muito simples e por isso é fácil decorá-los… Ao menos o Insertion Sort e o Selection Sort são algoritmos básicos que todo programador deve conhecer bem. Bom… Acredito que vocês não tenham tido dificuldade pra entender até aqui. A cor vermelha no pseudocódigo eu vou usar daqui pra frente para um comentário, que aliás, é uma excelente prática de boa programação.

O resto do problema precisa calcular quantos pontos o cara fez, baseado em suas cartas, agora já ordenadas. Para isto vamos criar uma função para testar vários se e retornar o resultado.

Eu poderia tirar os se aninhados, mas assim fica mais fácil a compreensão.

Como vamos ver com os pseudocódigos a seguir, é fácil testar cada uma das regras com o vetor ordenado:

Primeira Regra – Seqüência

Se as cinco cartas estão em seqüência a partir da carta $x$(ou seja, os valores das cartas são $x$, $x+1$, $x+2$, $x+3$ e $x+4$), a pontuação é $x+200$ pontos. Por exemplo, se as cartas recebidas são 10, 9, 8, 11 e 12, a pontuação é 208 pontos.

se $C_{1} = C_{2}-1$ e $C_{2} = C_{3}-1$ e $C_{3}=C_{4}-1$ e $C_{4}=C_{5}-1$, então
 retorna $C_{1}+200$
fim-se

Segunda Regra – Quadra

Se há quatro cartas iguais $x$ (uma quadra, ou seja, os valores das cartas são $x$, $x$, $x$, $x$ e $y$), a pontuação é $x+180$ pontos. Por exemplo, se as cartas recebidas são 1, 1, 1, 10 e 1, a pontuação é 181 pontos.

se $C_{1} = C_{2} = C_{3} = C_{4}$ ou $C_{2} = C_{3} = C_{4} = C_{5}$, então
 retorna $C_{2}+180$
fim-se

Aqui retornamos $C\_{2}$ porque ele será sempre parte da quadra (ela começando em $C\_{1}$ ou $C\_{2}$).

Terceira e Quarta Regra – Trinca

Se há três cartas iguais $x$ e outras duas cartas iguais $y$ (uma trinca e um par, ou seja, os valores das cartas são $x$, $x$, $x$, $y$ e $y$), a pontuação é $x+160$ pontos. Por exemplo, se as cartas recebidas são 10, 4, 4, 10 e 4, a pontuação é 164 pontos.

se $C_{1} = C_{2} = C_{3}$ ou $C_{2} = C_{3} = C_{4}$ ou $C_{3} = C_{4} = C_{5}$, então
 se ( $C_{1} \neq{} C_{3}$ e $C_{1} = C_{2}$ ) ou ( $C_{3} \neq{} C_{5}$ e $C_{4} = C_{5}$ ), então
  retorna $C_{3}+160$

Se há três cartas iguais $x$ e duas outras cartas diferentes $y$ e $z$ (uma trinca, ou seja, os valores das cartas são $x$, $x$, $x$, $y$ e $z$), a pontuação é $x+140$ pontos. Por exemplo, se as cartas recebidas são 2, 3, 2, 2 e 13, a pontuação é 142 pontos.

 senão
  retorna $C_{3} + 140$
 fim-se
fim-se

Note que aqui retornamos $C\_{3}$ porque ele será sempre parte da trinca (o mesmo motivo que retornarmos $C\_{2}$ para a quadra).

Quinta Regra – Duas Duplas

Se há duas cartas iguais $x$, duas outras cartas iguais $y$ ($x \neq{} y$) e uma outra carta distinta $z$ (dois pares, ou seja, os valores das cartas são $x$, $x$, $y$, $y$ e $z$), a pontuação é $3 \times{} x + 2 \times{} y + 20$ pontos, em que $x > y$. Por exemplo, se as cartas recebidas são 12, 7, 12, 8 e 7, a pontuação é 70 pontos.

se $C_{1} = C_{2}$ ou $C_{2} = C_{3}$, então
 se $C_{3} = C_{4}$ ou $C_{4} = C_{5}$, então
  retorna $3 \times{} C_{4} + 2 \times{} C_{2} + 20$
 fim-se
fim-se

$C\_{2}$ será sempre elemento da menor dupla e $C\_{4}$ será sempre elemento da maior dupla. Por isso usamos eles como $y$ e $x$, respectivamente.

Sexta Regra – Dupla

Se há apenas duas cartas iguais $x$ e as outras são distintas (um par, ou seja, os valores das cartas são $x$, $x$, $y$, $z$ e $t$), a pontuação é $x$ pontos. Por exemplo, se as cartas recebidas são 12, 13, 5, 8 e 13, a pontuação é 13 pontos.

se $C_{1} = C_{2}$ ou $C_{2} = C_{3}$, então
 retorna $C_{2}$
senão se $C_{3} = C_{4}$ ou $C_{4} = C_{5}$, então
 retorna $C_{4}$
fim-se

Separei em dois SEs porque senão não saberíamos que valor retornar.

Sétima Regra

Se todas as cartas são distintas, não há pontuação.

retorna 0

Função Inteira

Juntando todos os SEs, temos:

função pontua (C)
 // primeira regra
 se $C_{1} = C_{2}-1$ e $C_{2} = C_{3}-1$ e $C_{3}=C_{4}-1$ e $C_{4}=C_{5}-1$, então
  retorna $C_{1}+200$
 fim-se
 
 // segunda regra
 se $C_{1} = C_{2} = C_{3} = C_{4}$ ou $C_{2} = C_{3} = C_{4} = C_{5}$, então
  retorna $C_{2}+180$
 fim-se
 
 //terceira e quarta regra
 se $C_{1} = C_{2} = C_{3}$ ou $C_{2} = C_{3} = C_{4}$ ou $C_{3} = C_{4} = C_{5}$, então
  se ( $C_{1} \neq{} C_{3}$ e $C_{1} = C_{2}$ ) ou ( $C_{3} \neq{} C_{5}$ e $C_{4} = C_{5}$ ), então
   retorna $C_{3}+160$
  senão
   retorna $C_{3} + 140$
  fim-se
 fim-se
 
 // quinta regra
 se $C_{1} = C_{2}$ ou $C_{2} = C_{3}$, então
  se $C_{3} = C_{4}$ ou $C_{4} = C_{5}$, então
   retorna $3 \times{} C_{4} + 2 \times{} C_{2} + 20$
  fim-se
 fim-se
 
 // sexta regra
 se $C_{1} = C_{2}$ ou $C_{2} = C_{3}$, então
  retorna $C_{2}$
 senão se $C_{3} = C_{4}$ ou $C_{4} = C_{5}$,
 então
  retorna $C_{4}$
 fim-se
 
 // sétima regra
 retorna 0
fim-função

Já que a função retorna assim que encontra um resultado, não há risco de ocorrer nada errado (por exemplo, uma quadra é sempre uma trinca, que é sempre uma dupla). Agora basta colocarmos esta função no nosso código e adaptar para a saída ser igual a que o problema pede.

Saída

Para chegar a saída, basta fazermos o programa imprimir Teste nteste e depois o retorno da função pontua. Com isto, temos:

recebe N
para nteste $\leftarrow{}$ 1 até N, faça
 recebe $C_{1}, C_{2}, C_{3}, C_{4}, C_{5}$
 // início da ordenação por inserção
 para j $\leftarrow{}$ 2 até 5
  elemento $\leftarrow{}$ $C_{j}$
  i $\leftarrow{}$ j-1
  enquanto i > 0 e $C_{i}$ > elemento, faça
   $C_{i+1}$ $\leftarrow{}$ $C_{i}$
   $i$ $\leftarrow{}$ $C_{i-1}$
  fim-enquanto
  $C_{i+1}$ $\leftarrow{}$ elemento
 fim-para
 // fim da ordenação por inserção

 imprime “Teste ”
 imprime linha testen
 imprime linha pontua(C)
 imprime linha
fim-para

Fiz essa saída assim pra se parecer com Pascal, mas para cada linguagem ela pode ser bem diferente… Vejamos dois exemplos…

C

printf("Teste %d\n%d\n\n", nteste, pontua(C));

PHP

echo "Teste ".$nteste."\n".pontua($C)."\n\n";

Comentários sobre o problema

Este problema é muito chato. É trivial, mas perdemos um tempo enorme escrevendo ses. Ninguém gosta de um problema como esse, mas quando cai numa olimpíada somos obrigados a resolver… hehehe… Mas, para a felicidade geral de todos, saibam que a maioria dos problemas de olimpíadas não são assim. Exigem mais lógica e menos código. Com o tempo, vamos pegando problemas mais difíceis. Espero só ter cumprido meu objetivo dando uma utilidade pra ordenação, entrada e saída e que vocês tenham entendido tudo.

Sugiro que quem esteja aprendendo algoritmos com meus artigos e já saiba programar um pouquinho, resolva alguns problemas simples do site da OBI, que separei especialmente pra vocês!

• Bits Trocados
• Calculando
• Cofrinhos da Vó Vitória
• Quermesse

E, gostaria de fixar, mais importante é a interpretação e o seu pensamento… Programar é fácil!

No primeiro artigo desta série, o Hélio comentou: ‘Algoritmos’ é um tema pouco valorizado por muitos programadores iniciantes, que querem logo botar a mão na massa.

É a mais pura verdade. Quando eu tive a minha primeira noção do que são algoritmos (no dia 12 de julho de 2004, no Curso de Programação da Olimpíada Brasileira de Informática na UNICAMP), confesso que fiquei decepcionado. Qual a utilidade de algo tão formal pra algo que já sabemos fazer? Eu já programava em C e achei um saco o professor escrevendo no quadro aqueles pseudocódigos de problemas super simples, perdendo tempo com isso ao invés de programar. Porém, hoje percebo que algoritmos são muito mais legais (e importantes) do que eu pensava. Claro que para somar dois inteiros não há necessidade de escrever um pseudocódigo, mas algoritmos são representações essenciais para problemas mais complexos e grandes aplicações.

Acredito que você que já leu os dois primeiros artigos já deve saber, mas não custa lembrar: algoritmo é a relação entre entrada e saída do programa, é o rascunho do programa, o projeto. E um projeto antes de colocar a mão na massa é indispensável. Enquanto a implementação é a função dos pedreiros, o algoritmo é a função dos engenheiros. Se os engenheiros não existissem, acho que os pedreiros não iam conseguir fazer as casas e os prédios que eles constroem hoje em dia!

Não querendo desmerecer alunos de sistemas de informação, mas a maioria deles não passa de pedreiros.

O algoritmo sempre existe, mesmo que apenas no seu pensamento. A primeira coisa que você pensa quando quer fazer uma aplicação (a não ser que você seja louco) é: o que é a aplicação? O que ela vai fazer? E se você sair implementando uma coisa complexa, você vai se decepcionar depois demorando mais do que o tempo de fazer a implementação só para limpar o código! Por isso, representar algoritmos complexos é essencial.

E mais… Mesmo se você tivesse tempo infinito, memória infinita, etc. e tal (não tivesse necessidade de limpar o código), você vai precisar de um algoritmo pra provar que o seu programa funciona, para se organizar e para estudar a sua lógica. Se você não planejar um algoritmo para o caso acima, qualquer funcionalidade que você queira adicionar no meio, por falta de projeto e organização, vai demorar bem mais tempo. Por isso, algoritmo não é uma perda de tempo antes da programação, mas a programação é que se torna uma perda de tempo quando não teve um algoritmo (ou, um projeto). O livro Algoritmos: Teoria e Prática reforça essa interessante idéia na página 7:

Suponha que os computadores fossem infinitamente rápidos e que a memória do computador fosse livre. Você teria alguma razão para estudar algoritmos? A resposta é sim, se não por outra razão, pelo menos porque você ainda gostaria de demonstrar que o método da sua solução termina, e o faz com a resposta certa.

Outra utilidade do algoritmo é compartilhar idéias de problemas complexos. Todo programador entende um pseudocódigo e por isso convém muitas vezes apresentar sua idéia de um programa em forma de um algoritmo, num pseudocódigo, ao invés de passar um programa implementado em C para uma dúzia de programadores de VBScript (e sem dúvidas é muito melhor do que ter que aprender uma linguagem da Microsoft!!!).

Existe uma série de algoritmos comuns que todo programador deve conhecer (projetos prontos para muitas coisas complicadas que precisamos implementar no dia-a-dia) e isso é o que vamos começar a estudar no próximo artigo. :)

Impressionante a quantidade de besteiras que todo programador faz… Às vezes, uma semana depois de fazer um programa ou um site, eu já sinto raiva do script que acabei de fazer e me sinto obrigado a refazê-lo. Brincando um pouco nas férias, estou refazendo vários problemas da OBI e cada vez mais percebo a quantidade de lixo que achamos nos nossos scripts. E o pior é perceber o tempo que eu levava pra fazer aqueles problemas que podiam ser resolvidos de maneira tão simples (e eu pensava que tinha uma solução muito boa)… Estou resolvendo a lista de tarefas da modalidade Programação Nível 2, mas apenas os problemas de grafos (todos eles eu já tinha resolvido, mas estou agora programando-os melhor). Confiram as besteiras que eu fiz nos primeiros deles:

Aeroporto

[enunciado]

Um problema de grafos? Não! Mas parece muito. Na verdade, se ele pedisse qualquer coisa mais do que o grau de cada vértice eu precisaria de representar usando grafos, mas a única coisa que ele quer é que eu conte a quantidade de vezes que cada número aparece na entrada.

A primeira solução deste problema, que agora já não está mais entre nós, foi feita no curso de programação básica da OBI 2004, em Campinas, quando começava a aprender grafos. Pra vocês terem uma idéia do drama, eu fiz uma busca em profundidade pra contar o número de arestas que cada vértice tem (pra medir o grau de cada vértice).

Confiram a básica solução que fiz ontem: (e que daqui a algum tempo posso vir a achar ridícula também… hehehe)

#include <stdio.h>
#define AMAX 101

int main() {
	int a, v, x, y, t[AMAX]; // t = tráfego, grau dos vértices
	int i, maior, teste=1;

	while (scanf("%d %d", &a, &v)&&a&&v) {
		maior=0;
		for (i=1; i<=a; i++) {
			t[i]=0;
		}
		for (i=0; i<v; i++) {
			scanf("%d %d", &x, &y);
			t[x]++;
			t[y]++;
			if (t[x]>maior) {
				maior=t[x];
			}
			if (t[y]>maior) {
				maior=t[y];
			}
		}
		printf("Teste %dn", teste++);
		for (i=1; i<=a; i++) {
			if (t[i]==maior) {
				printf("%d ", i);
			}
		}
		printf("bnn");
	}

	return 0;
}

Batuíra

[enunciado]

O objetivo é achar o caminho mínimo de peso de 1 a N. Uma simples busca em profundidade resolve o problema. Agora vejam a busca em profundidade que eu faria em 2004, que ainda não tirei da minha galeria de códigos: batuira.c e comparem com a que eu fiz ontem (e que ainda poderia ser melhorada):

#include <stdio.h>
#include <values.h>
#define NMAX 101

int n, marc[NMAX], g[NMAX][NMAX];
int resultado;

void buscaemprofundidade(int v, int soma) {
	int w;

	if (v==n) {
		if (soma<resultado) {
			resultado=soma;
		}
	} else {
		marc[v]=1;
		for (w=1; w<=n; w++) {
			if (g[v][w]&&!marc[w]) {
				buscaemprofundidade(w, soma+g[v][w]);
			}
		}
	}
}

int main() {
	int x, y, xy;
	int i, j, teste=1;

	while (scanf("%d", &n)&&n) {
		resultado=MAXINT;
		for (i=1; i<=n; i++) {
			marc[i]=0;
			for (j=1; j<=n; j++) {
				g[i][j]=0;
			}
		}
		while (scanf("%d %d %d", &x, &y, &xy)&&x&&y&&xy) {
			g[x][y]=xy;
			g[y][x]=xy;
		}
		buscaemprofundidade(1, 0);
		printf("Teste %dn%dnn", teste++, resultado);
	}

	return 0;
}

Dengue

[enunciado]

Esse foi com certeza meu maior susto. Foi por causa desse problema que eu resolvi escrever este artigo… Dá até vergonha de mostrar a busca em profundidade que usei para resolver o problema anteriormente. O objetivo do problema é descobrir partindo de que vértice do grafo o vértice que se encontra mais longe tem custo menor. Ou seja, é só fazer uma busca em largura com todos os vértices. Mas antigamente eu não simpatizava muito com a busca em largura, então fiz aquela besteira. E imaginem quanto tempo eu não levei pra fazer aquela joça… Bom… Pelo menos deve ter servido pra eu quebrar a cabeça naquela época! Vejam o código novo (sujeito a mudanças, é claro!):

#include <stdio.h>
#include <values.h>
#define NMAX 101

int main() {
	int w, i, j, x, y, teste=1, g[NMAX][NMAX], n, d[NMAX], fim, ini, fila[NMAX], v, a, md[NMAX], c;

	while (scanf("%d", &n)&&n) {
		for (i=1; i<=n; i++) {
			for (j=1; j<=n; j++) {
				g[i][j]=0;
			}
		}
		for (i=1; i<n; i++) {
			scanf("%d %d", &x, &y);
			g[x][y]=1;
			g[y][x]=1;
		}
		c=0;
		md[0]=MAXINT;
		for (v=1; v<=n; v++) {
			for (i=1; i<=n; i++) {
				d[i]=n;
			}
			md[v]=0;
			d[v]=0;
			ini=0;
			fim=0;
			fila[fim++]=v;
			while (ini!=fim) {
				a=fila[ini++];
				if (d[a]>md[v]) {
					md[v]=d[a];
				}
				for (w=1; w<=n; w++) {
					if (g[a][w]&&d[w]==n) {
						d[w]=d[a]+1;
						fila[fim++]=w;
					}
				}
			}
			if (md[v]<md[c]) {
				c=v;
			}
		}
		printf("Teste %dn%dnn", teste++, c);
	}

	return 0;
}

Bom… Simplificando… Se você não é programador, não seja; você vai ficar louco! :lol: Este problema que citei aqui não acontece só com esses problemas de olimpíadas mas também com vários scripts, principalmente os que vamos alterando com o tempo e adicionando novas features. Já recomecei do zero muitos sites para deixá-los decentes e muitos programas também (essa versão do aeroporto.c já é a terceira!) e não só esses de olimpíadas (o meu programa de ouvir música, em Bash, eu já fiz umas 10 vezes).

Quando eu acabar de re-resolver todos os problemas da seção de códigos lógicos eu vou publicar todos juntos. Por enquanto, vou deixar tudo do jeito que tá pra vocês apreciarem meus scripts mal-feitos. ;)

Quem costuma visitar meu blog perceberá que apareceu um ícone lá no canto inferior direito, escrito Bom Demais para o IE. A imagem, posicionada lá embaixo usando um position:fixed; (que o IE não suporta) é de uma campanha muito legal que você pode conhecer clicando no link. Participem e tenham um site “bom demais para o Internet Explorer”! :)