À quel point est-il important pour un programmeur de savoir comment implémenter un algorithme QuickSort / MergeSort en mémoire? [fermé]

58

Je passais en revue mes notes et suis tombé sur l'application de différents algorithmes de tri.

Alors que je tentais de comprendre l’implémentation de QuickSort et MergeSort, je me suis rendu compte que, bien que je fasse de la programmation pour gagner ma vie et que je me considère décent dans ce que je fais, je n’ai ni la mémoire photographique ni le courage de mettre en œuvre ces algorithmes sans s'appuyant sur mes notes. Tout ce dont je me souvenais, c’est que certains de ces algorithmes sont stables et d’autres pas. Certains prennent le temps de compléter O (nlog (n)) ou O (n ^ 2). Certains utilisent plus de mémoire que d'autres ...

J'aurais l'impression de ne pas mériter ce genre de travail si ce n'était pas le cas, car mon poste n'exige pas que j'utilise un algorithme de tri autre que ceux que l'on trouve dans les API standard. Je veux dire, combien d’entre vous occupent un poste en programmation où il est essentiel de pouvoir se souvenir de ce genre de choses ou de les inventer par vous-même?

algorithms

— John Smith
source

13

Vous devez vous rappeler qu'une solution existe et à quel moment l'utiliser. Ensuite, allez dans la documentation et implémentez-le. Si vous n'aviez pas entendu parler de quicksort ou de mergesort, vous utiliseriez toujours Bubblesort et observiez votre programme dans une crawl d'analyse pour proposer des solutions de qualité inférieure lorsque les données augmentent.

— Pieter B

1

Outre les bonnes réponses mentionnées ci-dessous, notez que de nombreuses entreprises ont besoin de (1) connaître la complexité de tels algorithmes, (2) maîtriser leur mise en œuvre sur un tableau noir.

— Sakis

3

Je suis sûr qu'il est important de mémoriser ces algues pour éviter que Google ne soit souvent hors ligne. : o

— Lee James

Vous devez connaître leurs performances, leurs cas d'utilisation, etc. Savoir que les implémenter par cœur est quelque chose qui n'est exigé que par les entreprises de technologie interrogées.

— Sakisk

@PieterB, je ne suis pas d'accord. Il n'est pas nécessaire de connaître les notions de "mergesort" et de "quicksort" pour "l'algorithme de tri le plus performant" de Google

— hyankov

117

Demandons à Albert et voyons ce qu'il a à dire à ce sujet:

"Je n'ai pas besoin de tout savoir, j'ai juste besoin de savoir où le trouver, quand j'en ai besoin"

- Albert Einstein , paraphrasé

Amen, frère Albert, Amen.

Une fois que vous avez fait une bonne analyse des algorithmes essentiels dans une discipline donnée (sorte, recherche, peu importe), vous pouvez alors oublier les détails de la mise en oeuvre jusqu'à ce que vous ayez réellement besoin de l'algo. Dans ce cas, vous allez le rechercher bibliothèque préexistante Il y a 25 ans, j'ai construit un système de recherche majeur utilisant des arbres B *, mais aujourd'hui, il me faudrait RTFM pour bien les utiliser.

— Peter Rowell
source

5

Cette citation est douteuse: je suis «incapable de trouver une preuve substantielle reliant le dicton à Einstein» .

— Wok

9

Comment cela répond-il à la question? Il a dit: «Je n'ai pas besoin de tout savoir», il n'a pas dit «Je n'ai besoin de rien savoir». Certaines compétences sont fondamentales, et toute la question était de savoir si un élément d'information particulier appartenait ou non à la catégorie des compétences fondamentales.

— Konrad Rudolph

1

Penser que le but est de mémoriser quicksort, c'est rater le point de la question. Bien sûr, dans le monde réel, si vous aviez besoin d'un tri rapide, utilisez la routine de bibliothèque ou recherchez le code et copiez-le. Le test consiste à vérifier si vous comprenez la récursivité, les invariants de boucle, etc., et vous demander de noter rapidement un algorithme de tri n’est qu’une démonstration très simple de cette connaissance. Si vous n'êtes pas capable de dériver immédiatement un tri rapide de 20 lignes, combien de choses faites-vous régulièrement de manière inefficace ou incorrecte sans le savoir?

— Larry Gritz

3

@ Larry: Je pense avoir oublié plus que beaucoup de programmeurs ne connaissent les détails des algorithmes - et le tri rapide à partir de zéro en est un - pour une très bonne raison - j'ai choisi de lire sur des choses de haut niveau et d'utiliser plutôt des langages de haut niveau que rester dans des bols de détail de mise en œuvre de bas niveau. Franchement - peu m'importe la sorte de routine de bibliothèque que j'utilise - elle peut utiliser la poussière et les fées de pixy en ce qui me concerne. Les docs vont dire au O () pour le dimensionnement - c'est tout ce que j'ai besoin de savoir.

— mattnz

2

@mattnz: Un suivi quelque peu tardif de votre "dimensionnement O ()". Ce que j’ai appris à la dure, c’est qu’avec un grand ensemble de données, une mauvaise localité de référence peut complètement submerger le O (). Vous avez peut-être un algo O(n log n), mais si vous avez beaucoup de données manquantes dans la mémoire cache ou (que Dieu nous en préserve), vous frappez le disque, ce n log nne sera qu'un bon souvenir.

— Peter Rowell

49

Ce n'est pas vraiment une question de mémorisation. Il s’agit de comprendre en profondeur des classes générales d’algorithmes tels que diviser pour régner. Si vous comprenez vraiment diviser pour régner, vous n'avez pas besoin de mémoriser le tri rapide. Vous pouvez le dériver sur place au besoin. En outre, le véritable avantage n'est même pas de pouvoir récupérer rapidement un tri rapide, mais bien de savoir quand un nouveau problème peut être résolu par une solution de division.
Tous les travaux de programmation ne sont pas identiques. Certains emplois nécessitent une connaissance approfondie des algorithmes, certains ont besoin de personnes qui comprennent la théorie des types, et d'autres simplement de personnes capables de récupérer des données dans un formulaire Web et de les transférer dans une base de données. Certains emplois ont même besoin de toutes ces compétences à la fois. Quel genre de travail voulez-vous travailler?

— Charles E. Grant
source

5

Je ne pense pas qu'il soit possible de comprendre QuickSort sans se souvenir de QuickSort. Ce n'est pas une chose compliquée et obscure, c'est juste deux idées génériques combinées. La même chose s’applique au tri par fusion, mais là vous n’avez qu’une idée: P

— drxzcl

Je ne suis pas d'accord avec le 2ème point. tous les emplois sont les mêmes, seul l'intervieweur change. celui-ci sait très bien trier et pense que tout bon programmeur doit savoir trier, car c’est tout ce dont il se soucie.

— IAdapter

2

@ IAdapter, vous plaisantez sûrement! De par ma propre expérience, je sais que les connaissances et les compétences dont j'avais besoin pour mon premier travail en écriture de macros TROFF pour une entreprise de logiciels rétractable sont très différentes de celles dont j'avais besoin pour mon travail actuel dans un laboratoire de biologie informatique.

— Charles E. Grant,

@ CharlesE.Grant la plupart du temps, interviwer ne vérifie pas si vous avez les compétences dont vous avez besoin pour faire votre travail (je ne me souviens pas de la dernière question javascript / css qui m’a été posée et je fais des applications Web).

— IAdapter

10

Je pense que le seul moment où vous devez vous rappeler de tout cela est lorsque vous postulez pour un emploi, lorsque vous devez trouver des réponses sur-le-champ et ne pas disposer de ressources extérieures.

Des collègues ont réécrit QuickSort et ainsi de suite, mais je leur répète de revenir à l’utilisation des fonctions de tri intégrées au langage. Je sais que, selon le type de projet sur lequel nous travaillons, nous devons garder en mémoire d’autres algorithmes, car ils ne sont généralement pas inclus dans les bibliothèques standard, mais le tri n’est pas celui qui est utilisé car il est généralement intégré au langage.

Cependant, lorsque nous devons nous souvenir de ces algorithmes, nous nous tournons généralement vers Google ou un livre, qui ne recherche généralement pas une implémentation spécifique, mais plutôt celle qui convient le mieux à notre problème.

