Ce qui est fou, c'est qu'apparement l'interpreteur LISP a déjà compris lors du premier appel que c'est un appel "tail recursive" au vu de tes temps d'execution. Si c'est le cas et sans directives, je suis vraiment épaté.
Je ne pense pas a priori dans ce cas précis que ta fonction memoize apporte un énorme gain, je pense même que normalement, en faisant 2 appels naïf, le deuxième devrait être "immédiat" sans le memoize.
Je serais interessé d'avoir les temps sans passer par la hash table pour confirmer cette hypothése.
Dommage que je ne digére vraiment pas la syntaxe lisp (et ce ne sont pas les parenthéses qui me dérange le plus) et l'ordre prefixe.
En fait ça me fait penser à une démo de math, sauf qu'il n'y a pas de symboles graphiques (Sigma, PI, QuelqueSoit, barre d'intégrale, etc...) pour faire des points d'ACCROCHE à l'oeil et l'ordre infixe.
< troll>
Et ceux qui me dise que la polonaise inversé, c'est le top, pourquoi l'écriture mathématique est infixe et n'est pas en polonaise inversée, hein, si conceptuellement c'était mieux pour réflechir.
C'est uniquement une facilité pour la conception des programmes de parsing, le cerveau humain ne pense pas polonaise inversée, bien qu'avec l'habitude, on se dit que c'est aussi simple (c'est juste que le cerveau fait la transformation infixe->postfixe de manière plus mécanique avec l'usage et que sur les vielles calculatrices SANS mémoire, c'est plus pratique pour évaluer une expression, au passage ça évite l'usage des parenthèse, mais LISP a raté le coche de ce côté là :-)))))
< /troll>
>> Alors que ton exemple permet de gagner en vitesse, mais au détriment de la mémoire (et encore ça se discute, moins de pile à gérer)
> Sinon, du point de vue mémoire, entre stocker 1000 entiers dans une hash table et refaire un très grand nombre de fois le même calcul, le choix est vite fait à mon avis.
C'est ce que je disais, ça se discute :-)
Si au lieu d'un entier, c'est tout une structure à stocker, la taille de la pile qu'il faudra peut être augmenter avant l'execution du programme, etc...
A chaque cas sa solution, et je crois que c'est un peu l'esprit qui se dégage sur cette news.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par darkleon . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 3.
Je ne pense pas a priori dans ce cas précis que ta fonction memoize apporte un énorme gain, je pense même que normalement, en faisant 2 appels naïf, le deuxième devrait être "immédiat" sans le memoize.
Je serais interessé d'avoir les temps sans passer par la hash table pour confirmer cette hypothése.
Dommage que je ne digére vraiment pas la syntaxe lisp (et ce ne sont pas les parenthéses qui me dérange le plus) et l'ordre prefixe.
En fait ça me fait penser à une démo de math, sauf qu'il n'y a pas de symboles graphiques (Sigma, PI, QuelqueSoit, barre d'intégrale, etc...) pour faire des points d'ACCROCHE à l'oeil et l'ordre infixe.
< troll>
Et ceux qui me dise que la polonaise inversé, c'est le top, pourquoi l'écriture mathématique est infixe et n'est pas en polonaise inversée, hein, si conceptuellement c'était mieux pour réflechir.
C'est uniquement une facilité pour la conception des programmes de parsing, le cerveau humain ne pense pas polonaise inversée, bien qu'avec l'habitude, on se dit que c'est aussi simple (c'est juste que le cerveau fait la transformation infixe->postfixe de manière plus mécanique avec l'usage et que sur les vielles calculatrices SANS mémoire, c'est plus pratique pour évaluer une expression, au passage ça évite l'usage des parenthèse, mais LISP a raté le coche de ce côté là :-)))))
< /troll>
C'est ce que je disais, ça se discute :-)
Si au lieu d'un entier, c'est tout une structure à stocker, la taille de la pile qu'il faudra peut être augmenter avant l'execution du programme, etc...
A chaque cas sa solution, et je crois que c'est un peu l'esprit qui se dégage sur cette news.