exercicio 1.7
Adriano Ogata
No exercício 1.7 é dito que o good-enough? não é adequado para o
cálculo de números pequenos. Por que? Para números grandes também
haveria problemas, mas a única coisa que imaginei foi que a
aproximação se dá de forma lenta então para números grandes esse
processo toma cada vez mais tempo. Outra coisa, nesse caso, seria a
precisão mas não sei se é esse o caso. Pensando em números com
precisão limitada, não dá para ter muitos dígitos significativos antes
E depois da vírgula. No caso de números grandes, uma boa parte da
mantissa já seria usada, deixando pouca precisão para os dígitos
fracionários.
A sugestão de como melhorar o good-enough?, verificando quando a
alteração fosse 'pequena o suficiente' eu implementei adicionando um
novo parâmetro para controlar esse limiar. Era algo assim mesmo?
Og!
Luciano Ramalho
> No exercício 1.7 é dito que o good-enough? não é adequado para o
> cálculo de números pequenos. Por que?
Veja a implementação de good-enough? :
(define (good-enough? guess x)
(< (abs (- (square guess) x)) 0.001))
E se eu quiser calcular a raiz quadrada de 0.000007, o que acontece?
> Para números grandes também
> haveria problemas, mas a única coisa que imaginei foi que a
> aproximação se dá de forma lenta então para números grandes esse
> processo toma cada vez mais tempo.
Não creio que isso seja o problema, porque a implementação de
improve-guess usa a média entre o chute e x / chute, e isso converge
rapidamente.
> Outra coisa, nesse caso, seria a
> precisão mas não sei se é esse o caso. Pensando em números com
> precisão limitada, não dá para ter muitos dígitos significativos antes
> E depois da vírgula. No caso de números grandes, uma boa parte da
> mantissa já seria usada, deixando pouca precisão para os dígitos
> fracionários.
Aí sim, eu tenho a mesma intuição que você sobre isso. Mas ainda não
sentei para implementar um teste que demonstre o problema
concretamente. É onde eu parei, para retomar durante a semana.
[ ]s
Luciano
Conrado Porto Lopes Gouvêa
>
> Aí sim, eu tenho a mesma intuição que você sobre isso. Mas ainda não
> sentei para implementar um teste que demonstre o problema
> concretamente. É onde eu parei, para retomar durante a semana.
>
Tente tirar a raiz de 1e64 :)
O problema é a precisão mesmo. Do jeito que está, você aceita um chute
como bom o bastante se o quadrado dele difere por menos que 0.001 do
número inicial. Mas para números do tipo 1e32, é impossível dois
números diferirem por tão pouco.
Conrado
PS: acabei de commitar meu código, espero que não tenha feito besteira...
Mariana Bravo
Já estamos discutindo a solução? O que vcs fizeram para o good-enough? ficar melhor?
Mari
--
Mariana Bravo
Celular: (11) 9179 7796
msn: mar...@gmail.com
Skype: marivbravo
Luciano Ramalho
> Esse exercício é mesmo bem legal! Eu tinha conseguido falhar o raiz pra
> números pequenos, mas ainda não tinha achado a resposta pra números grandes.
>
> Já estamos discutindo a solução? O que vcs fizeram para o good-enough? ficar
> melhor?
Pelo cronograma que combinamos antes, estamos na semana 2 então já é
hora de discutir soluções. A idéia original era que no começo da
semana 2 as discussões não "entregassem" as soluções, mas acho que não
precisamos ter tantas regras, de repente.
Na verdade, a seção 1.1 já demonstrou até que não é ideal deixar todos
os exercícios para discutir na semana 2, porque nela tem alguns grupos
de exercícios intercalados na discussão.
[ ]s
Luciano
Renato Cunha
> O problema é a precisão mesmo. Do jeito que está, você aceita um chute
> como bom o bastante se o quadrado dele difere por menos que 0.001 do
> número inicial. Mas para números do tipo 1e32, é impossível dois
> números diferirem por tão pouco.
É, essa foi minha conclusão e meus comentários na solução sugerem isso.
2009/7/14 Mariana Bravo <mar...@gmail.com>:
> Já estamos discutindo a solução? O que vcs fizeram para o good-enough? ficar
> melhor?
Eu usei a sugestão do livro e comparo a variação percentual dos
chutes. Para isso, adicionei um novo argumento que é o chute anterior.
Para a chamada inicial, usei +infinito como chute anterior.
Em outras palavras, se (em fonte de espaçamento fixo):
chute_antigo
0.999 <= -------------- <= 1.001
chute-atual
Com este método, consegui computar a raiz quadrada de 1e+308 e de
1e-323 sem problemas.
A minha função in-range?, que verifica a relação do chute poderia ser
melhor, mas vou deixar para outro exercício.
[]'s,
--
Renato Cunha <http://renatocunha.com>
dropline GNOME page: <http://trovao.droplinegnome.org>
The ship of failure floats on a sea of excuses
- Portal?
Luciano Ramalho
> 2009/7/12 Conrado Porto Lopes Gouvêa <conrado...@gmail.com>:
> > O problema é a precisão mesmo. Do jeito que está, você aceita um chute
> > como bom o bastante se o quadrado dele difere por menos que 0.001 do
> > número inicial. Mas para números do tipo 1e32, é impossível dois
> > números diferirem por tão pouco.
>
> É, essa foi minha conclusão e meus comentários na solução sugerem isso.
>
> 2009/7/14 Mariana Bravo <mar...@gmail.com>:
>
> > Já estamos discutindo a solução? O que vcs fizeram para o good-enough? ficar
> > melhor?
>
> http://tinyurl.com/trovao1-7
>
> Eu usei a sugestão do livro e comparo a variação percentual dos
> chutes. Para isso, adicionei um novo argumento que é o chute anterior.
> Para a chamada inicial, usei +infinito como chute anterior.
>
> Em outras palavras, se (em fonte de espaçamento fixo):
>
> chute_antigo
> 0.999 <= -------------- <= 1.001
> chute-atual
>
> Com este método, consegui computar a raiz quadrada de 1e+308 e de
> 1e-323 sem problemas.
extremos da precisão do float.
> A minha função in-range?, que verifica a relação do chute poderia ser
> melhor, mas vou deixar para outro exercício.
range?. Como expressões aritméticas em Scheme não são tão fáceis de
ler quanto em linguagens que usam notação infixa para aritmética, acho
que vale a pena criar pequenas funções como a sua in-range? para
tornar o código mais inteligível.
[ ]s
Luciano
Mariana Bravo
(< (abs (- 1.0 (/ old-guess guess)) 0.001)
equivale a
(in-range? 0.999 1.001 (/ old-guess guess) )
né? É isso ou eu entendi errado?
Outra coisa que achei interessante nessa solução é que não importa muito qual o "old-guess" inicial, desde que (good-enough? old-guess guess) seja false. Poderia ser 2, por exemplo, e continuaria funcionando. (Aliás, esse good-enough? não depende do valor de x, apenas do guess e old-guess).
Eu fiz o good-enough? comparando o chute atual com o próximo chute por igualdade e funcionou muito bem:
http://code.google.com/p/eipc/source/browse/pessoal/mvb/sec1.1/ex1-7.scm
Abs
Mari
2009/7/19 Luciano Ramalho <ram...@gmail.com>
Renato Cunha
> Na verdade a função in-range? é o mesmo que a condição apresentada no livro,
> só que mais legal de ler - na minha opinião.
> (< (abs (- 1.0 (/ old-guess guess)) 0.001)
> equivale a
> (in-range? 0.999 1.001 (/ old-guess guess) )
> né? É isso ou eu entendi errado?
Exato.
> Outra coisa que achei interessante nessa solução é que não importa muito
> qual o "old-guess" inicial, desde que (good-enough? old-guess guess) seja
> false. Poderia ser 2, por exemplo, e continuaria funcionando. (Aliás, esse
> good-enough? não depende do valor de x, apenas do guess e old-guess).
Verdade, desde que os chutes iniciais sejam +- diferentes. Quanto ao
good-enough? não depender de x, é verdade. Ele só ficou lá por que minha
solução foi construída de forma iterativa e preferi manter, mais ou menos, a
interface das funções. Daqui a pouco eu devo passá-la por uma etapa de
embelezamento.
> Eu fiz o good-enough? comparando o chute atual com o próximo chute por
> igualdade e funcionou muito bem:
> http://code.google.com/p/eipc/source/browse/pessoal/mvb/sec1.1/ex1-7.scm
Interessante.
[]'s,
Renato.