Alors ça j'aimerais avoir une source. :) Oui, il faut prendre en compte à la fois la complexité en espace et en temps, mais au contraire, mon expérience est qu'un algo en O(N log N) peut gagner en temps parce qu'il stocke plus d'état que son équivalent O(N).
Les histoires de robuste/plus long à implémenter, je ne vois pas trop ce que ça a à faire ici : je connais des algorithmes qui en théorie sont pires que d'autres en temps ET en espace, mais parce que les jeux de données pour lesquels ils sont utilisés dépassent rarement (voire jamais) une taille déterminée, la complexité n'entre pas en compte, et justement tout l'intérêt de cet algo est qu'il est plus simple à implémenter malgré son temps d'exécution asymptotique plus grand.
[^] # Re: migre
Posté par lasher . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 2.
Alors ça j'aimerais avoir une source. :) Oui, il faut prendre en compte à la fois la complexité en espace et en temps, mais au contraire, mon expérience est qu'un algo en O(N log N) peut gagner en temps parce qu'il stocke plus d'état que son équivalent O(N).
Les histoires de robuste/plus long à implémenter, je ne vois pas trop ce que ça a à faire ici : je connais des algorithmes qui en théorie sont pires que d'autres en temps ET en espace, mais parce que les jeux de données pour lesquels ils sont utilisés dépassent rarement (voire jamais) une taille déterminée, la complexité n'entre pas en compte, et justement tout l'intérêt de cet algo est qu'il est plus simple à implémenter malgré son temps d'exécution asymptotique plus grand.