Ordenar e insertar ordenado en TObjectList

[[Delphius]]

Empezado por roman

Bueno, es que esto sería imposible
// Saludos

Pues si. Pero es que yo asumía que por "previamente almacenados" hace referencia a que de algún modo se recuperaban los datos almacenados físicamente y que éstos ya se encontraban ordenados.

Voy a tener que dejar los supuestos

Yo también le apuesto a TStringList cuando se trata de mantener los objetos ordenados de acuerdo a cierta "clave", aunque no me es de total agrado... Lo siento como que se está utilizando un parche.
Resulta extraño que no hubiera de fábrica una lista de objetos ordenada, sin tener que recurrir a otra vía.

Saludos,

[roman]

Pero, ¿dónde leiste eso de previamente almacenados?

// Saludos

[[Delphius]]

Empezado por roman

Pero, ¿dónde leiste eso de previamente almacenados?
// Saludos

Pues por eso... yo asumí que el máximo objetivo, no comentado, de sebamawa era de lograr tener los objetos almacenados y ordenados. De modo que ante una recuperación o "lectura" de éstos, bastaría con hacer una inserción ordenada y no tener que estar aplicando algoritmos de ordenamiento.

Saludos,

[roman]

Pues sí, ése es su objetivo. Creo que te hace falta un café para despertar

// Saludos

[[Delphius]]

Empezado por roman

Pues sí, ése es su objetivo. Creo que te hace falta un café para despertar
// Saludos

Mas bien dejar de jugar al God of War II en la PS2 y postear al mismo tiempo.

Saludos,

[sebamawa]

Hola a todos nuevamente !!!
Para eliminar un objeto de una lista TObjectList tenemos el método Remove; ahora para buscar un objeto en la misma por un campo clave hay algún método predefinido?. En caso de no haberlo, sería viable implementar un procedimiento que realice una búsqueda binaria, como propuso Roman para la inserción de objetos en una lista ?
Me podrían poner un ejemplo de este caso, por ejemplo si se tiene una lista de objetos (persona) y se quiere eliminar una persona según un número de documento que se ingrese para la búsqueda. Tengan presente que la lista está ordenada de forma ascendente según los números de documentos.
Desde ya muchas gracias.
Saludos.

[ecfisa]

Hola sebamawa.

Si la lista ya está ordenada podes usar una búsqueda binaria. Tomemos como ejemplo una reducción de la clase que puso de ejemplo roman:

Código Delphi [-]
implementation

type
  TCliente = class
    Nombre: String;
  end;

var
  LstObj : TObjectList;
  Cliente : TCliente;

procedure TForm1.FormCreate(Sender: TObject);
var
  i: Integer;
begin
  LstObj := TObjectList.Create;
  // Demás operaciones de carga
  ...
end;

function TForm1.BinarySearch(OLst: TObjectList; Valor: string): Integer;
var
  Pri, Ult, Med : Integer;
  Esta : boolean;
begin
   Pri  := 0;
   Ult  := OLst.Count-1;
   Esta := False;
   while (Pri <= Ult) and not Esta do
   begin
      Med := (Pri + Ult) div 2;
      if TCliente(OLst.Items[Med]).Nombre = Valor then Esta := true;
      if TCliente(OLst.Items[Med]).Nombre < Valor then Pri  := Med + 1;
      if TCliente(OLst.Items[Med]).Nombre > Valor then Ult  := Med - 1;
   end;
   if Esta then
     Result := Med
   else
     Result := -1;
end;

// Ejemplo de llamada:
procedure TForm1.Button1Click(Sender: TObject);
var
  P : Integer;
begin
  P := BinarySearch(LstObj, 'Juan Perez');
  if P <> -1 then
    ShowMessage('Nombre:   ' + TCliente(LstObj.Items[P]).Nombre+#10#13+
                'Posición: ' + IntToStr(P));
  //  ...
end;

...

procedure TForm1.FormDestroy(Sender: TObject);
begin
  if Assigned(LstObj) then
    LstObj.Free;
end;

Saludos.

[sebamawa]

