Una serie cojonuda (y no es porque en ella participen mi padre y sobre todo, mi primo Jorge).

Como la vida misma,  http://www.averlasvenir.es/

32 minutos de metraje, que me han pasado realitavamente cómo 5.

Un ejemplo de cómo con pocos medios y menos actores, puede hacerse una serie mucho mejor que las “profesionales”.

P.D.: ¡QUIERO UN PAPEL! xD Yo tambien tengo mi historia…

Proviene de la idea (fundamental) de que ordenar n elementos de un vector, es equivalente a hacer un “merge” de n vectores ordenados de un elemento (un vector ordenado de un elemento, es un elemento desordenado, lógico).

Por lo tanto lo que hallé es la forma de mezclar n vectores ordenados de forma óptima.

Como estaba convencido de que era una generalización de la búsqueda binaria (ya que es ordenación por comparación), no fué “tan” dificil:

Si quieres mezclar n vectores ordenados en un sólo vector ordenado, tan sólo has de coger el vector central, elegir su elemento central como pivote y situarlo dentro de los vectores que se encuentren en el centro de cada mitad. Pero para eso los elementos de los otros vectores tienen que estar ya situados respecto al resto, es recursivo.

Simplificando, cada elemento ha de buscarse únicamente en dos vectores, uno anterior y uno posterior, de forma recursiva y mediante búsqueda binaria y ¡voilá!

No es aún, el algoritmo de ordenación definitivo, pero se le acerca.

De momento, el algoritmo más rápido  es poco más o menos igual de rápido que Quicksort, pero se debe exclusivamente a la implementación, pues en ambas implementaciones uso o(n log n) memoria auxiliar (un autentico despilfarro).

Está en camino una implementación con un uso de memoría constante (es decir, un algoritmo in-place), pero requiere bastante trabajo. De momento tengo los algoritmo escritos de forma recursiva, pero “conociendo” a los compiladores, más vale que los escriba de forma iterativa a mano.

Creo que la mejor versión será usando el algoritmo de merge que he llamado (muy original) oMerge (de óptimo).

Una vez que tenga ese algoritmo en su versión iterativa, prescindiré de algoritmos auxiliares, y escribiré un algoritmo con una sola recursión, como el de Quicksort. Pero creo que se puede ir más allá y eliminar esa recursión tambien, ya que al contrario que en quicksort, las llamadas recursivas del algoritmo principal no dependen de las anteriores.

Bueno, el que quiera ya puede probar las diferentes velocidades de los diferentes merges. Trastenado un poquito con el código fuente, tambien los tipos de ordenación, pero ya digo que de momento, no he escrito AÚN nada mucho más rápido que mergesort.

Feliz navidad y feliz año ;).

 function Sort (v:vector) return v  

medio:=(v’primero+v’ultimo/2);  

return merge3(sort(v(v’primero..medio-1),v(medio),sort(v(v’medio+1..v’ultimo));

fin 

 Si no fuera por el merge3, sería más corto que Quicksort.En los próximos días lo implementaré, haré unas pruebas a ver si no sólo hace el numero mínimo de comparaciones, si no también es el más rápido (y sino porqué), y luego dejaré estar esto un tiempo, para estudiar (que ya me toca). Llevo dándole vueltas desde marzo del 2007. Si no me sobra tiempo antes, en febrero haré la implementación para el II CUSL.De momento hasta aquí he llegado con la ordenación ;). 

 Demostración a continuación:  

Queremos ordenar con el mínimo de comparaciones posibles N datos, por lo tanto necesitaremos crear un árbol binario de N nodos. Para facilitar la tarea usaremos 7 datos (por forma un árbol binario lleno y perfecto -o árbol completo). 

Supongamos el vector: |1|2|3|4|5|6|7|, vamos a ordenarlo ;). 

 

Sabemos la forma óptima de ordenar tres elementos, de modo que, ordenemos de forma óptima los tres primeros y los tres últimos, para depues ordenar todos juntos.

 

