¿Qué definición de tasa de crecimiento asintótica debemos enseñar?

35

Cuando seguimos los libros de texto estándar, o la tradición, la mayoría de nosotros enseñamos la siguiente definición de notación big-Oh en las primeras clases de una clase de algoritmos: Quizás incluso le demos la lista completa con todos sus cuantificadores:

f=O(g) iff (c>0)(n00)(nn0)(f(n)cg(n)).
  1. f=o(g) iff (c>0)(n00)(nn0)(f(n)cg(n))
  2. f=O(g) iff (c>0)(n00)(nn0)(f(n)cg(n))
  3. f=Θ(g) iff (c>0)(d>0)(n00)(nn0)(dg(n)f(n)cg(n))
  4. f=Ω(g) iff (d>0)(n00)(nn0)(f(n)dg(n))
  5. f=ω(g) iff (d>0)(n00)(nn0)(f(n)dg(n)) .

Sin embargo, dado que estas definiciones no son tan fáciles de trabajar cuando se trata de probar incluso cosas simples como 5nlog4n+nlogn=o(n10/9) , la mayoría de nosotros nos movemos rápidamente para presentar el "truco del límite":

  1. f=o(g) si limnf(n)/g(n) existe y es 0 ,
  2. f=O(g) si limnf(n)/g(n) existe y no es + ,
  3. f=Θ(g) si limnf(n)/g(n) existe y no es ni 0 ni + ,
  4. f=Ω(g) si limnf(n)/g(n) existe y no es 0 ,
  5. f=ω(g) si limnf(n)/g(n) existe y es + .

Mi pregunta es:

¿Sería una gran pérdida para la enseñanza de una clase de algoritmos de pregrado tomar las condiciones límite como las definiciones de o , O , Θ , Ω y ω ? Eso es lo que todos terminamos usando de todos modos y me parece bastante claro que omitir las definiciones del cuantificador facilita la vida de todos.

Me interesaría saber si ha encontrado algún caso natural convincente donde las estándar son realmente necesarias, y si no, si tiene un argumento convincente para mantener las estándar antemano de todos modos.c,n0c,n0

Slimton
fuente
1
La etiqueta realmente debería estar "enseñando", pero no pude encontrar ninguna etiqueta relacionada y no se me permite crear nuevas etiquetas.
slimton
1
Básicamente, esto absorbe los cuantificadores en la definición de límites epsilon-delta. Mi única preocupación sería que muchos estudiantes de CS no hayan realizado un análisis, por lo que su comprensión de los límites es principalmente mecánica. Sin embargo, para permitirles calcular rápidamente, es obvio.
Por Vognsen
66
Tenga en cuenta que sus dos definiciones de O () no son equivalentes (la misma advertencia se aplica a Θ () y Ω ()). Considere el caso donde f (n) = 2n para pares n yf (n) = 1 para n impares. ¿Es f (n) = O (n)? Prefiero usar limsup en lugar de lim para poder decir f (n) = Θ (n) en este caso (aunque ninguna de sus definiciones lo permite). Pero esta puede ser mi preferencia personal (e incluso una práctica no estándar), y nunca he enseñado una clase.
Tsuyoshi Ito
2
@ Tsuyoshi: Pensé que el objetivo del "truco límite" era que era una condición suficiente pero no necesaria para . (Para también es necesario). El contraejemplo de la función oscilante no tiene límite. O()o()
András Salamon
1
¿No debería reemplazar el símbolo por en cada definición y propiedad? Encontré el uso de muy inquietante como estudiante. ==
Jeremy

Respuestas:

13

Prefiero enseñar la definición original con cuantificadores.

En mi opinión, los humanos generalmente tienen problemas para comprender fórmulas y definiciones con más de dos alternancias de cuantificadores directamente. La introducción de nuevos cuantificadores puede aclarar lo que significa la definición. Aquí, los dos últimos cuantificadores solo significan "para todos los n suficientemente grandes", la introducción de este tipo de cuantificación puede ayudar.

