Máximo o mínimo valor en un listbox

[Neftali [Germán.Estévez]]

Empezado por roman

Quizá no necesite un StringList

Por supuesto, si puede ordenarlo.
Tal vez hemos "asumido" equivocadamente que no podía hacerlo directamente con el control.

[[fjcg02]]

Efectivamente, si puede cambiar el orden de los elementos del objeto, se ahorra unas cuantas líneas de código...

[[Delphius]]

Si los requisitos indican que los elementos del TListBox van a estar ordenados, obtener el máximo y el mínimo se convierte en una operación elemental como bien lo apunta roman.

Ahora bien, forzar una ordenación para hacer este proceso elemental es un desperdicio.
En primer lugar no hace falta ordenar para extraer el máximo y/o el mínimo, basta con recorrer la lista y evaluar.
En segundo lugar, aún utilizando un algoritmo de ordenamiento tan rápido como QuickSort es un proceso lento comparado con un simple recorrido. QuickSort tiene en promedio una complejidad O(n * log n) mientras que un recorrido SIEMPRE es O(n).
Y aún utilizando algoritmos más avanzados que QuickSort, si fueran aplicables y viables a las necesidades, como TimSort que tiene una complejidad O(n) sigue siendo un desperdicio.

A menos que exista una verdadera necesidad de contar con los datos ordenados, es mucho más barato lanzar un for y evaluar máximo y mínimo.

Saludos,

[[fjcg02]]

La verdad es que es aplastante la respuesta que ofreces, Delphius, y no admite duda.

Pero haciendo un pequeño ejercicio de coste/beneficio, y teniendo en cuenta que si se trata de un listbox no debería tener demasiados elementos... me atrevería a decir que en este caso nos cuesta más la salsa que la perdiz. Y que conste que tu respuesta es "la respuesta".

Un saludo "ordenado"

[roman]

Estoy de acuerdo con Delphius, es más eficiente el recorrido simple. Además, quizá la perdiz no es tan cara (*):

Código Delphi [-]
var
  MinMax, Val: TPoint;
  I: Integer;

begin
  MinMax := Point(MaxInt, -MaxInt);

  with ListBox1 do
    for I := 0 to Count - 1 do
    begin
      Val := Point(StrToIntDef(Items[i], MaxInt), StrToIntDef(Items[i], -MaxInt));

      if Val.X < MinMax.X then MinMax.X := Val.X;
      if Val.Y > MinMax.Y then MinMax.Y := Val.Y;
    end;

  ShowMessage(Format('Min: %d, Max: %d', [MinMax.X, MinMax.Y]));
end;

// Saludos

-----
(*) En México decimos que es más caro el caldo que las albóndigas

[[Delphius]]

Empezado por fjcg02

La verdad es que es aplastante la respuesta que ofreces, Delphius, y no admite duda.

Pero haciendo un pequeño ejercicio de coste/beneficio, y teniendo en cuenta que si se trata de un listbox no debería tener demasiados elementos... me atrevería a decir que en este caso nos cuesta más la salsa que la perdiz. Y que conste que tu respuesta es "la respuesta".

Un saludo "ordenado"

Hola, fjcg02.
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,

[[fjcg02]]

Delphius, veo que no me pillas el punto...

En definitiva, si puedo escribir una línea de código, mejor que dos, siempre y cuando el rendimiento no penalice al usuario. Es que cuando uno es vago, es vago .... sin más... y eso, para mi vale más que cualquier cosa.

Y sí, no hace falta que me lo expliques, que tienes razón. Con runge kuta o sin él...

Saludos

[[Delphius]]

Empezado por fjcg02

Delphius, veo que no me pillas el punto...

En definitiva, si puedo escribir una línea de código, mejor que dos, siempre y cuando el rendimiento no penalice al usuario. Es que cuando uno es vago, es vago .... sin más... y eso, para mi vale más que cualquier cosa.

Y sí, no hace falta que me lo expliques, que tienes razón. Con runge kuta o sin él...

Saludos

Ha... iba por cuestión de LDC

Es que para mi las LDC no son de todo una buen métrica de eficiencia y productividad.

Incluso aún escribiendo un ciclo como el que aportó román me animaría a decir que es poca cosa el "costo", sino me equivoqué al hacer cuentas rápidas, la V(G) es 4; y LDC/V(G) da un valor 7/4 = 1,75. Este valor es muy bajo... y me indica que no llega a 2 LDC en promedio por cada V(G) del algoritmo... algo que una simple prueba a dedo, permitiría comprobar que es un algoritmo de poca cosa.

Dime... ¿Cuántas LDC implica y V(G), requiere, indirectamente el uso de un QuickSort?

Saludos,

[roman]

Empezado por fjcg02

En definitiva, si puedo escribir una línea de código, mejor que dos, siempre y cuando el rendimiento no penalice al usuario. Es que cuando uno es vago, es vago .... sin más... y eso, para mi vale más que cualquier cosa.

Entiendo tu punto y hasta podría decir que lo apoyo. Pero en este caso sigo dándole la razón a Delphius. Vamos a ver si realmente tenemos menos líneas de código.

Asumamos, por lo que han comentado antes, que debemos usar un StringList separado para no alterar la lista original. Podríamos hacer algo así:

Código Delphi [-]
var
  List: TStringList;

begin
  List := TStringList.Create;

  try
    with ListBox1 do
    begin
      List.AddStrings(Items);
      List.Sort;

      ShowMessage(Format('Min: %s, Max: %s',[List[0], List[Count - 1]]));
    end;
  finally
    List.Free;
  end;
end;

Que no es tan cortito. Pero aún hay más. No sirve. De hecho, tampoco el código que puse originalmente con Sorted := true sirve (punto extra al que diga por qué no sirve ) Hay que usar el método CustomSort del StringList y proveer una función de comparación, con lo cual yo creo que hasta rebasamos las líneas de código del recorrido simple.

// Saludos