Esto varía de persona a persona, día a día, problema a problema.
En mi investigación, generalmente me guío por la intuición y los ejemplos. Tengo la sensación de cómo deberían ir las cosas, y eso proviene de una mezcla de experiencia y sensibilidad estética. Esbozaré los términos que tendré que definir, los principales teoremas que tendré que probar y los lemas y las proposiciones que espero probar en el camino. También puedo indicar ejemplos clave y comentarios notables.
Para una primera aproximación, el resultado es un trabajo matemático con todas las pruebas y toda la exposición omitida o esbozada. A menudo, ayuda establecer aproximadamente un teorema antes de comprometerse con definiciones particulares de los objetos en la declaración del teorema.
A medida que desarrollo mis ideas, las valido periódicamente
- ¿Están de acuerdo los matemáticos en que las matemáticas del cambio climático pueden haber malinterpretado la contribución del carbono?
- Matemáticos, ¿cómo haces para resolver problemas matemáticos?
- ¿Cuáles son los datos interesantes sobre los matemáticos?
- ¿Qué piensan los matemáticos / físicos de la crítica de Bill Gaede de la física matemática?
- ¿Cómo crearon los nativos americanos movimientos de tierra geométricos con precisión astronómica sin matemáticas escritas?
- comprobando los ejemplos que conozco y
- demostrando resultados parciales en el camino.
Probar cada paso en el camino generalmente ralentiza las cosas hasta el punto de que no es divertido. También puede perderse en los árboles, olvidando todo sobre el bosque.
Esto es muy análogo a lo que siento al comenzar un nuevo proyecto de software de mediano a grande. Cualquier persona con la que haya trabajado en software le dirá que soy un gran defensor de la documentación, los comentarios y las pruebas. Pero esas cosas rara vez entran en el primer borrador, al menos al principio. Prefiero esbozar las firmas e interfaces de funciones, estableciendo el código de andamiaje que organiza el proyecto en general. Luego puedo leer el resultado como un esquema y reorganizarlo hasta que me guste lo que tengo. (Para ser claros, al menos cuando estoy en el trabajo, ¡agregaré pruebas antes de enviar mi código a un repositorio compartido!)
Hay un punto que debo enfatizar aquí: el enfoque descrito anteriormente, tanto para matemáticas como para ingeniería de software, ¡solo funciona si eres sólido con lo básico! Si omite la prueba de un lema, es útil estar razonablemente seguro de que uno de los siguientes es cierto:
- El lema es cierto, y puedes probarlo sin demasiados problemas.
- El lema es verdadero “en espíritu”, pero no literalmente. Tendrá que cambiar algunas hipótesis, posiblemente refactorizando su lógica un poco, pero no invalidará su enfoque general.
Y análogamente en ingeniería, con “lema” reemplazado por “función” o “clase” o “módulo”, y “probar” reemplazado por “implemento”. Esto no funcionará el 100% del tiempo (ver, por ejemplo, la prueba original de Andrew Wiles del último teorema de Fermat / la conjetura de Tanimaya-Shimura-Weil), pero probablemente debería funcionar el 90% del tiempo.