Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testes #16

Open
andrechalom opened this issue Jul 9, 2014 · 7 comments
Open

Testes #16

andrechalom opened this issue Jul 9, 2014 · 7 comments
Assignees
Labels

Comments

@andrechalom
Copy link
Member

Precisamos recuperar, documentar e manter os testes básicos do TWoLife: crescimento exponencial simples, capacidade de suporte, comparação com o Skellam, etc.

@piklprado
Copy link
Contributor

Com o novo pull reuqest (#26) do D2 vi como este ToDo é importante! Antes de verificar se a modificação proposta pelo request funciona temos que usar uma bateria de testes que verifica se o que já fucniona continua.. Proposta de pacote básico:

  • Crescimento exponencial
    • Tamanho esperado da populacao após um certo tempo, independência do raio, independência dos parâmetros de movimentação
  • Crescimento logístico:
    -Tamanho esperado da populacao após um certo tempo, independência do raio e da movimentação para capacidade de suporte global (campo médio), estabilização do tamanho populacional médio mesmo com capacidade de suporte local
  • Reação-difusão:
    • velocidade da frente de onda decrescente com difusão pura e constante com reação-difusão.
    • Existência de um tamanho mínimo de mundo para que a população não se extinga, sob crescimento exponencial (limiar de Skellam)
    • Independência entre reação e difusão

@awade2
Copy link
Contributor

awade2 commented Sep 26, 2014

Ok vou fazer isso no R, ok? vou cirar um código de testes prontos para esses casos.

@awade2 awade2 self-assigned this Sep 26, 2014
@andrechalom
Copy link
Member Author

Acho que o lugar certo pra criar esses testes é no R mesmo. Ter um arquivo
que roda o TWoLife com parâmetros "padrãozão" e verifica se o resultado
bate.

Sugiro usar sempre "set.seed" antes de cada teste pra garantir
reprodutibilidade, e testar igualdade com "all.equal", que permite que as
comparações sejam feitas com uma certa tolerância (se não, fica difícil
comparar as coisas, pq 1 / 3 * 3 é diferente de 1, por conta do erro de
float).

On Thu, Sep 25, 2014 at 10:03 PM, Marcelo Awade [email protected]
wrote:

Ok vou fazer isso no R, ok? vou cirar um código de testes prontos para
esses casos.


Reply to this email directly or view it on GitHub
#16 (comment).

@piklprado
Copy link
Contributor

Totalmente de acoRdo! Mais alguns testes simples:

  • Sem movimentação e denso-dependência global a população total deve crescer até uma capacidade de suporte.
    • O valor desta capacidade deve ser fácil de calcular a partir de raio, tamanho do munod, taxas basais e inclinações
  • Dividir a paisagem ao meio, com denso-depenência nas manchas de habitats e taxa líquida sempre negativa na matriz. Sem movimento isto deve resultar em matriz vazia depois de algum tempo. Novamente deve ser possível calcular a densidade esperada no habitat.

@awade2
Copy link
Contributor

awade2 commented Oct 9, 2014

Pessoal, finalmente acabei de fazer algumas funções teste para o TWoLife, que está no novo arquivo Analytical-pckg.R. No arquivo Tests.R estão os testes que rodei para gerar os gráficos que apresento abaixo. Nesse processo, retirei (ainda está como comentário) os comandos de teste do arquivo TWoLife.R, que agora contém apenas as funções básicas para chamar o TWoLife em R. Por enquanto, só testei para paisagem homogênea, para as quais se aplicam as predições do modelo de Skellam. Antes de testar paisagem heterogênea, gostaria de discutir como calcular densidade nessa condição (abrirei um issue para isso).

  • Crescimento exponencial puro (50 réplicas)

nt_simple-birth-death

  • Comentário : Parece estar tudo ok com essa parte. Para qualquer configuração inicial dos indivíduos (centro, aleatória uniforme, aleatória normal). Já havia testado varias outras vezes sem problemas.
  • Crescimento Logístico puro, densidade global (20 réplicas)
    • Congifuração inicial = Centro (0,0)

nt_general-birth-death-gd

  • Configuração Inicial = Aleatória Uniforme

nt_general-birth-death-gd2

  • Comentário : Parece estar tudo ok com essa parte também.
  • Crescimento Logístico puro, densidade local (20 réplicas)

nt_general-birth-death-ld

  • Comentário : Com crescimento logístico e denso-depêndencia local as primeiras estranhezas começam a aparecer. Por exemplo, extinção de populações com crescimento positivo. Isso tem a ver com a configuração inicial. Se todos começam no centro, a chance de extinção aumenta muito pois a capacidade suporte é alterada para o número de indivíduos que cabe na circunferência de percepção. Isso aumento os efeitos estocásticos.
  • Caminhada Aleatória pura (50 réplicas)
    • Velocidade

vel_simple-random-walk

  • Desvio padrão da distribuição dos individuos ao longo do tempo

dist_simple-random-walk

  • Comentário : Parece estar tudo ok com essa parte também.
  • Reação-Difusão Skellam : crescimento exponencial (50 réplicas)
    • Crescimento Populacional

nt_skellam

  • Velocidade

vel_skellam

  • Detalhe

vel_skellam-b

  • Tamanho mínimo da paisagem

skellam_comb-02

  • Comentário : Parece estar tudo ok com essa parte. O desvio observado para configurações iniciais aleatórias pode ser esperado, uma vez que a predição do modelo de Skellam é feita para configuração inicial centralizada. No entanto, ao observarmos o ultimo conjunto de gráficos (tamanho mínimo da paisagem) observamos que, em todas as paisagens testadas, o tamanho populacional não atingiu o valor esperado (mesmo em paisagens com área suficiente para evitar extinção; P extinção = 0).
    Acho que o motivo de ambos os desvios é o efeito de borda (condição de contorno), mas não tenho certeza. Parece que mesmo sustentando populações estáveis, o tamanho final da população dependerá da área da paisagem a longo prazo (i.e. quando tempo suficiente tenha sido dado para que os indivíduos cheguem às bordas da paisagem).
  • Reação-Difusão: Crescimento logístico, densidade global (20 réplicas)
    • Crescimento Populacional

nt_fisher-gd

  • Velocidade

vel_fisher-gd

  • Detalhe

vel_fisher-gd-b

  • Comentário : Percebe-se que a velocidade não só está abaixo do esperado como parece ser igual a zero. Isso me fez pensar se o método para calcular a velocidade no modelo de reação-difusão logístico deve ser mudado. Vocês tem alguma idéia do porque isso está ocorrendo?
  • Reação-Difusão: Crescimento logístico, densidade local (20 réplicas)
    • Crescimento Populacional
      • Congifuração inicial = Centro (0,0)

nt_fisher-ld

  • Congifuração Aleatória Uniforme

nt_fisher-ld-c2

  • Velocidade
    • Congifuração inicial = Centro (0,0)

vel_fisher-ld

  • Congifuração Aleatória Uniforme

vel_fisher-ld-c2

  • Detalhe (Configuração aleatória)

vel_fisher-ld-c2b

  • Comentário : Aqui o caso é bem mais complicado. Primeiro dá para ver que algumas combinações de parâmetros levam à extinção "inesperada" da população, como o Paulo já havia atentado.
    Além disso, estou com dúvidas em como calcular o tamanho populacional esperado. Do jeito que fiz, é independente do raio de percepção do indivíduo. No entanto os resultados mostram o contrário. Da mesma forma, os parâmetros de inclinação de denso-dependência assim como as taxas basais afetam a dinâmica como mostra os casos 3 e 4 para ambas configurações iniciais testadas. Vejam que nos casos 4 a única mudança é o valor das taxas basais, porém mantém-se a taxa de crescimento populacional (b0 - d0).
    Em relação à velocidade, os mesmos problemas permanecem. Não percebi diferença variando o raio de percepção dos indivíduos.

CONCLUSÃO

Acho que a simulação está funcionando corretamente, porém tem esses casos especiais que merecem ser discutidos. Acho que isso faz parte de um modelo de simulação, correto? Na verdade, a única questão que tenho é sobre o cálculo da velocidade para reação-difusão logística.

@awade2
Copy link
Contributor

awade2 commented Oct 9, 2014

Chalom, esqueci de colocar o set.seed... e não usei nada que demandasse a função all.equal. Não vejo onde ela se aplicaria em nossos testes.

Ah, e ainda não implementei no código um contador que não seja de um em um. Não estou conseguindo lembrar da formula para isso.

piklprado added a commit that referenced this issue Oct 23, 2014
Tudo funfando! Ver tb os resultados das funções de teste no issue #16
@renatocoutinho
Copy link
Contributor

Se eu entendi corretamente, o processo é rodar o Tests.R e olhar pras figuras? (que devem ser as que o D2 colocou acima).

Já usei o Travis-CI e é muito bom, mas tem duas coisas que precisam ser adaptadas:

  1. Pra automatizar isso precisa transformar essas comparações entre simulado e esperado em números, que batem ou não. Com um set.seed daria pra testar até valores específicos, mas acho que isso restringiria demais as alterações (se você acrescenta um sorteio ou muda a ordem de qualquer coisa, os resultados mudam). Então acho que precisa ser uma comparação estatística mesmo.
  2. Eu pus pra rodar aqui, um i7 com 8 (pseudo-)cores, e demorou um monte, até cancelei ainda na Comb-07. Os testes precisam ficar (bem) mais curtos, deveria rodar tudo em ~1h (a verificar), se não vai estourar o tempo de execução do Travis. Alternativamente, dá pra deixar um serviço rodando no abacus que roda os testes a cada commit e manda um e-mail avisando, mas isso já vem depois do push, não antes (é possível fazer ele procurar os PRs, mas teria que investigar...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants