¿Qué opinas de una educación en informática donde el profesor de ‘algoritmos y programación’ ni siquiera sabe acerca de la notación Big O?

Deje de lado la probabilidad de que haya formulado la pregunta de manera incorrecta: la notación Big O son algoritmos 101, y me cuesta imaginar que cualquier universidad contrate a un profesor que nunca haya estudiado algoritmos.

Más importante aún, medir la eficiencia de los algoritmos de esa manera es un gran ejercicio en el aula, y ciertamente tiene una serie de aplicaciones en el mundo real, pero NO es el final de la evaluación que debería ocurrir.

El contexto de un código o enfoque particular dicta el grado en que debe preocuparse por la eficiencia de Big O. Ejemplo: tal vez tenga una función que solo recorrerá 100 registros. Además, digamos que el código se ejecuta raramente en relación con otros segmentos de la base del código. Digamos que necesita ordenar una estructura de datos dentro de esa función, que contiene los 100 registros. Cualquier ganancia computacional del enfoque en la eficiencia del algoritmo de clasificación sería insignificante; en cambio, se beneficiaría más de la legibilidad del código, la facilidad de mantenimiento o muchas otras consideraciones pragmáticas que entran en juego al desarrollar aplicaciones.

El punto es que no te obsesiones demasiado con ningún concepto. En el mundo real siempre hay factores competitivos que, tomados en conjunto, dictan el enfoque correcto.

Lo tienes. Con una pregunta capciosa. Serás un gran entrevistador algún día. No te dio la respuesta esperada a una pregunta vagamente formulada.

Por supuesto, él conoce O (), por lo que no preguntaste directamente. Se aplica principalmente a los algoritmos de clasificación. No escribirás nada de eso después de graduarte de … Tengo algunas dificultades aquí. ¿Estás hablando de un profesor universitario? ¿Estás realmente en la universidad? Si es así, eso habla por la “educación en informática”.

FIY la medida real de eficiencia para el programa “a” en el mundo real es el nivel de felicidad de sus clientes. Y el dinero que te hizo. Tu profesor te dio una respuesta 100% correcta. Puedo confirmarlo después de 25 años de mirar “códigos” que funcionaron y no funcionaron. Un programa bien diseñado es el más conciso y minimalista, escrito y mantenido por el menor número de monos de código. No hay otra medida.

Por último, deje de pluralizar la palabra “código”. Apesta a “subcontratación” “offshore”. “Softwares” también.

Big O funciona en algunas situaciones, pero no en todas.

Mi opinión personal es que no criticaría las instrucciones por no saber acerca de “Big O”, ya que esa es solo una técnica entre muchas para determinar la complejidad del software. Y la complejidad no siempre se traduce linealmente en eficiencia (o falta de): hay mucho más por considerar.

En algunas áreas de programación, su instructor sería correcto, pero no en todos. Sospecho que está hablando sobre el tipo específico de codificación que se realiza para sus tareas.

Dependiendo de lo que el software esté tratando de lograr, existen diferentes métodos para determinar la eficiencia. El método más utilizado en mi campo de software (Embedded Systems) es simplemente cronometrar el código usando herramientas de depuración o establecer y borrar un bit GPIO inmediatamente antes y después del área de código que se analiza y examinar el tiempo en un osciloscopio. Busca el momento más desfavorable, luego trata de optimizar el código para la velocidad, luego vuelve a probar el tiempo para ver si has logrado el resultado deseado.

Una vez trabajé en un proyecto de robótica donde la “eficiencia del código” estaba determinada por la cantidad de tiempo para completar un conjunto dado de movimientos. Observé a este robot haciendo lo suyo durante días, tomando notas de cada movimiento que hizo y cuánto tiempo tomaron. En este caso, “Big O” sería inútil … ves mi punto? Por cierto, logré mejorar el rendimiento de ese conjunto de movimientos para satisfacción de mi gerencia, no haciendo que el robot se mueva más rápido, sino encontrando lugares en el código que estaban “perdiendo el tiempo” y optimizando esas áreas.

Mi punto es que “Big O” está lejos de ser el final de determinar la eficiencia del código. Es mejor para ciertos tipos de código e inútil para otros. Es solo una herramienta que se utilizará cuando sea apropiado, y hay más de esas “herramientas” de las que cualquier persona puede memorizar. Lo más probable es que el tipo de código sobre el que está enseñando su instructor se analice mejor para el rendimiento en la forma en que lo indicó.

En función de los detalles de la pregunta, no puedo determinar si el profesor en realidad no conocía la notación O grande, o si solo usó diferentes palabras para responder a su pregunta.

Si su profesor no lo sabe, es un completo idiota y esa escuela es muy sospechosa. Pero es muy poco probable que incluso un profesor incompetente no conozca la notación O grande. Muy, muy poco probable que espere que simplemente lo malinterpretes.

Es perfectamente posible evaluar la eficiencia de un programa observando la cantidad de instrucciones en el bucle interno. Esta no es una mala respuesta. La notación O grande a veces es conveniente, pero de ninguna manera es la única forma de hablar de eficiencia.