Las imágenes que dibujo para explicar estos conceptos coinciden mejor con las versiones cuantificadoras.

Creo que la simplificación del límite es útil para estudiantes de ingeniería que solo están interesados ​​en calcular la tasa de crecimiento, pero no serán tan útiles para los estudiantes de informática. De hecho, usar esta simplificación puede causar más daño que bien.

Esta idea es similar a la sugerencia de que usemos las reglas para calcular derivados (de polinomios, exponenciación, ..., regla de cadena, ...) en lugar de la definición de épsilon-delta, que en mi humilde opinión no es una buena idea.

Kaveh
fuente
La noción de dominación eventual también es útil: iff . Ahora si hay st . \ esits m n > m f ( n ) < g ( n ) f O ( g ) c > 0 f ( x ) c g ( x )f(x)g(x)\esitsmn>mf(n)<g(n)fO(g)c>0f(x)cg(x)
Kaveh
9

Editar: revisión principal en la revisión 3.

Como nunca he enseñado una clase, no creo que pueda reclamar nada convincente sobre lo que deberíamos enseñar. Sin embargo, aquí está lo que pensé al respecto.

Hay ejemplos naturales en los que no se puede aplicar el "truco límite" tal como está escrito. Por ejemplo, suponga que implementa un "vector de longitud variable" (como el vector <T> en C ++) usando una matriz de longitud fija con duplicación de tamaño (es decir, cada vez que está a punto de exceder el tamaño de la matriz, usted reasignar la matriz dos veces más grande que ahora y copiar todos los elementos). El tamaño S ( n ) de la matriz cuando almacenamos n elementos en el vector es la potencia más pequeña de 2 mayor o igual que n . Queremos decir que S ( n ) = O ( n ), pero usar el "truco límite" como está escrito como definición no nos permitiría hacerlo porque S ( n) / n oscila densamente en el rango [1,2). Lo mismo se aplica a Ω () y Θ ().

Como cuestión un tanto separada, cuando usamos estas notaciones para describir la complejidad de un algoritmo, creo que su definición de Ω () a veces es inconveniente (aunque supongo que esa definición es común). Es más conveniente definir que f ( n ) = Ω ( g ( n )) si y solo si limsup f ( n ) / g ( n )> 0. Esto se debe a que algunos problemas son triviales para infinitos valores de n ( como el problema de mecanizado perfecto en un gráfico con un número impar n de vértices). Lo mismo se aplica a Θ () y ω ().

Por lo tanto, personalmente considero que las siguientes definiciones son las más convenientes para describir la complejidad de un algoritmo: para las funciones f , g : ℕ → ℝ > 0 ,

  • f ( n ) = o ( g ( n )) si y solo si limsup f ( n ) / g ( n ) = 0. (Esto es equivalente a lim f ( n ) / g ( n ) = 0.)
  • f ( n ) = O ( g ( n )) si y solo si limsup f ( n ) / g ( n ) <∞.
  • f ( n ) = Θ ( g ( n )) si y solo si 0 <limsup f ( n ) / g ( n ) <∞.
  • f ( n ) = Ω ( g ( n )) si y solo si limsup f ( n ) / g ( n )> 0. (Esto es equivalente a que f ( n ) no es o ( g ( n )).)
  • f ( n ) = ω ( g ( n )) si y solo si limsup f ( n ) / g ( n ) = ∞. (Esto es equivalente a que f ( n ) no es O ( g ( n )).)

o equivalente,

  • f ( n ) = o ( g ( n )) si y solo si para cada c > 0, para n suficientemente grande , f ( n ) ≤ cg ( n ).
  • f ( n ) = O ( g ( n )) si y solo si para algunos c > 0, para n suficientemente grande , f ( n ) ≤ cg ( n ).
  • f ( n ) = Θ ( g ( n )) si y solo si f ( n ) = O ( g ( n )) yf ( n ) = Ω ( g ( n )).
  • f ( n ) = Ω ( g ( n )) si y solo si para algún d > 0, para infinitamente n , f ( n ) ≥ dg ( n ).
  • f ( n ) = ω ( g ( n )) si y solo si por cada d > 0, por infinitamente n , f ( n ) ≥ dg ( n ).

