Cómo hablar de teoría

Me doy cuenta de que esta podría ser una pregunta polémica, pero este parecía ser el lugar correcto para preguntar. Por favor, redirígeme si no.

El trasfondo es que soy un "practicante" (estudiante de doctorado, no estudio teoría CS) pero tengo una base razonable en algoritmos de pregrado y matemáticas. Sin embargo, las discusiones con los teóricos suelen ser muy superficiales, como si tuvieran miedo de usar términos matemáticos conmigo en caso de que me asustara. En realidad, me siento perfectamente cómodo e interesado en la teoría, pero no estoy acostumbrado a discutirlo, por lo que probablemente no siempre uso términos que me señalen como "teórico". Me parece que el enfoque directo ("por favor dígame los detalles") no siempre funciona, particularmente si el teórico en cuestión ha asumido un tono condescendiente que establece un alto nivel de experiencia (esto sucede a menudo).

Como teóricos, si filtra a las personas de esta manera, ¿tiene recomendaciones sobre cómo un profesional puede evitar ser "marcado" por su filtro?

Puede que esté trabajando con elitistas groseros, pero desde mi experiencia, ser reacio a explicar detalles técnicos depende más del contexto que de la persona con la que estoy hablando. Por lo general, evitaría dar detalles técnicos de una prueba / algoritmo durante el almuerzo o en el corredor, incluso si mi interlocutor fuera el propio Alan Turing. La razón es que los detalles dependen en gran medida de la elección de las anotaciones y de los conceptos artesanales introducidos para suavizar un reclamo. Además, debido a que todos entienden las cosas de manera diferente y no tengo una forma genérica de explicar un concepto, siempre tengo que adaptarme a mi interlocutor (por eso es tan difícil dar detalles técnicos en una presentación de investigación).

Una excepción es si mi interlocutor ha trabajado estrechamente conmigo en este tipo de problema y luego, sé que podemos usar este galimatías común que solo nosotros entendemos porque crecemos juntos después de varias sesiones de pizarra blanca (o antes de una fecha límite urgente) .

Otra excepción es si después de dar un esquema general burdo de la prueba sin detalles, mi interlocutor hace una pregunta precisa que muestra que ha visto una parte difícil de la prueba de que me he estado ocultando intencionalmente para simplificar la presentación. En ese caso, naturalmente abriríamos la caja de Pandora e iríamos juntos al corazón de la prueba, capa por capa ... y generalmente terminaríamos en una pizarra blanca porque en algún momento, nuevamente necesitamos este galimatías común que solo nos queda y este problema

Hay varias moralejas con mi ya larga historia:

• No te deprecies porque no estás trabajando activamente en informática teórica. La mayoría de las personas no se preocuparán por su formación precisa siempre que demuestre que siente curiosidad por su trabajo.
• Cuando las personas son imprecisas acerca de una prueba / concepto, manténgase alerta e intente guiar la conversación haciendo una pregunta precisa que muestre su comprensión y, por lo tanto, ayude a su interlocutor a elegir qué parte de la prueba debe desarrollar primero. Obviamente, esto es bastante difícil e impredecible porque es posible que no pueda hacer comentarios relevantes sobre la marcha (esto le sucede a todos, incluso a los "teóricos"), pero si lo logra, es probable que termine con una discusión muy esclarecedora.
• Incluso los "teóricos" necesitan tiempo para recargar los detalles de una prueba en su cabeza antes de poder explicarlo claramente. Haga una cita pidiéndole explícitamente que esté interesado en los detalles técnicos de X. Esto le dará tiempo a su interlocutor y a usted para prepararse, y facilitará la discusión. Asegúrese de tener una pizarra blanca o una hoja de papel durante la discusión para que realmente pueda entrar en detalles.

Hablando como un teórico que ocasionalmente ha colaborado con investigadores de sistemas, ¡los detalles matemáticos suelen ser lo último de lo que quiero hablar!

Es muy, muy fácil formalizar lo incorrecto, y además de ser una gran pérdida de tiempo, es realmente desalentador. Las matemáticas son una aguja, no un martillo, y cada pinchazo de la aguja es muy costoso. Si estoy hablando con un investigador de sistemas sobre una posible colaboración, antes de llegar a cualquier ceremonia matemática de la alta iglesia, quiero saber:

1. ¿Cuál es el problema que está tratando de resolver y por qué a alguien le importa?
2. ¿Cuáles son las técnicas que utilizan actualmente para atacar este problema?
3. ¿Cuáles son los enfoques alternativos plausibles?
4. ¿Cuáles son las limitaciones de la solución?
5. ¿Cómo llevaron esas restricciones a las elecciones hechas?

Tenga en cuenta que en su mayoría son las mismas cosas que cualquier otro posible colaborador desearía saber, y la razón es que para descubrir una línea de ataque productiva (matemática o de otro tipo) debe tener una idea clara de lo que es importante mantener en un modelo y lo que no es esencial.

Por ejemplo, un investigador de sistemas que colabore con un investigador de HCI tendrá que pasar por el mismo proceso antes de que la persona de HCI pueda diseñar un protocolo experimental útil para hacer un estudio de usuarios: nadie esperaría que se pudiera realizar un experimento que valga la pena sin una buena comprensión. del problema. ¡Debe tener la misma expectativa para el modelado matemático!

Además, casi siempre se da el caso de que, incluso con estas respuestas, la primera ronda es incorrecta, porque muchos de los factores más importantes generalmente viven en el buen gusto y el sentido de ingeniería de la persona con la que estoy hablando. Enseñar y aprender una buena estética es difícil, pero también es por eso que tales colaboraciones valen la pena.

Realmente me gustó la respuesta de Neel, y me inspiró a compartir parte de mi experiencia como teórico, colaborando ocasionalmente con personas más aplicadas. Una de las etapas más difíciles y frustrantes de la colaboración es encontrar un lenguaje común, para que el problema se pueda formalizar correctamente. En mi experiencia, cuando se plantea un problema para un teórico, las personas tienden a dar demasiados detalles irrelevantes. Por ejemplo, si estamos tratando de predecir una serie de tiempo, ¿es realmente necesario pasar 5 minutos diciéndome que estas transacciones financieras están sujetas a las regulaciones que usted quiere aprovechar de tal o cual manera?

Mi sugerencia concreta para hablar con los teóricos: trate de eliminar todos los detalles innecesarios. Si intenta optimizar una ruta de entrega, hable sobre puntos y distancias (en lugar de decirme las direcciones específicas). Al hablar de datos , diga de inmediato cuál es su tipo: cadenas, vectores numéricos, imágenes (¿en qué formato?). ¿Está etiquetado o no? Si es lo primero, ¿cuál es el "tipo" de las etiquetas (binario, multiclase, multilabel, anotación de texto, valor real)?

$d$