Benilton, bom saber desses pequenos detalhes. No meu caso, de uns tempos pra cá eu tenho trabalhado com bases de dados da ordem de milhoes de registros e perto de 50 variáveis. Via de regra, eu faço 99% do "trabalho sujo" (Consistência e transformação das variáveis) usando algum BD SQL (MySQL, Oracle, SQL Server, depende do caso) e após quase tudo arrumado, eu levo pro R. Com o R em 64 bits, tenho feito alguns testes para ver se faço parte da prepara ção já no R e esses milissegundos a menos tem feito a diferença, principalmente na parte de lidar com memória. Eu não faço 100% no R porque ainda faço essas transformações com mais rapidez e segurança usando SQL nativo. Um dia (ainda este ano) com certeza o farei com mais naturalidade no R. lmassis <at> yahoo <dot> com <dot> br assis.leonard <at> gmail <dot> com 2011/8/11 Benilton Carvalho <beniltoncarvalho@gmail.com>
A verdade, Leonard, e' que o que "mata" a opcao 1 e' a conversao da matriz logica is.na(x) para valores *reais* (para que a comparacao com 1 possa ser realizada).
Muitos usuarios sao surpreendidos com os seguintes resultados:
is.double(1) ## TRUE is.integer(1) ## FALSE
Entao, a expressao
is.na(x) == 1
vai exigir a conversao para numeros reais, que usa mais memoria e tempo para a conversao...
Agora, se vc tiver o previo conhecimento de que essa substituicao deve acontecer em apenas uma pequena fracao dos dados, vc pode matar a pau com:
x[which(is.na(x))] <- .1
Entretanto, e' importante notar que esses ganhos sao substanciais apenas para conjuntos de dados de grandes volumes ou atividades que sejam repetidas muitas e muitas vezes. Se for algo a ser executado apenas uma vez num conjunto de dados pequeno, o que o usuario fara' com os 3ms que ele economizou?
b _______________________________________________ R-br mailing list R-br@listas.c3sl.ufpr.br https://listas.inf.ufpr.br/cgi-bin/mailman/listinfo/r-br Leia o guia de postagem (http://www.leg.ufpr.br/r-br-guia) e forneça código mínimo reproduzível.