La mayoría de las matemáticas que he usado es implementar el deslizamiento de pantalla en la versión para tableta del programa de monitoreo de LabVIEW. Estaba implementando las ecuaciones físicas para la amortiguación y la velocidad en código gráfico y funcional, algo como esto:
También hubo un proyecto complicado sobre simulaciones navales en el que estaba trabajando con cuaterniones para colocar cámaras alrededor de un globo simulado, siguiendo barcos.
- ¿Dónde ve la industria de la traducción en diez años?
- Cómo configurar la unidad de desarrollo de software interno en una empresa de consultoría
- Cómo prepararme para ser ingeniero de software en Google sin un título de CS
- ¿Qué debe obtener un desarrollador de software en un plan de reparto de ingresos para desarrollar una aplicación web?
- ¿Hay más dinero para ganar como gerente o como desarrollador?
Sospecho que está haciendo esta pregunta debido a una hipótesis en la línea de “¿los ingenieros realmente necesitan ser buenos en matemáticas?”. He cubierto esto mejor en otra respuesta, pero básicamente, a pesar de que podríamos no realizar ecuaciones difíciles Todos los días, el estilo de pensamiento todavía se siente muy similar.
Un buen ingeniero debe considerar todos los escenarios posibles que puedan surgir y debe escribir un código que demuestre que el código probado podrá manejar tales escenarios. Se requiere una comprensión profunda para saber cómo se puede romper su código; no será suficiente tener una habilidad superficial para lanzar tropos de escenarios de falla comunes.
Leslie Lamport inventó TLA⁺ y lo aplicó al problema de la coherencia de la memoria caché (almacenar un valor de fácil acceso que aún coincide con el valor de acceso lento), reparando un error que había afectado a todo Compaq. TLA⁺ permitió que el software fuera escrito y probado matemáticamente.