Tenemos  |1|2|3| con dos comparaciones y |5|6|7| con otras dos. Ahora falta ordenar el |4|, si queremos tener el minimo de comparaciones (n-1), por lo tanto, necesitamos comparar el 4 con el 3 y con el 5. PERO, si comparamos primero con el 3 y con el 5, hacemos que el caso peor, necesite , al menos una comparación extra. 

Esto es así porque no hacemos el equivalente a lo que sería una búsqueda binaria para localizar la posición del elemento central en los dos vectores ordenados. Como sabemos que la búsqueda binaria es la forma más rápida de media de buscar un elemento en un vector ordenado, el algoritmo óptimo no podrá ser así.

Por lo tanto el algoritmo óptimo de ordenación por comparación SIEMPRE, hará más de n-1 comparaciones.

 

Después de esto es fácil deducir el algoritmo óptimo, que presentaré en el siguiente post.

 

 

Ya sé que como demostración no es muy rigurosa, ni sigue un modelo formal, pero a partir del ejemplo no debería de ser difícil generalizarla, y no quiero perder el tiempo con algo que ahora veo trivial. 

 v1: |1|2|3|4|5|6|7|8|9|  

v2: |1|2|3|4|5|6|7|8|9| 

v3: |1|2|3|4|5|6|7|8|9|  

Seguimos  comparando centros de vectores, por lo tanto elegiremos el central de los centros como pivote, y empezaremos por comapararlo con los otros dos centros.

Tenemos 5<=5<=5.

Por lo tanto: 

v1: |6|7|8|9|   

v2: |1|2|3|4|5|6|7|8|9|

v3: |1|2|3|4| 

Ahora tenemos 7>5>2, por tanto:

v1:   |6|   

v2: |1|2|3|4|5|6|7|8|9|v3: |3|4|

 6>5>3

v1:  v2: |1|2|3|4|5|6|7|8|9|v3: |4|   

5>4

En resumen, hemos separado los tres vectores en relación a nuestro pivote que era el elemento más central, por ser del que más información se obtiene al compararlo.

Tenemos

|1|2|3|4|5|         |6|7|8|9|

|1|2|3|4|     5     |6|7|8|9|

|1|2|3|4|             |5|6|7|8|9|