Es posible que haya entendido mal lo que su profesor quería decir.

Es posible que haya querido decir la cantidad de instrucciones ejecutadas por un programa en lugar de la cantidad de líneas de instrucciones escritas en código, en cuyo caso es más o menos correcto.

La notación O grande es solo un método para describir qué tan grande es una cantidad en relación con alguna entrada. Al describir el tiempo de ejecución, esencialmente es el número de instrucciones ejecutadas.

No. Eso no es lo que está diciendo 🙂

El número de instrucciones en el código de máquina de un programa. Ahora, hay un elemento de verdad en lo que él está diciendo, pero hay un problema, al cual usted tiene razón para eludir. El número de instrucciones que utiliza un algoritmo solo cubre “un bucle” a través del algoritmo. Si tiene, por ejemplo, una multiplicación regular de una matriz densa, esto creará un algoritmo con complejidad:

[matemáticas] O ([/ matemáticas] [matemáticas] n ^ 3) [/ matemáticas]

Ahora el problema es que esto no se traducirá a las instrucciones [math] n ^ 3 [/ math] en el código de máquina. Lo cubrirá con incrementos / decrementos y ramas (la elección depende de la máquina de destino y la optimización del compilador).

La optimización a nivel de instrucción de máquina individual, cuando se realiza correctamente, ocurre después de la optimización combinatoria (complejidad). La optimización del código de instrucción solo produce un aumento constante o lineal de la velocidad por iteración. Mientras que la optimización combinatoria produce idealmente, la velocidad exponencial aumenta.

Ahora, algunos profesores saben esto porque se especializan en él, otros no. Depende totalmente de su área de investigación. Muchos profesores de HCI que pasaron por la ruta del diseño pueden no conocer la optimización combinatoria. Pero te derrotarán en HCI sin dudas 🙂 Por lo tanto, depende de su especialidad.

La notación O grande no se trata de eficiencia, sino de cómo crece el tiempo y el espacio de cómputo con el tamaño del problema.

Puede aumentar la eficiencia de un programa seleccionando el algoritmo correcto, pero la eficiencia depende de cuánto tiempo real se necesita.

Podría tener código con complejidad O (N ^ 2) que supere el código con complejidad O (N log N) para N≤64 simplemente porque el primero usa significativamente menos ciclos de CPU por paso, o es más amigable con la caché.

Entonces, no, la respuesta de tu profesor no indica que no conozcas la notación Big-O y probablemente solo sea una falta de comunicación.

Se les pide a muchos maestros que enseñen fuera de sus áreas de especialización (tuve una maestra de inglés que sabía menos sobre el idioma que yo, ella era matemática) porque no hay nadie disponible para enseñar en la clase y la maestra no tiene agenda completa.

Juzgar la eficiencia de un programa por el número de líneas en él indica que él era uno de ellos, incluso puede haber tomado un pequeño “curso de un par de horas” en programación. Todo lo que le enseñó, evidentemente, es pensar que sabía de lo que estaba hablando. (La mayoría de los programas de ensamblaje tendrán muchas más líneas de código que un programa Python que hace esencialmente lo mismo, pero será mucho más eficiente . Por ejemplo, el programa Python puede llevar partes de bibliotecas para las que el programa no tiene uso. [Y bit-twiddling es realmente difícil en Python, pero trivial en el ensamblaje, incluso si puede llamarlo tan complejo como ‘trivial’.])

Su pregunta a su profesor fue ambigua ya que la “eficiencia” podría describirse de múltiples maneras. Eligió definir la eficiencia como la cantidad de líneas de código, pero la definición que tenía en mente era la cantidad de ciclos de cómputo requeridos.

Puede escribir muchos “programas” sin algoritmos iterativos. Gran parte del código de la interfaz de usuario simplemente responde a eventos sin iteración, es decir, O (1)

Yo diría que, si bien una interpretación literal de la frase “número de instrucciones en el programa” te deja con una especie de respuesta sospechosa, el “número de instrucciones ejecutadas” es una forma bastante razonable de decirlo. No sería raro comenzar a difuminar la línea entre “instrucciones” e “instrucciones ejecutadas”.

Yendo un paso más allá, apuesto a que probablemente conoce la notación Big O, pero esa es una respuesta menos útil a menos que ya sepas qué es Big O. Big O es solo una abreviatura para describir cuántas instrucciones se ejecutan, a veces describe el recuento en el peor de los casos o en el mejor de los casos.

Su profesor dijo que la eficiencia de un programa se basa en la cantidad de instrucciones y que él es correcto. El número de instrucciones y el número de líneas de código son cosas diferentes muy difíciles. Si escribe un bucle for que itera de 0 a 100 e imprime su índice, entonces realmente solo tiene dos líneas de código, pero tiene 202 instrucciones. Creo que llegaste a la conclusión demasiado rápido como para intentar probar que tu profesor sabe menos que su alumno. Si bien eso es posible, es muy raro y especialmente a nivel de pregrado, suponiendo que es donde estás.

Aunque no es exactamente la respuesta que esperarías escuchar de un profesor de informática, daría un paso atrás y examinaría el contexto en el que hiciste la pregunta.

