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

Definir arquivos mínimos para execução #2

Open
5 tasks
AndreaSanchezTapia opened this issue Mar 30, 2017 · 7 comments
Open
5 tasks

Definir arquivos mínimos para execução #2

AndreaSanchezTapia opened this issue Mar 30, 2017 · 7 comments

Comments

@AndreaSanchezTapia
Copy link
Member

AndreaSanchezTapia commented Mar 30, 2017

Temos o exemplo inteiro da Mata Atlântica aqui e isso faz com que cada rodada de teste seja muito longa e com funções paralelas que talvez sejam repetidas com a base de dados (limpeza, processamento de camadas preditoras).

Proponho:

  • tirar os dados de anfíbios e aves. - deixar FLORA_occs_final10Km.csv
  • tirar tudo o referente a limpeza taxonômica
  • tirar tudo o referente a criação de eigenvariables - mantendo as camadas.
  • modificar a resolução das camadas de teste para 10 x 10 km
  • tirar os scripts que não estão rodando específicamente a modelagem - deixar apenas script.R
@FelipeSBarros
Copy link
Contributor

Concordo. Sugiro fazer uma limpeza nas funções que estão no arquivo read.eval1.R
Deve ter coisa desnecessária lá. Além de trocar o nome do arquivo para algo como "toolbox. R"

@FelipeSBarros
Copy link
Contributor

FelipeSBarros commented Aug 30, 2017

O arquivo ARF_sp_DataPreparation também pode ser removido pois foi criado para a análise da Mata Atlantica...

@gmgall
Copy link
Contributor

gmgall commented Sep 5, 2017

Pré-requisito da issue #8.

@AndreaSanchezTapia
Copy link
Member Author

podemos manter um subconjunto de dados como data() do pacote, para rodar exemplos (Zygia e mais alguém) e guardar esse toolbox.R como funções do pacote (se vale a pena)

@gmgall
Copy link
Contributor

gmgall commented Sep 11, 2017

O Hadley Wickham tem uma abordagem parecida com essa do toolbox.R para criar pacotes. Do capítulo sobre namespaces:

I believe that packages that have a wide audience should strive to do one thing and do it well. All functions in a package should be related to a single problem (or a set of closely related problems). Any functions not related to that purpose should not be exported. For example, most of my packages have a utils.R file that contains many small functions that are useful for me, but aren’t part of the core purpose of those packages. I never export these functions.

No pacote que criei, por exemplo, temos as funções do_algortimo() exportadas e funções utilitárias como cropModel() e createBuffer() não exportadas. Essas funções poderiam estar todas num tools.R ou utils.R.

@diogosbr
Copy link
Member

Vou elaborar esse conjunto essa semana OK?
Umas duas ou três espécies tá bom, né?

@AndreaSanchezTapia
Copy link
Member Author

@diogosbr, acho que não precisa ser um conjunto aparte do que já tem na pasta.

AndreaSanchezTapia added a commit to AndreaSanchezTapia/Back-end that referenced this issue Oct 20, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants