Comments on: Más sobre la cota log(n!).

By: azrael

azrael — Sat, 09 Jun 2007 18:59:54 +0000

Gracias por responder. A ver si consigo algo tangible.
De momento estoy convencido de que lo más rápido que se puede hacer es parecido a “ordenar mínimos”, “ordenar máximos”, repetir con el resto y mezclar. El problema es que un merge ahí suele hacer más comparaciones de las necesarias, y que para que sea óptimo de verdad ha de ordenar un vector en el que el único elemento desordenado sea el último en n-1+log(n-2) y no en n-1 + n-2.
Le estoy dando vueltas a algoritmos en los que se comparen de forma recurrente los terminos medios entre máximos y minimos puntuales.

By: javifields

javifields — Sat, 02 Jun 2007 20:27:54 +0000

no investigo en algoritmia, pero no creo que se pueda bajar el coste promedio de ordenación más abajo de nlogn; y sobre lo de algoritmo óptimo en nº de comparaciones, la verdad es que no recuerdo si hay muchas diferencias con el nº de movimientos, pero no lo creo

By: azrael

azrael — Sat, 02 Jun 2007 16:25:29 +0000

Tienes razón, me refería al coste de la busqueda en comparaciones, el otro depende de la estructura de datos utilizada. Vamos, creo :P.
A lo que me refiero es en realidad más bien un árbol binario de búsqueda.
¿Estás de acuerdo en que el coste promedio de un algoritmo de ordenación óptimo pudiera ser ligeramente inferior a n log n?
Y esta es más complicada ¿Se te ocurre como hallar un algoritmo de ordenación óptimo en el numero de comparaciones?

P.D.: Pese a alguna inexactitud, lo que quería en este post, es demostrar que “viendo todo el vector” se puede ordenar más rápido que “viendo los elementos uno por uno”.

By: javifields

javifields — Fri, 01 Jun 2007 14:46:22 +0000

puntualizo: “A la hora de añadir un elemento a un vector ordenado, es evidente que el coste óptimo es log(n)”
no! ese coste es el de buscar la posición de inserción, luego hay que “hacer hueco” en el vector para añadir el elemento y eso tiene coste lineal en el caso peor