Comment parler de théorie

Je me rends compte que cela pourrait être une question controversée, mais cela semblait être le bon endroit à poser. Veuillez me rediriger sinon.

Le contexte est que je suis un "praticien" (doctorant, je n'étudie pas la théorie CS) mais j'ai une base raisonnable en algorithmes de premier cycle et en mathématiques. Néanmoins, les discussions avec les théoriciens sont généralement très superficielles, comme s'ils avaient peur d'utiliser des termes mathématiques avec moi au cas où j'aurais peur. En réalité, je suis parfaitement à l'aise et intéressé par la théorie, mais je n'ai pas l'habitude d'en discuter, donc je n'utilise probablement pas toujours des termes qui me marqueraient comme "théoricien". Je trouve que l'approche directe ("s'il vous plaît dites-moi les détails") ne fonctionne pas toujours, en particulier si le théoricien en question a pris un ton condescendant qui place la barre haute pour l'expertise (cela arrive souvent).

En tant que théoriciens, si vous filtrez les gens de cette façon, avez-vous des recommandations sur la façon dont un praticien peut éviter d'être «signalé» par votre filtre?

Vous travaillez peut-être avec des élitistes grossiers, mais d'après mon expérience, la réticence à expliquer les détails techniques dépend plus du contexte que de la personne à qui je parle. J'éviterais généralement de donner les détails techniques d'une preuve / algorithme pendant le déjeuner ou dans le couloir même si mon interlocuteur était Alan Turing lui-même. La raison en est que les détails dépendent fortement du choix des notations et des concepts artisanaux introduits pour lisser une réclamation. De plus, comme tout le monde comprend les choses différemment et que je n'ai pas de façon générique d'expliquer un concept, je dois toujours m'adapter à mon interlocuteur (c'est pourquoi il est si difficile de donner des détails techniques dans une présentation de recherche).

Une exception est si mon interlocuteur a travaillé en étroite collaboration avec moi sur ce type de problème et ensuite, je sais que nous pouvons utiliser ce charabia commun que nous seuls comprenons parce que nous le développons ensemble après plusieurs sessions de tableau blanc (ou avant une date limite urgente) .

Une autre exception est si, après avoir donné un schéma général grossier de la preuve sans détails, mon interlocuteur pose une question précise montrant qu'il a vu une partie particulièrement dure de la preuve que je lui ai intentionnellement cachée afin de simplifier la présentation. Dans ce cas, nous ouvririons naturellement la boîte de Pandore et irions ensemble au cœur de l'épreuve, couche par couche ... et nous nous retrouvons généralement sur un tableau blanc car à un moment donné, nous avons à nouveau besoin de ce charabia commun qui ne nous convient que et ce problème.

Il y a plusieurs mœurs avec mon histoire déjà trop longue:

• Ne vous dépréciez pas car vous ne travaillez pas activement en informatique théorique. La plupart des gens ne se soucient pas de vos antécédents précis tant que vous montrez que vous êtes curieux de connaître leur travail.
• Lorsque les gens sont vagues sur une preuve / un concept, restez vigilant et essayez de guider la conversation en posant une question précise montrant votre compréhension et en aidant ainsi votre interlocuteur à choisir la partie de la preuve qu'il doit développer en premier. C'est évidemment assez difficile et imprévisible parce que vous ne pourrez peut-être pas faire de commentaires pertinents sur le pouce (cela arrive à tout le monde même aux "théoriciens"), mais si vous y parvenez, vous vous retrouverez probablement avec une discussion très éclairante.
• Même les «théoriciens» ont besoin de temps pour recharger les détails d'une preuve dans leur tête avant de pouvoir l'expliquer clairement. Prenez rendez-vous en vous demandant explicitement que vous êtes intéressé par les détails techniques de X. Cela laissera du temps à votre interlocuteur et à vous pour préparer, et facilitera la discussion. Assurez-vous d'avoir un tableau blanc ou un morceau de papier pendant la discussion afin que vous puissiez vraiment entrer dans les détails.

Parlant en tant que théoricien qui a parfois collaboré avec des chercheurs en systèmes, les détails mathématiques sont généralement la toute dernière chose dont je veux parler!

C'est vraiment, vraiment, facile de formaliser la mauvaise chose, et en plus d'être une énorme perte de temps, c'est vraiment décourageant. Les mathématiques sont une aiguille, pas un marteau, et chaque coup de l'aiguille coûte très cher. Si je parle à un chercheur en systèmes d'une collaboration potentielle, avant de me rendre à une cérémonie mathématique de haute église, je veux savoir:

1. Quel est le problème qu'il essaie de résoudre et pourquoi quelqu'un s'en soucie-t-il?
2. Quelles sont les techniques qu'ils utilisent actuellement pour attaquer ce problème?
3. Quelles sont les approches alternatives plausibles?
4. Quelles sont les contraintes sur la solution?
5. Comment ces contraintes ont-elles conduit aux choix opérés?

Notez que ce sont principalement les mêmes choses que tout autre collaborateur potentiel voudrait savoir, et la raison en est que pour déterminer une ligne d'attaque productive (mathématique ou autre), vous devez avoir une idée claire de ce qui est important à garder dans un modèle et ce qui est inessentiel.

Par exemple, un chercheur en systèmes collaborant avec un chercheur HCI devra suivre le même processus avant que la personne HCI puisse concevoir un protocole expérimental utile pour effectuer une étude utilisateur - personne ne s'attendrait à ce qu'une expérience valable puisse être menée sans une bonne compréhension du problème. Vous devriez avoir la même attente pour la modélisation mathématique!

De plus, il est presque toujours vrai que même avec ces réponses, le premier tour est faux, car beaucoup des facteurs les plus importants vivent généralement dans le bon goût et le sens technique de la personne à qui je parle. Enseigner et apprendre une bonne esthétique est difficile, mais c'est aussi pourquoi de telles collaborations en valent la peine.

J'ai vraiment aimé la réponse de Neel, et cela m'a inspiré pour partager une partie de mon expérience en tant que théoricien collaborant occasionnellement avec des personnes plus appliquées. L'une des étapes les plus difficiles et les plus frustrantes de la collaboration est de trouver un langage commun - afin que le problème puisse être formalisé correctement. D'après mon expérience, lorsqu'ils posent un problème à résoudre pour un théoricien, les gens ont tendance à donner trop de détails non pertinents. Par exemple, si nous essayons de prédire une série chronologique, est-il vraiment nécessaire de passer 5 minutes à me dire que ces transactions financières sont soumises à telle ou telle réglementation que vous souhaitez utiliser de telle ou telle manière?

Ma suggestion concrète pour parler aux théoriciens: Essayez de supprimer tous les détails inutiles. Si vous essayez d'optimiser un itinéraire de livraison, parlez des points et des distances (au lieu de me dire les adresses spécifiques). Lorsque vous parlez de données , dites tout de suite quel est leur type: chaînes, vecteurs numériques, images (dans quel format?). Est-il étiqueté ou non? Dans le premier cas, quel est le "type" des étiquettes (binaire, multiclasse, multilabel, annotation de texte, valeur réelle)?

$d$