Tán sólo nos queda repetir la operación de forma recursiva, y tenemos el mejor merge que haya visto un mergesort, usandolo en lugar del merge tradicional, se reduciría el número de comparaciones y sobre todo el movimiento de datos, al mezclar los vectores de forma óptima de tres en tres.

 Ahora cabe observar, que este merge, que es equivalente a ordenar tres elementos de un vector, sigue exactamente los mismos pasos que haría quicksort con tres elementos. Elige como pivote el elemento central, y lo compara con los otros dos, separando en un casó optimo, los tres elementos ordenados, o en el peor de los casos, separando uno de los datos como menor o mayor y ordenando recursivamente los otros dos datos.Es decir, Quicksort es óptimo para 3 elementos, exactamente lo que buscamos, hace un mínimo de dos comparaciones y un máximo de 3 para ordenarlos.Pero con más de 3 elementos eso ya no es cierto. Si continuamos usando el elemento central como pivote, independientemente de los resultados de la comparaciones, nos encontramos con que si el vector esta ordenado no iremos comparando los elementos contiguos. Esto lleva a quicksort a su peor caso. Si los elementos estan ordenados en orden creciente o decreciente, las comparaciones son O(n^2). Quicksort en un vector ordenado, eligiendo como pivote el elemento central es de O( n log n), pero sigue habiendo un caso de O(n^2), si cada pivote que eliges es máximo o minimo de los restantes elementos. Eso conlleva, que el merge óptimo de 4 vectores deja de ser sencillo.De hecho aún no tengo una idea muy clara de como debe hacerse, he hecho cientos de hipotesis pero en todas he acabado encontrando fallos (con los merges de 2 y 3 tambien me ha pasado, pero esos, creo que ya los tengo solucionados).Esta mañana se me ha ocurrido una idea increible, me ha recordado a Emmett Brown dándose un golpe en la cabeza y viendo de repente el condensador de fluzo. La idea no es tán buena, ya que sigue dejando casos de O(n^2).Puede que sea una chorrada, pero estoy convencido que todos los algoritmos de ordenación “buenos” son algoritmos incompletos, todos tienen partes de uno mejor. Lo que yo busco es que en el caso de que los datos estén ordenados, el algoritmo sólo haga n-1 comparaciones, y que el caso peor se resuelva de la mejor forma posible, así que ¿que tal una mezcla de Quicksort con Mergesort y puede que incluso con un poquito de Bubblesort?Me explico, la idea es elegir un primer pivote, que ha de ser el elemento central, despues se compara este con el siguiente y el anterior, igual que haría un quicksort en su primer paso, pero, la diferencia esta aquí, si esos tres elementos están ordenados (en orden creciente o decreciente), es decir, si ambas comparaciones son iguales, en lugar de seguir comparando, pasaría a haber dos pivotes, uno a cada lado del pivote anterior. Cada pivote iría comprobando que los siguientes elementos siguen el mismo orden, y en el momento que eso ya no sea así, el vector ordenado que hemos obtenido se guardará, para hacer un merge con los vectores ordenados que obtengamos en cada uno de los lados (llamadas recursivas).De momento he estado probando con cuatro elementos y parece óptimo, en el mejor caso son 3 comparaciones y en el peor 5.Esto no es así, porque sigue estando el caso de que el pivote sea máximo o minimo, es decir, el algoritmo sería O(n log n) de media, con O(n) para un vector ordenado, pero con casos “malos” de O(n^2).Recordemos esta lista que contiene los valores conocidos, de la serie del número mínimo de comparaciones para ordenar un vector en el peor caso.

Son: 

| 0 | 1 | 3 | 5 | 7 | 10 | 13 | 16 | 19 | 22 | 26 | 30 | 34 | 38 |

Para:

| 1 | 2 | 3 | 4 | 5 |  6 |  7 |  8 | 9  | 10 | 11 | 12 | 13 | 14 |

Empecemos. Tenemos dos vectores, v1 y v2 

v1: |1|2|3|4|5|6|7|8|9| 

v2:|1|2|3|4|5|6|7|8|9|

Como queremos generalizar la búsqueda binaria, lo que es evidente es que la primera comparación a realizar será comparar los dos centros. 5<=5Tras ello, querremos situar uno de los dos centros comparados dentro del otro vector. La elección igual que con el redondeo en búsqueda binaria, no parece tener mucha importancia. Por las mismas razones que antes, elegiremos el primer centro de los dos.  Este elemento será nuestro pivote, para esta iteración del algoritmo.Por lo tanto:  

v1: |1|2|3|4|5|6|7|8|9| 

v2:|1|2|3|4|

5>2 

v1: |1|2|3|4|5|6|7|8|9| 

v2:|3|4|

5>3

v1: |1|2|3|4|5|6|7|8|9| 

v2:|4|

5>4

Por lo tanto, tenemos la posición del elemento central del primer vector en el segundo. Es decir, hemos separado los datos de la forma siguiente.

|1|2|3|4|   |5|    |6|7|8|9|

|1|2|3|4|            |5|6|7|8|9|

Podemos repetir la operación recursivamente, para los vectores que nos quedan a la izquierda de nuestro pivote por un lado, y para los vectores que nos quedan a la derecha de nuestro pivote por el otro. 

Ya tenemos un algoritmo de merge de dos vectores, óptimo en el número de comparaciones.

Como prueba de que no me equivoco, el numero de comparaciones siempre es igual o inferior al del merge clásico (a+b-1 para dos vectores de tamaño a y b).

