![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
#11
|
||||
|
||||
|
Cita:
Pues no comprendo tu punto. Aún siendo, y con más razón, pocos los elementos del TListBox es por lejos más preferible un simple recorrido. Lo lógico sería pensar al revés: cuanto más elementos, convendría ordenar. ¿Para que ordenar, pocos elementos? ¿Aporta en algo? En realidad, no hay beneficio alguno. Si asumiéramos que la máquina es perfecta y tuviera siempre un valor de factor c constante, aplicar un ordenamiento consume O(n), mientras que con QuickSort en el mejor caso O(n * log n). Si hacemos cálculos, que para simplificar c = 1: n = 10 => O(n) = 10, O(n * log n) = 10. Dif = 0 n = 100 => O(n) = 100, O(n * log n) = 200. Dif = 100 n = 1000 => O(n) = 1000, O(n * log n) = 3000. Dif = 2000 Con n menores a 10 se aprecia mejor mi planteo: n = 5 => O(n) = 5, O(n * log n) = 3,49. Dif = 1,51 n = 2 => O(n) = 2, O(n * log n) = 0,60. Dif = 1,4 n = 1 => O(n) = 1, O(n * log n) = 0. Dif = 1 No se "gana" demasiado cuando más chico sea ¿O no? . Y como quedó demostrado, cuando mayor sea la lista más conveniente es el recorrido. Esto demuestra que para pocos elementos se peca demasiado en esforzarse ordenarlos. Incluso alguien se podría llegar a pensar que para el caso, para pocos elementos podríamos aprovechar burbuja mejorado. Ufff... ¡peor! Éste es O(n^2). Si me explicas mejor tu punto... Saludos, |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| consultar el maximo valor | beatriz g | SQL | 4 | 16-08-2006 17:35:53 |
| width con valor mínimo | edusus | Varios | 1 | 02-04-2006 11:58:11 |
| 2 SubConsultas con Maximo y Minimo | AGAG4 | SQL | 18 | 03-09-2004 21:34:03 |
| Minimo y Maximo en un campo DATETIME y Consulta OnTimer | bustio | SQL | 2 | 08-06-2004 07:27:57 |
| consulta con Valor maximo | isc_hilda | SQL | 3 | 29-04-2004 22:17:20 |
|