Interpreto la pregunta como preguntar por la diferencia en complejidad y comprensión entre el algoritmo tal como aparece en un libro de texto y el algoritmo tal como aparece en el código fuente de un programa.
Una vez que el algoritmo es suficientemente complejo, entonces su implementación no necesita agregar mucha complejidad:
El algoritmo en el libro de texto debe describirse utilizando algún tipo de formalismo. Lo que siempre puedes hacer es construir un intérprete para ese formalismo. Eso le permitirá expresar el algoritmo en su forma original, por lo que realmente no hay complejidad de tener que representarlo en un idioma en particular.
- Cómo mostrar que O (max {f (n), g (n)}) = O (f (n) + g (n))
- ¿Cuál es la forma más fácil de demostrar que si la intersección de 2 rutas es un gráfico conectado, entonces la unión de las 2 rutas tiene al menos un circuito?
- Sistemas distribuidos: ¿es posible utilizar el algoritmo de Paxos para generar números de secuencia (seqnums)?
- ¿Cómo se explica el algoritmo de Metropolis-Hastings en términos simples?
- ¿Qué algoritmo de compresión de imagen se usa en WhatsApp?
Por supuesto, esto significa que debe implementar el intérprete. ¡Pero crucialmente, la complejidad del intérprete no depende de la complejidad del algoritmo ! Entonces, si consideramos algoritmos suficientemente complejos , la complejidad de la sobrecarga del intérprete se vuelve insignificante.
Por supuesto, en la práctica generalmente nos interesan algoritmos mucho más simples en los que incluir un intérprete para un formalismo diferente no sería insignificante (de hecho, para la mayoría de los algoritmos comunes, escribir un intérprete sería más complejo que volver a expresar el algoritmo en un idioma diferente ) En ese caso, realmente depende de qué tan bien coincida la descripción del algoritmo que desea implementar con el lenguaje de computadora en el que lo va a representar.
Tradicionalmente, los algoritmos a menudo se dan en un pseudocódigo que es una mezcla de estilos de programación imperativos, orientados a objetos y, a veces, funcionales. Estos paradigmas son compatibles con la mayoría de los lenguajes modernos, por lo que en tales casos la implementación debe coincidir bastante bien con la descripción original y el programa debe permanecer relativamente razonable y no mucho más tiempo que en la descripción original del algoritmo.
Las cosas se vuelven más difíciles si la descripción original del algoritmo es un diagrama de flujo, porque hay muchos diagramas de flujo simples y naturales que no tienen una representación limpia en los lenguajes imperativos existentes (algo que siempre me ha molestado mucho).
Por supuesto, es aún peor si la descripción original está en código de máquina y tiene que implementarla en un lenguaje funcional puro, o viceversa. En tales casos, la mejor solución puede ser simplemente cambiar a un algoritmo diferente, uno que haga el mismo trabajo pero que sea más fácil de expresar en el idioma de destino.