Muchas gracias ecfisa, algo como lo que planteaste tenía en mente y resulta de mucha ayuda.
Como he comentado, vengo de Pascal Estándar, o sea de arreglos estáticos, crear listas enlazadas desde cero, etc, y estoy tratando de migrar algunas estructuras de datos a Delphi como listas enlazadas y arboles, pero claro, Delphi ya tiene incorporadas muchas de estas estructuras o algunas semejantes que facilitan el tener que empezar a programar desde cero, supongo que esto se da en todo lenguaje moderno.
Me podrías decir donde encontrar descripciones de los métodos y propiedades de las clases de Delphi, es que a veces cuando tengo que realizar una tarea caigo en la duda si, es que tengo una rutina predefinida o no, y en este último caso debo implementar la misma por mi cuenta.
Otra duda, el método FindInstanceOf de la clase TObjectList, qué tarea realiza?
Y lo último, teniendo la posibilidad de realizar búsquedas binarias en una lista (TObjectList por ejemplo), sabiendo que este tipo de búsqueda es muy eficiente, tiene sentido el utilizar árboles para el guardado de datos?
Tal vez más de uno me dirá que use base de datos, pero antes quiero manejar con solvencia las estructuras de datos que menciono antes.

Muchas gracias.
Saludos para todos.

[roman]

Empezado por ecfisa

Si la lista ya está ordenada podes usar una búsqueda binaria.

De hecho, modificando un poco, la misma función que se usa para la inserción se puede usar para la búsqueda. Es decir, se hace una sóla función de búsqueda que devuelva el índice donde debe ir el objeto. Ese índice se usa, bien sea para insertar un nuevo objeto, o bien para devolver la posición del objeto buscado.

// Saludos

[ecfisa]

Hola sebamawa.

Me podrías decir donde encontrar descripciones de los métodos y propiedades de las clases de Delphi

En la propia ayuda de Delphi encontras descrita las clases, sus propiedades y métodos. Sobre TList,TQueue,TStrings, etc revisa este enlace.

Otra duda, el método FindInstanceOf de la clase TObjectList, qué tarea realiza?

Busca la primera ocurrencia de una clase específica dentro de la lista. Si la clase buscada no existe devuelve el valor -1.

Saludos.

[[Delphius]]

Empezado por sebamawa

tiene sentido el utilizar árboles para el guardado de datos?
Tal vez más de uno me dirá que use base de datos, pero antes quiero manejar con solvencia las estructuras de datos que menciono antes.

Muchas gracias.
Saludos para todos.

¿Árboles? Pasar de un TAD lista a un TAD árbol no es poca cosa. En primer lugar habría que determinar si efectivamente tiene sentido alguno (sobre todo en lo lógico) el almacenar datos en forma de árbol.
Desconozco si Delphi provee de fábrica un TObjectTreeList (por darle un nombre) pero me parece que el que consideres pensar en árboles, y que luego sobre este posiblemente se deba implementar y adaptar los algoritmos de insersión, ordenamiento y búsquda es ya algo exagerado y una pérdida de tiempo.

Lo mejor es que le dejes eso al motor de base de datos... que lo hace estupéndamente. Si ya de hecho los motores por dentro poseen árboles para estructurar los datos. Concretamente los B+ tree.

Luego es que existen tus clase del dominio, y crearás tantos objetos como registros tengas. Al extraer los registros pasas los datos a cada instancia en sus correspondientes campos. Y el paso inverso, desde tu clase del dominio lees sus campos y mandas a ejecutar una instrucción INSERT o UPDATE sea el caso.
A estas alturas y si quieres seguir avanzando de escala ya te vas pensando en un framework de persistencia.

Me parece que te estás complicando las cosas innecesariamente.

Saludos,

[roman]

Empezado por Delphius

¿Árboles? Pasar de un TAD lista a un TAD árbol no es poca cosa. En primer lugar habría que determinar si efectivamente tiene sentido alguno (sobre todo en lo lógico) el almacenar datos en forma de árbol.
Desconozco si Delphi provee de fábrica un TObjectTreeList (por darle un nombre) pero me parece que el que consideres pensar en árboles, y que luego sobre este posiblemente se deba implementar y adaptar los algoritmos de insersión, ordenamiento y búsquda es ya algo exagerado y una pérdida de tiempo.

Aquí ya me perdí. Mis cursos básicos de computación me dicen que los árboles binarios son excelentes candidatos para guardar información ordenada. Es más, yo diría que una lista ordenada con inserción y búsqueda como la que hemos expuesto es esencialmente lo mismo que un árbol binario.

// Saludos

[[Delphius]]

Empezado por roman

Aquí ya me perdí. Mis cursos básicos de computación me dicen que los árboles binarios son excelentes candidatos para guardar información ordenada. Es más, yo diría que una lista ordenada con inserción y búsqueda como la que hemos expuesto es esencialmente lo mismo que un árbol binario.