Pero no sé si esta es una práctica común o no. Además, no sé si es adecuado para la enseñanza. El problema es que a veces queremos definir Ω () liminf en su lugar (como lo hizo en la primera definición). Por ejemplo, cuando decimos "La probabilidad de error de este algoritmo aleatorio es 2 −Ω ( n ) ", ¡no queremos decir que la probabilidad de error sea exponencialmente pequeña simplemente para infinitos n !

Tsuyoshi Ito
fuente
También uso las definiciones de limsup, pero para los estudiantes que no han visto limsup (casi todos) tengo que expandirme en cuantificadores explícitos de todos modos.
Jeffε
@JeffE: Estoy de acuerdo en que la mayoría de los estudiantes no han visto limsup, así que si usamos las definiciones de limsup, tenemos que usar cuantificadores en su lugar en clase.
Tsuyoshi Ito
2
El problema con las versiones cuantificadoras es que son difíciles de recordar y visualizar. Prefiero porque se puede describir como "punto límite más alto". Una posible explicación es: "Es como l i m , excepto que l i m solo funciona cuando la secuencia converge. Si la secuencia no converge, por ejemplo porque el algoritmo oscila entre muy rápido para algunos n y lento para otros n , entonces tomamos el punto límite más alto ". limsuplimlimnn
Heinrich Apfelmus
En realidad, ¿hay ejemplos naturales de algoritmos en los que el tiempo de ejecución oscila?
Heinrich Apfelmus
2
@Heinrich: Ya mencioné el tiempo de ejecución de un algoritmo para encontrar una coincidencia perfecta de un gráfico en n vértices, pero ¿cuenta como un ejemplo natural? Agregué otro ejemplo en el que el tiempo de ejecución no oscila pero f (n) / g (n) oscila. El ejemplo habla sobre la complejidad del espacio, pero la complejidad del tiempo del mismo ejemplo tiene la misma propiedad.
Tsuyoshi Ito
8

Usar límites es un poco confuso ya que (1) es una noción más complicada (2) no captura f = O (g) muy bien (como podemos ver en la discusión anterior). Por lo general, hablo de funciones desde los números naturales (estrictamente positivos) hasta los números naturales (que son suficientes para tiempos de ejecución), omito las pequeñas cosas, y luego la definición es concisa y apropiada para los estudiantes de primer año:

Dfn: f = O (g) si para algo de C para todo n tenemos que f (n) <= C * g (n)

Noam
fuente
1
Primero, no me gustó esta definición porque decir "todo n" oculta el hecho importante de que la notación O () solo se preocupa por el comportamiento de las funciones para n grande. Sin embargo, no importa qué definición elijamos, supongo que deberíamos explicar este hecho junto con la definición. Pensando de esa manera, declarar esta definición simple parece bastante bueno.
Tsuyoshi Ito
Si bien esto captura la esencia, no me gusta que si para todos n , g ( n ) = 0 para todos n hasta N 0 , y g ( n ) = f ( n ) + 1 de lo contrario, entonces f = O ( g ) pero esta definición no logra capturar esta relación. Por lo tanto, uno tiene que agregar un saludo manual sobre las funciones que se comportan bien en algún sentido. f(n)=nng(n)=0nN0g(n)=f(n)+1f=O(g)
András Salamon
2
El punto de hablar sobre funciones cuyo rango son los números naturales (sin incluir 0) es exactamente no caer en problemas con g (n) = 0.
Noam
1
@Warren Victor Shoup en su libro sobre Teoría de números computacionales usa la notación lugar de registrar un análisis de tiempo de ejecución, lo cual me pareció ordenado. len(a)loga
Srivatsan Narayanan
1
@Warren (continuación) Así es como lo explica: "Al expresar los tiempos de ejecución de los algoritmos en términos de una entrada , generalmente preferimos escribir l e n ( a ) en lugar de registrar a . Una razón es estética: escribir l e n ( un ) hace hincapié en el hecho de que el tiempo de ejecución es una función de la longitud de bits de un Otra razón es técnica:. para BIG- S estimaciones implican funciones de un dominio arbitrario, las desigualdades adecuadas deben mantener en todo el dominio, y por Por esta razón, es muy inconveniente usar funciones, como logalen(a)logalen(a)aOlog, que desaparecen o no están definidos en alguna entrada ".
Srivatsan Narayanan
5

