Foro - Perl en Español

Bueno, vamos a empezar...

Primero: los programadores de Perl no escribimos scripts. Hacemos programas

Segundo... el programa en sí

• En vez de un declare() y un execute(), usaría un selectall_arrayref() (no probado):
  
  Sintáxis: [ Descargar ] [ Ocultar ]

  Sintáxis: [ Descargar ] [ Mostrar ]

  Using perl Syntax Highlighting

  my @array = @{ $dbh->selectall_arrayref("select calle FROM dir where completo = ''  GROUP BY direc ORDER BY direc") };

  Coloreado en 0.002 segundos, usando GeSHi 1.0.8.4
  
  Lo mismo para @array2. El objetivo es tenerlo todo en arrays, que facilitan la nomenclatura posterior, aparte de que Perl se ahorra varios cálculos a la hora de hacer desreferencias, como cuando queremos averiguar el número de elementos del array.
• Todos los if() hacen lo mismo, así que se pueden simplificar en uno solo.

Quedaría algo así (no probado):



Ahora quedaría la parte de decidir qué hacer cuando los casos de coincidencia. Primero habría que decidir cuándo hay una coincidencia plena. Si suponemos que es cuando la similitud es superior al 90%, entonces podemos incluir una línea al final del bucle más interior con esto:

Así, saltamos a probar la siguiente calle del bucle más exterior.

Lo interesante es el poder sacar elementos de los array a medida de que vamos encontrando coincidencias.

Pero... no es tan sencillo. O bueno... es sencillo pero nada recomendable.

Quiero decir que se podría poner una instrucción splice() en el bucle más interior para extraer el elemento que nos interesa (habría que cambiar la forma de recorrer los arrays, pasando de elementos a índices de elementos), y Perl reduciría el tamaño del array.

El problema es que, en la documentación, aconsejan no hacer nada de esto. Podría ser una operación no bien soportada en futuras versiones de Perl.

Hay varias soluciones: una de ellas sería guardar los índices de las calles encontradas en los arrays. Y luego, indefinir esa posición en el segundo array, para que el bucle más interno vaya más rápido.

Algo así (no probado):

Al final tenemos un array, @calles encontradas, que contiene los índices dentro de los arrays, de las calles que más coinciden.

Naturalmente, estamos destruyendo la información del segundo array, así que si queremos saber qué valores eran, tendremos que hacer otra consulta a la base de datos. O crear, antes del bucle, una copia de ese array en uno nuevo. Para esto último, no vale con hacer un '='. Como estos arrays son estructuras complejas (array de array), deberás usar un módulo, como por ejemplo Clone, para hacer esa copia. O crear un array que contenga referencias a los elementos del segundo array. En fin, hay varias soluciones. La idea es jugar con la información que tenemos, pero que nos permite ahorrar el máximo posible de tiempo haciendo el mínimo de comparaciones, asignaciones, y ciclos. Y lo dicho para el segundo array se puede extender al primero, si estamos seguros de que, si dos calles coinciden en ambos arrays, los podemos sacar porque no habrá otra calle del segundo array que coincide con alguna del primero.

Es cierto, tengo esa muy mala costumbre de llamar todo script. Un viejo hábito heredado del HTML y Javascript. jajaja.

Imagino que esto:

debería ser:


¿no?

Me temo que estoy un poco espeso y no entiendo y lo del Clone.

¡De verdad que muchas gracias!

Pues sí que hay un fallo, pero la solución no es la que pones

He reeditado el código y ya lo he dejado bien. Se trata de $#array1, que devuelve el índice del último elemento del array.

Lo del Clone es una posibilidad más. Es un módulo que se usa para copiar estructuras de datos complejas.

Ya lo he probado, pero no quita el nombre cuando coincide, se siguen evaluando del 100% hasta llegar al 50%.

Lo que estoy haciendo como "primera fase" de identificación es ejecutar una instrucción SQL que casa las del 100%.

Luego aplico este programa para las variantes.

El test lo realicé con una tabla de 700 registros contra otra de 8000, de las cuales esas 700 tienen coincidencias del 100%. El tiempo de trabajo del programa fue de 35 min.

Si disminuyo el nivel de coincidencia se repiten por cada registro, no hace el next.

Vamos a ver... eso no puede ser... media hora para solo 5.600.000 comparaciones... es demasiado tiempo.

He hecho un programa que me genera 8000 cadenas aleatorias, entre 20 y 80 caracteres. De ellas me extraigo 700:



Haciendo el doble bucle propuesto:

me salen tiempos de 15 minutos. El módulo Smart::Comments apenas aporta retraso. El módulo informa que tardará 29 minutos, pero luego, con la ayuda del next, va acelerando.

Sigue siendo demasiado tiempo.

Entonces, es cuando debemos volver a leer la documentación... porque el culpable es String::Trigram, naturalmente.

Leyendo con cuidado, vemos que hemos elegido la peor solución que nos ofrece el módulo:
* no le damos una base de cadenas de caracteres para entrenar la red de ngramas.
* usamos la función compare(), que es lo más lento del módulo, ya que crea un objeto nuevo en cada comparación.

Respetemos la decisión de preiddy de elegir que el tamaño de los ngramas sean de 7 caracteres.

Solo queda reescribir el programa para hacer las comparaciones según lo recomienda el módulo:



Tiempo: 8 segundos. 6 segundos si quitamos los print().

Eso ya me gusta más.

Incluso si descomentamos la línea 26, para agregar en la base de conocimiento las cadenas de @array2, la diferencia es pequeña (no las he agregado porque son copias de @array1).

Ahora solo queda jugar con el parámetro minSim y ngram para filtrar aún más las coincidencias.

Eso es lo malo de "heredar" código de los compañeros de trabajo, jajajajaa.

El programa es de otro compañero, me lo pasó para que le echara un ojo y lo menos que hice fue leer la documentación.

En una oportunidad leí que para los nombres en español los ngramas funcionan mejor con 7. El argumento era muy razonable, jajaja.

De nuevos muchas gracias y en cuanto lo pueda probar te comento los resultados.