[R-br] precisão numérica no R - uma falha?

[Benilton Carvalho]

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 <gustavo.bio em gmail.com>:
> 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 <cezarcamelo em gmail.com>:
>> 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
>> <gustavo.bio em gmail.com> 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 <beniltoncarvalho em gmail.com>:
>>> > Cezar,
>>> >
>>> > o que vc esta' procurando e' o seguinte:
>>> >
>>> > all.equal(y$dp - refer, rep(0, 2))
>>> >
>>> > b
>>> >
>>> > 2011/4/14 Cézar Freitas <cezarcamelo em gmail.com>:
>>> >> 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
>>> >> R-br em listas.c3sl.ufpr.br
>>> >> https://listas.inf.ufpr.br/cgi-bin/mailman/listinfo/r-br
>>> >>
>>> >>
>>> > _______________________________________________
>>> > R-br mailing list
>>> > R-br em listas.c3sl.ufpr.br
>>> > 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)