1. ¿Fue una discusión rápida e informal de preguntas y respuestas con la clase?

2. Tal vez el profesor tenía su mente en otras cosas y solo dio una respuesta a medias.

3. Tal vez si formula la pregunta un poco diferente, como “¿cómo evaluaría la eficiencia de un algoritmo?” (en lugar de un programa) él habría tenido una larga tangente sobre la notación O grande.

Pero aún así … Es un progesor universitario. Esperarías escuchar una respuesta mejor que esa.

“El profesor”? De Verdad? ¿Estás tomando una licenciatura en ciencias donde solo hay un profesor de ciencias de la computación? No, probablemente no.

Todos tienen una especialidad; Lo más probable es que este profesor tenga un área de experiencia que pueda ayudarlo a convertirse en un mejor programador. Aprenda lo que pueda del área de experiencia que tiene cada uno de sus profesores y busque humildad al darse cuenta de lo poco que sabe, en lugar de la superioridad al darse cuenta de que podría saber algo que alguien más no sabe.

Conocer la notación Big O no te convierte en un buen programador.

Supongo que eres un estudiante universitario. Déjame hacerte una pregunta. ¿Qué pensarías de un estudiante universitario que ni siquiera conoce la gramática del inglés?

Bueno, la descripción de su pregunta tiene dos errores gramaticales evidentes que no señalaré por ahora. A pesar de los errores, todavía podía entender lo que intentabas decir, ¿verdad?

No puede esperar que su profesor sepa sobre notación bigO si ni siquiera puede escribir la gramática adecuada. En su lugar, trate de comprender lo que está enseñando y aprenda todo lo demás de otra fuente como Internet.

Con suerte, puedes mirar más allá de mi duro ejemplo y ver lo que estoy tratando de decir. Lo siento si hiero tus sentimientos.

Estoy bastante seguro de que por la cantidad de instrucciones en el programa se refería a la cantidad de instrucciones ejecutadas.

Entonces, el significado que agregaste a sus palabras es incorrecto y no estás siendo caritativo al interpretar sus palabras.

Y a menos que tenga una transcripción de la conversación completa, no podremos saber qué quiso decir exactamente (es posible que esté actualizando una respuesta anterior que le dio en la misma conversación)

De alguna manera, usar o no la notación Big O no es cómo evaluaría la respuesta de su profesor.

Cualquiera que equipare la “eficiencia” con el recuento de líneas tiene deficiencias más fundamentales.

Si consideramos que no hay fallas en la comunicación o malentendidos, entonces tengo un par de comentarios:

1. Creo que “Big O” está realmente sobrevalorado en Quora, algo así como los puntajes de IQ o tocino. Admito que hasta hace un par de años, ni siquiera sabía lo que era, así que lo busqué, y es básicamente una notación de “lo más obvio”. Básicamente, una expresión complicada (para los legos) de “las cosas van más rápido o más lento, dependiendo de lo que esté haciendo”. No es exactamente una revelación. Claro, supongo que un profesor sabrá de qué se trata, supongo, y tal vez lo hizo, pero probablemente nunca lo sabremos.
2. Evaluar la eficiencia por la cantidad de instrucciones en un programa, es simplemente incorrecto. El número de instrucciones no importa, pero sí el número de instrucciones ejecutadas . Incluso entonces, no todas las instrucciones son iguales, algunas se hacen más en un ciclo de reloj que otras, como las instrucciones SIMD, y, por supuesto, el recuento de instrucciones puede no contar toda la historia de las recuperaciones costosas en la memoria.

No estaré de acuerdo con que su combinación de “instrucciones en un programa” sea lo mismo que “líneas de código”, realmente no son lo mismo. Podría escribir 1000 líneas de C y 10 líneas de Python, Python ejecutará muchas más instrucciones debido a la naturaleza de la VM.

Sin embargo, tal vez entendiste mal lo que dijo tu profesor, tal vez no lo hiciste, pero no me preocuparía demasiado que “Big O” no sea algo importante para él.

Si se trata de educación en informática, no puede ser del todo malo. (Por ejemplo, las clases de matemáticas de la escuela a menudo tienen nombres más o menos exagerados). Si este fuera un ejemplo característico, pronto desarrollaría una nube de lluvia personal sobre mi cabeza. Whoa, detalles de la pregunta. ¿Qué ha hecho para confirmar que “mirar el número de instrucciones” no es del todo correcto?

El profesor tiene razón y usted está equivocado.

1 Su respuesta a su vaga pregunta es perfectamente razonable: el número de instrucciones ejecutadas para realizar la tarea es una medida de eficiencia muy sensata.

Menos instrucciones ejecutadas deberían conducir a un tiempo de ejecución más corto.

2 No significa el número de líneas de código.

3 Finalmente, la gran O no tiene nada que ver con la eficiencia: se trata del rendimiento asintótico para entradas arbitrariamente grandes (no es algo que haya pedido).

4 El hecho de confundir la notación Big O y la eficiencia indica un malentendido grave de los dos conceptos.