Máximo o mínimo valor en un listbox

[[fjcg02]]

Se me ocurre que crees un TStringList, copies los elementos, ordenes y cojas el primero y el último.


Saludos

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

Empezado por fjcg02

Se me ocurre que crees un TStringList, copies los elementos, ordenes y cojas el primero y el último.

O eso, o realizar un recorrido manual con un for y quedarte tú con los dos valores, pero me gusta la propuesta por fjcg02 (es que yo soy mucho de TStringList ;-D ).

[[fjcg02]]

Empezado por Neftali

O eso, o realizar un recorrido manual con un for y quedarte tú con los dos valores, pero me gusta la propuesta por fjcg02 (es que yo soy mucho de TStringList ;-D ).

Seguro que el chino es más eficiente que cualquiera de nosotros. Además, si alguien trabaja por nosotros, siempre nos setiremos más importantes...

Respecto a los stringlist, al final vía listas, se pueden hacer casi todas las cosas, y desde luego bajo mi punto de vista, son mucho más cómodas de usar que cualquier otra cosa, como arrays por ejemplo. Y si no mirad cómo funciona python...

Saludos

[roman]

Quizá no necesite un StringList:

Código Delphi [-]
with ListBox1 do
begin
  Sorted := true;
  ShowMessage(Format('Min: %s, Max: %s', [Items[0], Items[Count - 1]]));
end;

// Saludos

[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"