Por ejemplo, si buscamos la posición el dato D en el vector V: 

i)                          V= |1|2|3|4|5|6|7|8|9 |                                        D=6 

Nuestra primera comparación será preferentemente 5<=6, ya que  5 es el elemento central del vector.  Así, descartamos las comparaciones con los elementos anteriores al 5 (y con el 5).

ii)                     V1= |6|7|8|9|      D=6 

Al quedar un número par de elementos, podemos elegir entre el redondeo a la izquierda o a al derecha, en terminos de valor medio, ambas elecciones resultan en la misma cantidad de comparaciones, sin embargo, en los computadores, las cachés hacen que en general los accesos secuenciales, de izquierda a derecha sean más rápidos. Aunque puede que eso no suponga una diferencia significativa, lo que es evidente es que no va a resultar peor.Por lo tanto la comparación será 7>6, con lo que descartamos todos los elementos superiores al 7, y el 7.

iii)                    V2= |6|                            D=6 

Comparamos 6<=6, por lo tanto tenemos el vector |6|6| ordenado.Lo juntamos con los “trozos” de vectores que hemos ido descartando, y nos da el resultado  |1|2|3|4|5|6|6|7|8|9 | 

Una pequeña puntualizacion. Esto es cierto porque hemos definido como óptimo, que sea óptimo en comparaciones, si nos saltasemos esa regla, esta misma operación de búsqueda podría hacerse mucho más rápido.La búsqueda binaría hace Log2(n) comparaciones para situar un dato , sin embargo, con una búsqueda interpolatoria lineal, las comparaciones en el caso medio, pasarían a ser log2 log2 (n), mucho más rápido, pero aquí ya no se usa únicamente la operación de comparación, sino también el valor del dato. Creo que el limite estaría en usar una función interpolatoria de todos los datos ordenados, y hayar la posición de forma directa en tiempo constante.Puede que mediante interpolación se puedan ordenar n elementos en O(n), pero eso se sale de mis objetivos actuales, que ya de por si son muy ambiciosos, y requiere una gran habilidad matemática.                         

Este es mucho mayor cuando se han desarrollado métodos desde hace decenas de años. Algunos son muy buenos, pero ninguno es óptimo en función de unos parámetros deseables. Por ejemplo, mi objetivo para el II CUSL es hallar un algoritmo de ordenación por comparación, óptimo en el número de comparaciones. Es decir un algoritmo que ordene N datos, utilizando únicamente la operación “<=” (y en consecuencia “<”, la misma operación negada), y que realice el número mínimo necesario de estas comparaciones entre dos elementos, para garantizar que los n elementos estan ordenados.Resumiendo, si alcanzo mi objetivo, para N elementos cualesquiera, el numero de comparaciones estarán entre N-1 (si todos los elementos estan ordenados) y log2(n!) (en el peor caso, ningún tipo de orden aprovechable), con una suave transición entre los dos limites. Además, también me gustaría (y creo firmemente que es posible) que el algoritmo resultante sea sencillo y con un tiempo de ejecución del orden de O(n log n). Como ilustración el algoritmo más rápido de media, conocido es Quicksort, de C.A.R. Hoare, sólo es óptimo en el número de comparaciones para el caso de elementos completamente desordenados, en el caso medio nunca son óptimas, y en el caso de N elementos ordenados son de N-1+N-2+….+1. Es decir hace entre O(n lo n) comparaciones y O(n^2) comparaciones.El problema de la ordenación parece sin embargo simple; de una entrada de N datos desordenados, proporcionar esos mismos N datos ordenados tal que D1<=D2….Dn-1<=Dn. Surgen varias dudas: ¿Porque no es facil resolverlo de forma óptima? Y mejor aún:¿Si encontramos una forma simple de resolverlo de forma óptima, podrá aplicarse esta para la resolución óptima de otros problemas más complejos?