Unidad 4: Análisis de algoritmos (parte II) Bloque 1: Introducción Unidad 4: Análisis de algoritmos (parte II)

En general, distinguiremos cuatro casos Introducción En esta parte de la unidad didáctica, se determinará tipo de análisis es conveniente realizar, esto es, desde qué punto de vista deseamos conocer una determinada propiedad del algoritmo En general, distinguiremos cuatro casos Análisis para todos los casos Análisis para el caso mejor Análisis para el caso medio Análisis para el caso peor

Análisis para todos los casos Este tipo de análisis es el que se realiza cuando todos las instancias del problema que resuelve el algoritmo poseen la misma función de complejidad No todos los algoritmos pueden analizarse desde este punto de vista Cuando es posible, los restantes tipos de análisis no son aplicables Por ejemplo: function factorialIter(n:integer):integer; VAR i, res: integer; BEGIN res:= 1; for i:= 1 to n do res:= res * i; factorialIter:= res END; Operación básica tn=n para todos los casos

Análisis para el caso mejor/medio/peor Los análisis de Caso mejor Caso medio Caso peor Pueden realizarse cuando instancias distintas de un mismo problema pueden poseer funciones de complejidad distintas Por ejemplo: function busquedaLineal(a:array[1..n] of integer; x:integer):integer; var i:integer; begin i := 1; while i <= n and a[i] <> x do i:= i+1; if i > n then busquedaLineal:= 0 else busquedaLineal:= i end; ¿Qué ocurre si: a[1] = x a[n/2] = x a[n] = x x no está en a?

Análisis para el caso mejor/medio/peor Los tres tipos de análisis son relevantes: Por ejemplo, dados dos algoritmos a1 y a2, con funciones de complejidad para los casos medio y peor similares (en el mismo orden), pero donde tn(a1) es de menor orden que tn(a2) para el caso mejor, a1 será preferible Para los casos mejores, a1 termina más rápidamente Similares razonamientos se pueden realizar con otras combinaciones de cm, cmd y cp Realizado cuidadosamente, el cmd es la función de complejidad más realista Desde un punto de vista pesimista, el análisis del caso peor es el preferible

Análisis para el caso mejor Consiste en determinar las funciones de complejidad para las instancias del problema más favorables Depende (como en el resto de los casos) del problema particular Ejemplo: No acostumbra a ser realista, y es poco utilizado function busquedaLineal(a:array[1..n] of integer; x:integer):integer; var i:integer; begin i := 1; while i <= n and a[i] <> x do i:= i+1; if i > n then busquedaLineal:= 0 else busquedaLineal:= i end; Si a[1] = x, entonces tbn = 1

Análisis para el caso medio Consiste en determinar las funciones de complejidad para las instancias típicas del problema Es difícil determinar la tipicidad Hace usos de conceptos (aunque básicos) de probabilidad Ejemplo: function busquedaLineal(a:array[1..n] of integer; x:integer):integer; var i:integer; begin i := 1; while i <= n and a[i] <> x do i:= i+1; if i > n then busquedaLineal:= 0 else busquedaLineal:= i end; ¿Cuáles son los valores típicos de a y x?

Análisis para el caso medio (Ejemplo) Valores de entrada: a puede ser un vector cualquiera de longitud n Supongamos que no se repiten valores x puede ser cualquier valor Supongamos que x está incluido en a ¿ Qué probabilidad existe de que a[i] = x ? P(a[i] = x) = 1/n ¿ Cuál es la función de complejidad ? Viene dada por la suma de las probabilidades individuales, o lo que es lo mismo, P(a[1] = x) + P(a[2] = x) + ... + P(a[n] = x)

Análisis para el caso peor Consiste en determinar las funciones de complejidad para las instancias del problema más desfavorables Recorrer todo el array en el caso de búsqueda Que el array esté ordenado de forma inversa en un algoritmo de ordenación Etc. Esto es, lo que lleve más tiempo, y más iteracciones, realizar Es el tipo de análisis que realizamos habitualmente, ya que proporciona un límite superior a la complejidad del algoritmo Nunca empleará más tiempo que el del caso peor

