Cezar, note que nem todos estes numeros nao possuem representacao binaria perfeita:
4.96 = 100.11110101110000101000111101011100001010001111010111 ( = 4.9599999999999999383484909024105265228684473934444104163875499178081282073594053273515617319174792...) 4.97 = 100.1111100001010001111010111000010100011110101110000101 ( = 4.9699999999999999522262787102249791917074708051575354490781853972972047883147623040656351019280470...) 5.02 = 101.0000010100011110101110000101000111101011100001010001111011 (exatamente) 5.03 = 101.0000011110101110000101000111101011100001010001111010111 (exatamente) Por fim, como a matematica e' feita na representacao binaria (que neste caso e' imperfeita), a gente nao pode esperar os mesmos resultados. Por isso a minha sugestao de usar o all.equal(), que permite o uso de tolerancia para compensar estes problemas na representacao binaria.... b 2011/4/15 Gustavo Henrique de Carvalho <[email protected]>: > Aquela resposta na página que enviei explica o porquê. Ainda, ela leva > à esse pdf: > > http://www.validlab.com/goldberg/paper.pdf > > De qualquer forma, só para ilustrar: > >> a <- c(4.96, 4.97, 4.96) >> b <- c(5.02, 5.03, 5.03) >> d <- c(5.96, 5.97, 5.96) >> sd(a) == sd(b) > [1] FALSE >> sd(a) == sd(d) > [1] TRUE > >> 0.2 * 0.4 == 0.08 > [1] FALSE > > 2011/4/14 Cézar Freitas <[email protected]>: >> Acho que não fui claro o suficiente: os desvios deveriam, de fato, ser >> iguais (os números estão à mesma distância de suas respectivas médias), >> porém o R não retrata assim (independentemente da quantidade de dígitos) e >> eu fiquei surpreso. >> >> Na minha época, sei que havia coisinhas que evitávamos, como elevar números >> muito grandes ao quadrado para somá-los e depois dividi-los, quando era >> possível contornar o problema aplicando a divisão previamente, mas nas >> máquinas de hoje eu achei que não era necessário preocupar-se com tais >> acontecimentos. >> >> Alguma outra pista? >> >> C. >> >> Em 14 de abril de 2011 17:13, Gustavo Henrique de Carvalho >> <[email protected]> escreveu: >>> >>> >>> http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f >>> >>> > print(y$dp, digits = 13) >>> [1] 0.005773502691896 0.005773502691897 >>> >>> 2011/4/14 Benilton Carvalho <[email protected]>: >>> > Cezar, >>> > >>> > o que vc esta' procurando e' o seguinte: >>> > >>> > all.equal(y$dp - refer, rep(0, 2)) >>> > >>> > b >>> > >>> > 2011/4/14 Cézar Freitas <[email protected]>: >>> >> Olá. >>> >> >>> >> Bem, escrevo apenas para ilustrar algo que me surpreendeu. Estava >>> >> plotando >>> >> gráficos e os colorindo segundo seu desvio padrão estava ou não acima >>> >> de um >>> >> ponto de corte. Reproduzo abaixo a parte do código que interessa: >>> >> >>> >> y=as.data.frame(matrix(c(4.96,5.02,4.97,5.03,4.96,5.03), ncol=3)) >>> >> y$dp=apply(y,1,sd) >>> >> >>> >>> y >>> >> V1 V2 V3 dp >>> >> 1 4.96 4.97 4.96 0.005773503 >>> >> 2 5.02 5.03 5.03 0.005773503 >>> >> >>> >> refer=y$dp[1] >>> >> >>> >> y$dp<=refer >>> >> >>> >> [1] TRUE FALSE >>> >> >>> >> Sei que o R é extremamente preciso e até podemos alterar sua mantissa >>> >> nos >>> >> cálculos, mas isso não é rotineiro para cálculos tão simples. O pessoal >>> >> do >>> >> cálculo numérico saberia dizer o que evitar para não cair nessas >>> >> armadilhas >>> >> no futuro? >>> >> >>> >> Abraços, >>> >> Cézar Freitas >>> >> >>> >> _______________________________________________ >>> >> R-br mailing list >>> >> [email protected] >>> >> https://listas.inf.ufpr.br/cgi-bin/mailman/listinfo/r-br >>> >> >>> >> >>> > _______________________________________________ >>> > R-br mailing list >>> > [email protected] >>> > https://listas.inf.ufpr.br/cgi-bin/mailman/listinfo/r-br >>> > >> >> > -- Successful people ask better questions, and as a result, they get better answers. (Tony Robbins) _______________________________________________ R-br mailing list [email protected] https://listas.inf.ufpr.br/cgi-bin/mailman/listinfo/r-br
