Análise dos Dados

Após a execução da implementação do algoritmo e a coleta dos resultados, dá-se prosseguimento à análise para extração de informações.

Muitas vezes, os dados produzidos pelos testes fornecem poucas informações, ou informações sobre as quais não é possível fazer afirmações bem embasadas, fazendo com que o preenchimento das lacunas geradas entre a análise e os resultados sejam deixadas para preenchimento pela imaginação do leitor. Para evitar tal situação, recomenda-se:

• Executar mais testes: talvez a forma mais simples de produzir conclusões mais bem

embasadas é ter um número de resultados relativamente grande.

do fator é pequena quando comparado à variação, aumentar a faixa dos valores testados para ele pode melhorar a resposta. Infelizmente, por restrições de tempo e de hardware, não podemos conduzir experimentos com os níveis de fator desejados.

• Não resumir os dados prematuramente: os programas de teste devem sempre gerar

valores “crus”, mostrando os resultados de cada teste, para que a distribuição desses dados possa ser analisada. Posteriormente, podemos definir estatísticas como variância ou média amostrais, por exemplo.

• Reduzir (ou aumentar) os dados amostrais para o tamanho certo: evitar produzir

muitos (ou muito poucos) dados nos testes. Uma quantidade pequena de dados pode ocultar propriedades importantes enquanto muitos dados podem tornar difícil enxergar o que realmente importa (reportar o valor de uma variável em cada iteração de um laço de repetição, ao invés de reportar apenas o valor na saída do laço, por exemplo).

• Não usar indicadores de desempenho que podem resumir ou ocultar propriedades:

em nosso caso, poderíamos definir nossos algoritmos para reportar apenas os valores médios dos testes executados, mas isso poderia ocultar discrepâncias ou outras informações importantes. Assim, cada execução tem seus dados individuais reportados e o cálculo médio é realizado posteriormente.

• Usar indicadores de desempenho específicos: indicadores de desempenho específicos

concentram-se em uma parte do algoritmo, fazendo assim com que seja mais fácil analisar ou identificar certas propriedades ligadas ao identificador. Variações de resultado identificadas através de indicadores de desempenho amplos podem ser resultado de um agregado de propriedades, cujo relacionamento nem sempre é claro.

2.2.5.1 Experimento Dobrado

O conceito de Experimento Dobrado (Doubling Experiment) foi inicialmente

pro-posto em (SEDGEWICK; SCHIDLOWSKY, 1998). Esse experimento pode ser empregado

no início do processo experimental, para colhermos informações sobre o desempenho do algoritmo. Basicamente o que o autor propõe é que podemos estimar a taxa de crescimento da função de custo de muitos algoritmos comparando um indicador de desempenho a medida que o tamanho da entrada dobra. Além disso, podemos verificar se as presunções

de desempenho feitas na teoria são traduzidas para a prática. Podemos interpretar os resultados da seguinte forma:

• Se os valores resultantes do indicador de desempenho não mudam com o aumento

do nível de n, a função de custo é constante;

• Se os valores do indicador são incrementados por uma constante, a função de custo

é θ(log n)

• Se ao dividirmos cada resultado do indicador de desempenho por n e os valores

aumentarem de forma constante, a função de custo é θ(n log n)

• Se o custo dobra a medida que n dobra, a função de custo é linear.

• Se o custo quadruplica a medida que n dobra, a função de custo é θ(n2)

Utilizamos uma versão simples desta ideia durante a análise dos resultados dos grafos de

Moon-Moser, na Seção 4.3.

2.2.5.2 Técnicas de Redução de Fatores

Abordamos no início deste capítulo Design Fatorial Completo, que fornece um

meio de definirmos quais os níveis e pontos dedesignque usaremos nos testes. Um problema com essa abordagem é que a quantidade de testes demandados cresce de forma exponencial em função do número de fatores. O exemplo citado mostra que caso sejam identificados

três fatores, teremos oito pontos de design. Se adicionarmos mais 2 fatores, passamos

a ter 25 = 32 fatores. Digamos então que escolhemos 20 pontos de design para serem

testados e que vamos executar o programa de testes 3 vezes para cada ponto de design.

Temos um total de 1.920 execuções do programa de testes a serem feitas. Caso o programa de teste seja de execução rápida, isso não representa um grande problema, mas caso tenhamos um programa de teste que demanda uma grande quantidade de tempo para executar, devemos buscar alternativas para não gastarmos uma quantidade exagerada (da qual muitas vezes não se dispõe) de tempo. Apresentamos algumas opções para reduzir o tamanho do conjunto de fatores:

• Unir fatores similares: caso dois fatores possuam um efeito similar sobre o desempenho, podemos tratá-los como um único fator, realizando testes apenas em casos onde o

• Usar dados de rastreamento para inferir os efeitos de fatores omitidos: podemos modificar o código para que ele reporte estados de variáveis em determinados pontos de forma que possamos tirar conclusões sobre o efeito do “ex-fator"sobre o funcionamento do algoritmo;

• Converter fatores para parâmetros de ruído: ao invés de definir explicitamente os

níveis para um fator, podemos deixar que ele varie de acordo com uma distribuição de probabilidade simples e reportar seu valor em testes aleatórios. Temos assim um conjunto de níveis e medidas de desempenho que podem ser usadas posteriormente.

• Limitar o escopo do experimento: através da fixação de fatores e redução do número

de níveis. Se os resultados não variam muito de nível para nível, podemos aplicar um espaçamento maior entre os valores de nível, por exemplo. Utilizamos essa técnica

3 ANÁLISE EXPERIMENTAL

Neste capítulo, aplicamos os conceitos apresentados no Capítulo 2para comparar

diversos algoritmos para o problema da clique máxima. Apresentamos três experimentos diferentes, cada um envolvendo uma família de instâncias diferente, descritas na Seção 3.2.

Inicialmente apresentamos na Seção3.1o ambiente dehardwareesoftwareutilizado

nos experimentos. Apresentamos nas Seções 3.2 e 3.3 as classes de grafos e algoritmos

usados, respectivamente. Finalmente, apresentamos na Seção 3.4 os modelos de design

também divididos por tipos de instância. Elementos comuns são descritos apenas uma única vez, como o ambiente de testes e os algoritmos analisados.