Notas finales: Análisis amortizado En algunos casos, el análisis de caso peor (el habitualmente realizado) es excesivamente pesimista, aunque válido como límite superior Por ejemplo, supóngase: donde la complejidad (caso peor) de p() es tk(p) Entonces, es lógico suponer que tnk(bucle) = n* tk(p) Si n=k, entonces tn(bucle) = n* tn(p) i:= 1; while i <= n do begin p(); i:= i+1 end;

Notas finales: Análisis amortizado No obstante, aunque tk(p) puede ser razonable como límite superior (esto es, p() tiene una complejidad O(tk(p)), puede ocurrir que, considerando una sub- secuencia de invocaciones a p(), el tiempo empleado esté acotado superiormente por una constante Ello no implica que p()no realice en ciertas ocasiones tk(p) operaciones Un ejemplo: suponer p()la siguiente función procedure count(var C:array[1..m] of integer); {C[i]=0 ó 1 para todo i} var j:1..m; begin j:= m+1; repeat j:= j-1; C[j]:= 1 - C[j] until C[j]=1 or j=1; end; Es O(m) ???

Notas finales: Análisis amortizado Contador Iteraciones en el bucle repeat Estado inicial del vector (no entra en cuentas) 1 2 3 ... Existe un claro patrón; el número de iteracciones a través del bucle repeat depende de donde esté situado el último 0 (considerando igualmente el tamaño del vector), y no del valor de m

Notas finales: Análisis amortizado El algoritmo está claramente en el orden de n

Notas finales: Análisis amortizado Formalmente, para realizar un análisis amortizado, se necesita una función potencial i: La función  representa el incremento “de potencial” que las sucesivas invocaciones procedimentales producen i representa el “potencial” de la función tras la i-ésima llamada n >= 0 para todo n Pensadlo en sentido físico n i 0 n

Notas finales: Análisis amortizado Se define el tiempo amortizado como: donde ti es el tiempo (o numero de veces que se ejecuta la operación básica) en la i-ésima llamada a la función ti representa el tiempo requerido para llevar a cabo la i- ésima llamada a la función más el incremento de potencial Este incremento de potencial permite obviar el caso peor, esto es, cuando la función tarda un tiempo en el orden de m Se puede probar que Esto es, Tn está acotado superiormente por Tn

Notas finales: Análisis amortizado El problema es habitualmente identificar la función potencial adecuada Para el ejemplo que manejamos, una función potencial adecuada podría ser... Numero de ceros ?  no cumple que sea creciente. De hecho, es decreciente Numero de unos ?  más razonable, ya que es creciente y n >= 0 para todo n Análisis: Caso 111111...  el potencial cae a 0 (incremento de –m) después de m iteracciones. Por lo tanto, el tiempo amortizado es 0 Otros casos  avanzamos realizamos k iteracciones, pasando k-1 unos a ceros y un cero a uno. El incremento en potencial es, por lo tanto, -(k-2), y el tiempo amortizado es igual a k-(k-2) = 2 Después de n llamadas, Tn = 2*n

Notas finales: Análisis amortizado Después de n llamadas (supongamos que n = 2m) hemos realizado n-1 llamadas a coste amortizado 2 1 llamada a coste amortizado 0 El efecto de esta última llamada se diluye asintóticamente, dependiendo de los valores de n y m (ver gráfica) Podemos suponer, por lo tanto, que: Y dado que Tn está acotado superiormente por Tn, sabemos que O(p())=2n = n

Notas finales: Análisis amortizado Una alternativa, cuando la identificación de la función potencial y los son difíciles de calcular, es aplicar un enfoque empírico o, alternativamente, jugar con un almacén de tokens