Cuando tomé cursos básicos, nos dieron la cosa como definición y las otras cosas como teorema.do,norte0 0...

Creo que el primero es más natural para muchas personas que piensan discreto en lugar de continuo, es decir, la mayoría de los informáticos (en mi experiencia). También se ajusta mejor a la forma en que generalmente hablamos de esas cosas: "Hay una función polinomial de grado 3 que es un límite superior para esta hasta un factor constante".F

fO(g):⇔c,d>0n0:f(n)cg(n)+dd=f(n0)

El límite es bastante útil para calcular clases de complejidad, es decir, con lápiz y papel.

En cualquier caso, creo que es muy útil que los estudiantes aprendan que hay una gran cantidad de (con suerte) definiciones equivalentes. Deberían poder darse cuenta de eso y distinguir las diferencias en caso de definiciones no equivalentes.

Rafael
fuente
4

Habiendo estudiado estos conceptos hace solo unos años, no fueron los más difíciles de entender para mi clase (a diferencia de conceptos como inducción o contra positivos). Límites y limsups son solo más "intuitivos" para aquellos familiarizados con el cálculo en mi opinión. Pero los estudiantes con una base matemática de este tipo tendrán antecedentes teóricos establecidos de todos modos, para que puedan procesar calificadores discretos.

Además, lo que es más importante, recuerde que, en última instancia, sus alumnos continuarán (con suerte) para leer otros libros de texto de teoría de cs, y tal vez incluso algún día de investigación. Como tal, es mejor que se sientan cómodos con la notación estándar en el campo, incluso si inicialmente no se concibió idealmente. No tiene nada de malo darles definiciones alternativas también, una vez que hayan asimilado las estándar.

Amir
fuente
3

Para una versión interesante del tema, mire la carta bien escrita de Don Knuth "Cálculo vía notación O" . Él defiende la opinión inversa de que el cálculo debe enseñarse a través de las anotaciones 'A', 'O' y 'o'.

xAyx=A(y)|x|y100A(200)

Srivatsan Narayanan
fuente
1
  1. Las definiciones de Tsuyoshi Ito no se ven del todo bien. Para little-omega y big-omega, las definiciones deben usar liminf, no limsup. La definición de big-theta necesita un límite inferior en liminf y un límite superior en limsup.

  2. Una definición de f (n) = O (g (n)) es que existe otra función f '(n)> = f (n) tal que lim f' (n) / g (n) <infinito.

  3. ¿Por qué se permite a los novatos publicar respuestas pero no hacer comentarios?

Warren Schudy
fuente
1
En cuanto al ítem 1, me refiero a limsup en todos los casos, y la razón se explica en el segundo párrafo de mi respuesta.
Tsuyoshi Ito
Desafortunadamente, es un mecanismo de bloqueo de spam.
Suresh Venkat
Además, puedes usar látex en tus respuestas.
Suresh Venkat
1

Primero , trato de desarrollar en los estudiantes cierta intuición , antes de mostrar ecuaciones.

  • "Combinar-ordenar vs Insertar-Ordenar" es un buen punto de partida.

f=O(g) iff (c>0)(n00)(nn0)(f(n)cg(n)).
limn

Otro aspecto es que depende en gran medida del programa de estudios concretos. En mi humilde opinión, dependiendo de los temas anteriores, una de las definiciones será más adecuada, mientras que en mi humilde opinión, es una buena idea mostrar ambos y aceptar ambos tipos de soluciones.

Grzegorz Wierzowiecki
fuente