// Saludos

Pues si roman, pero hay árboles mejores que los binarios Y B+ está pensado justamente para equilibrar: inserción, lectura, navegación, ordenamiento, etc. Y ni que decir... más convenientes si luego se tiene pensado hacer lectura/escritura física en un archivo. Justamente estos son los que utilizan los motores de base de datos.

Sinceramente, pretender llegar a pensar en árboles es demasiado. Es mejor quedarse con la Lista, a como se ha propuesto... y que como bien dices, para este caso es equivalente al árbol binario. Si ya la lista con lo propuesto sirve ¿para que más?
Si en verdad se quiere llevar al TAD árbol, y que se comporte como tal, pues habrá que buscar una clase, si es que ya está. O bien volver a retormar las clases de estructuras de datos.

A mi parecer, creo que se está perdiendo la sintonía del problema y buscar resolverlo de una forma más complicada de la que se podría llevar. Y lo digo precisamente porque algo me dice que sebamawa ha perdido de vista algo, porque algo le hace pensar ahora que árboles le resultará más adecuado.

¿No será mejor invitar a que se descubra y explique ese algo? Yo creo que de algo nos estamos perdiendo.

Saludos,

[sebamawa]

Estimados amigos, primero que nada les agradezco sus sugerencias y ayuda.
Estoy de acuerdo con lo que dice Delphius, estoy complicando las cosas, y seguramente eso se de porque aún me falta aprender muchas herramientas de Delphi.
Lo he dicho más de una vez, mi base previa en programación es Pascal Estándar, un curso con FreePascal y otro con Modula2 (que básicamente es Pascal para trabajar de forma modular).
Con los compiladores anteriores sólo trabajabamos con la consola Dos, o sea, todas las salidas se realizaban de modo texto en la consolita. Los cursos que mencioné estaban enfocados a adquirir los rudimentos de la programación estructurada (con FreePascal) y la programación modular (Modula2).
Prácticamente todo lo hacíamos desde cero, listas enlazadas, árboles, arreglos con tope, etc; claro que no eran superaplicaciones ni mucho menos lo que realizabamos partiendo "desde la nada".
Pero de interfaces gráficas, nada de nada, es por ello que yo de forma autodidacta he querido sumergirme un poco en la programación con interfaces de este tipo, y para ello elegí Delphi, pues es una forma de seguir conectado con Pascal.
Pero, está recontra claro, que la potencialidad y las herramientas de Delphi te ahorran mucho trabajo, y es por ello que a veces sin quererlo complico un poco las cosas queriendo traer algunas estructuras de Pascal Estándar que ya están predefinidas en Delphi como TAD's.

Nuevamente gracias, y espero se entienda en parte por qué he planteado ciertas dudas.
Saludos.

[roman]

Empezado por Delphius

Pues si roman, pero hay árboles mejores que los binarios Y B+ está pensado justamente para equilibrar: inserción, lectura, navegación, ordenamiento, etc. Y ni que decir... más convenientes si luego se tiene pensado hacer lectura/escritura física en un archivo. Justamente estos son los que utilizan los motores de base de datos.

Sinceramente, pretender llegar a pensar en árboles es demasiado. Es mejor quedarse con la Lista, a como se ha propuesto... y que como bien dices, para este caso es equivalente al árbol binario. Si ya la lista con lo propuesto sirve ¿para que más?
Si en verdad se quiere llevar al TAD árbol, y que se comporte como tal, pues habrá que buscar una clase, si es que ya está. O bien volver a retormar las clases de estructuras de datos.

A mi parecer, creo que se está perdiendo la sintonía del problema y buscar resolverlo de una forma más complicada de la que se podría llevar. Y lo digo precisamente porque algo me dice que sebamawa ha perdido de vista algo, porque algo le hace pensar ahora que árboles le resultará más adecuado.

¿No será mejor invitar a que se descubra y explique ese algo? Yo creo que de algo nos estamos perdiendo.

Saludos,

Sinceramente creo que rizas demasiado el rizo. No he visto que el forista haya pretendido hacer una motor de base de datos ni nada por el estilo. Más bien veo alguien que trata de familiarizarse con delphi implmentando algunas de las estructuras clásicas de datos. Pero una frase como

En primer lugar habría que determinar si efectivamente tiene sentido alguno (sobre todo en lo lógico) el almacenar datos en forma de árbol.

