Permítanme sugerir que la programación y las matemáticas están tan relacionadas como la ingeniería y la ciencia. Es decir que la informática trata con maquinaciones simbólicas concretas y las matemáticas trata con maquinaciones simbólicas más abstractas. No son lo mismo, pero están estrechamente relacionados. Así que ciertamente, a menos que esté operando en un nivel superior a la “programación” (un término problemático) diseñando interfaces de usuario utilizando un generador de GUI, etc., o de alguna manera haciendo mantenimiento de TI sin tener que escribir scripts, tendrá que hacer algo similar para el pensamiento matemático, tendrá que al menos abstraer de los modelos y procesos dentro de un sistema de software algún modelo utilizable en su cabeza desde el cual pueda generar programas.
Pero hay dos rayos de esperanza que quiero ofrecer aquí. Soy ingeniero de software y no me considero matemático, y no tengo una sólida formación en matemáticas (hice matemática en el nivel “A” / nivel de secundaria y matemática en el primer año de pregrado en física y matemática discreta como parte de mi título de CS) no ha sido un obstáculo. Los rayos de esperanza son
a) las matemáticas no son necesariamente lo que piensas que es
- ¿Cuáles son las formas o tipos de problemas en los que XOR es útil?
- ¿Qué módulo será más útil, análisis multivariado o análisis bayesiano?
- ¿Cuál es una explicación simple pero detallada de Textrank?
- ¿Qué otras cosas debo probar aparte de programar o codificar?
- ¿Cuál es la explicación rigurosa de por qué n / m es el factor de carga en una tabla hash?
b) lo que hace que un buen programador sea la capacidad de aceptar y dominar reglas arbitrarias.
Tomemos el último primero. Hay un documento que detalla la investigación realizada por Saeed Dehnadi y Middlesex U y sus colegas del departamento de informática que enseñé en el Queen Mary College, UL, que muestra que lo que predice el éxito a nivel de pregrado no es la habilidad matemática, sino la habilidad de comprender, aceptar y aplicar las reglas arbitrarias de los lenguajes de programación. Entre los sujetos de prueba de sus alumnos, identificaron tres grupos, aquellos que no obtuvieron la matemática o la manipulación de símbolos y simplemente no podían programar, aquellos que eran fuertes en matemáticas y encontraron que las diferencias entre las matemáticas y la programación simplemente eran demasiado disonantes para aceptar, y aquellos que tomó las reglas al pie de la letra y se fue con ellas.
Recuerdo que mi nuevo amigo Ian Kinns me contó cuando caminábamos a la escuela a los 14 años sobre BASIC, y el primer punto importante fue que me dijo que podía escribir x = x + 1, lo que para mí no tenía sentido. Me tomó más de unos minutos obtener que ‘=’ no significaba ‘es igual a’, y que ‘x’ denotaba una ubicación de almacenamiento, no una variable algebraica.
Entonces, si puede tratar las reglas de programación como perfectamente válidas y funcionales por sí mismas, no encontrará problemas de programación.
Pero creo que mucho más interesante es que las matemáticas no son lo que la gente tradicionalmente considera matemáticas. Sugiero que gran parte de lo que creemos que las matemáticas son la manipulación de símbolos al servicio de la construcción de pruebas, una tarea que cada vez más se deja a las computadoras, ya que es tediosa y propensa a errores, aburrida y no es lo que hacen los matemáticos reales.
Permítanme ilustrar con tres ejemplos. Aquí hay un rompecabezas. Imagine un tablero de ajedrez del que se han eliminado dos cuadrados en las esquinas opuestas. Eso deja un tablero de ajedrez incompleto con 62 casillas. Tienes 31 fichas de dominó, cada una del tamaño de dos cuadrados. ¿Puedes enlosar completamente el tablero cuadrado 62 con tus 31 fichas de dominó de dos cuadrados? Intenta y construye una prueba. Daré la respuesta al final de esta publicación. No te desplaces hasta el final; piense en el fondo mientras sigue leyendo.
El ejemplo dos es el teorema de Pitágoras. Recuerdo que me presentaron una prueba algebraica de que me resultaba incomprensible en la clase de matemáticas de nivel O (escuela primaria). Luego, muchos años después, vi a Alan Kay presentar una prueba geométrica fabulosamente clara y comprensible. Aquí hay un video de la prueba. Encantador. Apuesto a que así es como Pitágoras se le ocurrió la idea en primer lugar, y que todas las pruebas posteriores son una racionalización post hoc diseñada para torturar a los seres humanos en las clases de matemáticas.
El ejemplo tres fue un lanzamiento encantador para mí. Había cursado un año de licenciatura en física y recuerdo haber encontrado la doble integral del análisis de Fourier incomprensiblemente intimidante. El análisis de Fourier determina los componentes de frecuencia presentes en una función arbitraria. Muy poderoso, muy útil. Pero la presentación algebraica en Imperial en el primer año de física voló sobre mi cabeza. Un día en QMC, donde ahora enseñaba programación, estaba almorzando en la cafetería con uno de mis estudiantes de maestría y expresé mi frustración con el análisis de Fourier y mi estudiante [si estás leyendo esto, ponte en contacto, nunca he olvidado este día] explicó cómo funcionaba.
Primero, necesitamos saber que cualquier función puede expresarse como una suma de ondas desde. Una prueba de esto es que podemos construir una función delta a partir de ondas sinusoidales. Si tengo dos ondas sinusoidales separadas infinitamente en frecuencia y en fase en 0, interferirán constructivamente en 0 e interferirán destructivamente en el infinito. Continúe agregando más frecuencias (dividiendo por el número de frecuencias que agregamos para mantener la suma en cero a, digamos, 1) y obtenemos más interferencia constructiva en 0 y más interferencia destructiva en otros lugares. Con una extensión infinita de frecuencias obtenemos la función delta, algo con un valor distinto de cero en cualquier otro lugar. Combina muchas funciones delta y puedes generar cualquier función. No es muy satisfactorio, pero crudamente funciona.
Ahora piense en el producto de dos ondas sinusoidales (vea la sección “Dos ondas sinusoidales con diferentes frecuencias: latidos”) de diferentes frecuencias y el producto de dos de la misma frecuencia. Si las frecuencias son diferentes, obtenemos latidos, aún periódicos, pero cruzando cero. Si las frecuencias son las mismas, obtenemos una onda senoidal cuadrada, por lo que esto siempre es positivo ya que -n * -n = n * n. Entonces, si integra (encuentra el área debajo de la curva) de la onda sinusoidal cuadrada, comenzando en 0 y avanzando hacia el infinito, la integral aumentará porque la curva siempre está por encima de cero, pero la integral de la curva de los latidos irá ligeramente positivo y luego de vuelta a cero, etc., ya que los latidos aún cruzan cero. Entonces, si dividimos la integral por el rango en el que nos integramos, la integral de frecuencia de latido tiende a cero a medida que alcanzamos el infinito y la integral de seno cuadrado tiende a una constante.
Entonces, si multiplicamos todas las ondas sinusoidales que componen alguna función por una onda sinusoidal de referencia, e integramos cada uno de esos productos y dividimos por el rango, obtenemos un valor distinto de cero solo si hay una componente de onda sinusoidal en la función que es la misma frecuencia que nuestra onda de referencia. Entonces, para descubrir todos los componentes de una función, realizamos este proceso con una extensión infinita de frecuencias. Ahora la doble integral tiene sentido.
Entonces, ¿la respuesta al tablero de ajedrez? Bueno, los tableros de ajedrez son tableros de cuadros, y si visualizas el tablero en tu cabeza verás que las esquinas opuestas del tablero tienen el mismo color, ya sea negro o blanco. Las esquinas adyacentes tienen el mismo color; las esquinas opuestas difieren. Por lo tanto, habrá 32 cuadrados negros y 30 blancos, o 30 cuadrados negros y 32 blancos en nuestro tablero modificado. Dado que un dominó de dos cuadrados siempre cubre dos cuadrados de diferentes colores, es imposible enlosar el tablero con los 31 dominós.
En todos estos ejemplos entendemos construir una prueba usando nuestra capacidad de visualizar, internalizar algo en forma de modelo manipulable, algo que los pensadores visuales como yo hacemos. No puedo hacer lo algebraico, pero puedo manipular estructuras abstractas en mi cabeza como si fueran concretas. Y esa habilidad funciona tanto para la programación como para las matemáticas. He trabajado con personas que no piensan así, que son pensadores lingüísticos, y todavía no entiendo cómo hacen lo que hacen. Pero sé que la capacidad de manipular modelos geométricos abstractos en tu cabeza es una gran habilidad para tener como arquitecto de software. Y, aunque lo que he dado aquí es anecdótico, sospecho que gran parte de lo que hacen los matemáticos es lo mismo, y las pruebas algebraicas son racionalizaciones post hoc que se usan para denotar esas pruebas y que una habilidad necesaria es hacer un mapeo del álgebra de regreso a algo uno puede manipular en la cabeza algo más que una simple cadena de fichas.