— effrayant
source

6

Se rappeler quel algorithme est utile dans quels scénarios serait largement suffisant pour vous aider pendant votre travail. En fait, la plupart des tâches de programmation ne nécessitent pas de mémorisation d'approche, mais s'intéressent plutôt à votre façon de reconnaître le modèle algorithmique face au problème .

En fait, il existe une abondance d'informations dans la plupart des blogs / articles de programmation sur des sujets relatifs aux algorithmes. Ainsi, la mémorisation d'une mise en œuvre exacte n'a pas d'importance. L'information la plus précieuse serait de se faire une idée de base sur le type d'algorithme disponible et sur le problème spécifique qu'il est capable de résoudre . Rechercher une mise en œuvre exacte une fois que vous savez ce que vous recherchez est assez rapide.

En résumé, il est toujours préférable de savoir ce que vous recherchez et où sont les références - qui vous guideront vers la source.

— EL Yusubov
source

5

La mise en œuvre exacte n'est pas très importante. Mais le principe de mergesort / quicksort - la récursivité, le partitionnement, etc., est très basique et doit être compris par tous les programmeurs. Une fois que vous avez compris, ces algorithmes sont très simples à décrire en mots.

Ce n'est pas vraiment un problème de savoir si vous pouvez le rechercher ou si vous pouvez le rechercher sur Google, mais bien si le programmeur comprend ces techniques de résolution de problèmes et est capable de l'appliquer à d'autres situations.

— hgh
source

3

Je suis de deux avis sur ce sujet. Je connais beaucoup de programmeurs qui ne savent pas ce qu'est un algorithme de tri, mais font assez bien leur travail. Je crois aussi à la compréhension des principes afin de vraiment comprendre le domaine.

Il est difficile pour moi d’avoir une réponse impartiale à ce sujet car je programme depuis si longtemps que j’ai probablement oublié plus d’algorithmes que je connais actuellement - mais je connais toujours ceux de tri mentionnés dans cette question. Je pense que les leaders d'opinion d'Agile (par exemple, Ron Jeffries et Alistair Cockburn) ont de bonnes idées proches de cette idée (par exemple, Shu-Ha-Ri).

En résumé, voici la réponse difficile: utilisez l'API (le NIH est un signe d'immaturité du développeur), mais comprenez toujours les principes sous-jacents. J'espère que ça aide.

— Mike Polen
source

2

Trier et rechercher sont incroyablement importants, que vous soyez un fan de Donald Knuth ou que vous souhaitiez être le prochain Larry Page. En fonction de votre activité et du niveau de concurrence que vous pouvez maîtriser parmi vos candidats, je vous recommanderais d'inclure certains des concepts suivants dans l'entretien.

Tri

Esquisse d'une sorte d'algorithme de tri.
Citez quelques exemples d’algorithmes de tri.
Comparez / contrastez deux types avec des caractéristiques de performance différentes.
S'ils ne mentionnent pas l'utilisation de la mémoire, posez des questions à ce sujet.

Recherche

Nommez autant d'algorithmes de recherche que possible.
Compare / contraste deux algorithmes de recherche.
Esquissez toute recherche autre que la recherche linéaire.

Certains pourraient dire que requérir le code pour ces algorithmes est excessif sauf si le travail est sur une île déserte sans connexion Internet. Une autre considération est que, si vous disposez de 30 minutes et que vous souhaitez poser des questions à propos de quelque chose d'autre, la mise en œuvre de ce type pourrait prendre beaucoup de temps pour de nombreux candidats.

— DeveloperDon
source

J'avais l'habitude de penser que demander aux gens de programmer des interviews était idiot, mais vous ne voudriez pas en croire le nombre de personnes avec des CV apparemment fantastiques et qui répondent aux questions "sociales" avec brio, mais qui, pour la vie, ne peuvent pas Notez une implémentation correcte de 'strcat' ou une autre fonction simple. Plusieurs fois, cela m'a évité d'embaucher quelqu'un qui, sans la question idiote du codage, aurait pu causer une douleur sans fin et entraîner l'équipe avec incompétence.

— Larry Gritz