lejos de enriquecer la plática, oscurece el asunto. Si no almacenas datos en un árbol, ¿qué coños almacenas ahí? Desde luego que hay mejores o peores tipos de datos para cada tarea y que muy posiblemente cuando se ponga a la tarea real que le ocupe, pensará en una base de datos, pero considero que hay que tomar los hilos y las respuestas en su justa medida y no hacer una cátedra teórica en cada caso.

// Saludos

[[Delphius]]

Empezado por roman

Sinceramente creo que rizas demasiado el rizo. No he visto que el forista haya pretendido hacer una motor de base de datos ni nada por el estilo. Más bien veo alguien que trata de familiarizarse con delphi implmentando algunas de las estructuras clásicas de datos.

Yo no digo que pretenda hacer una base de datos, sino más bien tratar de entender el trasfondo de todo esto.
Por más que esto se trate de alguna práctica, debe haber algún objetivo detrás de esto, y que va más allá de practicar con los TADs.
Si en verdad lo que se busca es practicar con TADs pues entonces lo más apropiado es justamente utilizar TQueue, TStack, TList, para Colas, Pilas, Listas, algún derivado o similar de la familia de los TTreeView para árboles y se opere con estos. Es decir, tomar aquellos prácticos que se nos daban en la cátedra de estructuras de datos.

Y si en verdad se quiere llegar a implementar su propia clase, pues con más razón: agarrar los libros de estructuras de datos, repasar el tema de punteros e implementar los algoritmos. Justo casi igual que en la vieja escuela. Pero he aquí que las dudas me parecen encaminar a algo más profundo que eso y no es una cosa de una simple práctica de TADs sino que se intenta responder y utilizar a los TADs para algo que busca a hacer.
Parte de ese algo nos ha comentado, pero me parece que hay un iceberg oculto y no logramos ver. Y lo digo en buen plan, porque si ya se ha propuesto algunas soluciones y que ahora resulta que quiere ir a por árboles, es el momento de decir: Momento... ¿a donde más quieres llegar? Mejor analicemos el problema de otra forma, cual es el contexto a analiza y de allí vemos las posibles sugerencias y te damos los elementos para que practiques.

Empezado por roman

Pero una frase como
(...)
lejos de enriquecer la plática, oscurece el asunto.

No roman, no la oscurece.... Más bien intento traer luz, hay algo más allá de una simple práctica. Partamos de algo: cuales son los conocimientos que el interesado tiene, cual es el contexto que analiza, y vemos el mejor modo de guiar.
Porque así lo que se dará serán contenidos sueltos, uno después del otro y no necesariamente con alguna corelación cuando en realidad lo que más les favorece a los que se inicia es tener un buen plan de práctica que le ofrezca un paneo general y con un temario que sea escalado y sepa unir a los conceptos.
Si respondemos hoy sobre TObjectList, mañana sobre árboles, y quien sabe si luego en un mes es sobre grafos y vemos que se sigue dando vueltas en el mismo problema es una clara y evidente señal de que algo no se ha comprendido bien.

Empezado por roman

Si no almacenas datos en un árbol, ¿qué coños almacenas ahí? Desde luego que hay mejores o peores tipos de datos para cada tarea y que muy posiblemente cuando se ponga a la tarea real que le ocupe, pensará en una base de datos, pero considero que hay que tomar los hilos y las respuestas en su justa medida y no hacer una cátedra teórica en cada caso.
// Saludos

A ver roman, yo no dije que en un árbol no se ha almacenar datos. Sino más bien que quizá en términos lógicos AL PROBLEMA no sea lo más apropiado si hay una manera más simple de encararlo. Tu entendiste al término lógico, como algo interno al árbol. Me refería que quizá no hace demasiado a la lógica del problema.

Si los datos y las posibles operaciones a esperarse no dan ciertas evidencias de comportarse con dicha estructura es quizá el momento de preguntarse si el utilizar formal y explícitamente un árbol le aporta más valor... ¡a una mente que ya está confundida!

No pretendo dar una cátedra teórica en cada post, sino más bien evidenciar de que el problema se lo está planteando algo exagerado. Precisamente demuestro con exageraciones el impacto y a donde se lo está por intentar llevar al hilo.

Repito y sostengo: antes de empezar a saltar al tema de los árboles, ¿Será realmente necesario? ¿Porqué no discutir los verdaderos y demás objetivos tras todo esto?
Realmente te me sulfuraste conmigo al divino botón.

Saludos,

[roman]

Está bien Delphius, tranquilo, no te vayas a provocar una úlcera.

// Saludos