PHP Tips: preg_replace, array_map, array_keys & array_values

[vlad]

Realmente eso seria solo para articulos con variaciones casi sinonimos porque ningun sistema automatico te podria reemplazar "carro", "coche" y  "auto" por "automovil" a menos que las variaciones estuvieran ingresadas.

[rdoggsv]

Realmente el preg replace no lo uso mucho, pero array keys y array values si son muy utilizados, sobre todo que al estar trabajando con formularios y mapear los campos con modelos se utilizan mucho los arreglos.

Buenos tips vlad, gracias

[tekun]

ok, pero aún siento que "la utilidad" no es la adecuada, el echo de que no te importe el RDBMS lo veo como un problema también, porque te estas esforzando en implementar algo que ya esta echo... aquí cabe la frase "estas reinventando la rueda"....

En un sitio grande es donde mas utilidad le encuentro yo , un sitio grande = mas contenido = mas posibilidades de que la gente no encuentre algo si pone una letra de mas.

la verdad no se como funcionan los "tags" en los sitios web, ni como se hace la consulta en el servidor sobre ese tema.. pero considero que aquí debe intervenir el motor de la base....

ahora entiendo porque dicen que "mysql es más rápido" si casi no hace nada... si con php haces cosas que debería hacer el motor

[vlad]

ok, pero aún siento que "la utilidad" no es la adecuada, el echo de que no te importe el RDBMS lo veo como un problema también, porque te estas esforzando en implementar algo que ya esta echo... aquí cabe la frase "estas reinventando la rueda"....
la verdad no se como funcionan los "tags" en los sitios web, ni como se hace la consulta en el servidor sobre ese tema.. pero considero que aquí debe intervenir el motor de la base....

ahora entiendo porque dicen que "mysql es más rápido" si casi no hace nada... si con php haces cosas que debería hacer el motor

¿Porque son cosas exclusivas de la base de datos?, luego cuando toca migrar de base de datos son los dolores de cabeza porque todo esta implementado a ese nivel. Total, para no dar larga a esto (porque el tema era sobre PHP ) creo que solo se puede concluir con "cada quien y sus gustos"

[mxgxw]

Realmente eso seria solo para articulos con variaciones casi sinonimos porque ningun sistema automatico te podria reemplazar "carro", "coche" y  "auto" por "automovil" a menos que las variaciones estuvieran ingresadas.

Yo se que el objetivo de este tema no era saber si preg_match es adecuado para el tipo de aplicacion que se utiliza o no.

Recuerdo cuando trabajaba en el CMS de SNET implementamos las friendly URLs.. y se desarrolló un sistema de auto-corrección bien interesante.

La idea general era que el usuario pudiera escribir la URL amigable segun se acordaba. Así si escribía http://www.snet.gob.sv/volcanologia el gestor lograra identificar "volcalonolgia" y convertirla inmediatamente a la palabra correcta del diccionario, en este caso "vulcanologia".

No quise utilizar preg_match ya que es un gestor de contenido dinámico entonces es prácticamente imposible tener actualizado un catálogo de sinónimos o palabras similares. Y no podría detectar cosas como estas:

http://www.snet.gob.sv/ver/megeotorigia -> te muestra el contenido de http://www.snet.gob.sv/ver/mteorologia

Lo que se hace es bastante simple y ayuda mucho que todas las páginas tienen un orden jerarquico. Para cada nodo del arbol cada una de las ramas (paginas internas) almacena su nombre.

Para comparar utilizo esta funcion:

Levenshtein

Que te calcula el numero de "transformaciones" necesarias para convertir una palabra en otra.

Luego se hace una comparacion de cual palabra es la que mas se asemeja (en este caso la que necesite menos transformaciones) y se realiza la redireccion. Obviamente no es perfecto, pero trabaja absurdamente rápido, no hay que tener una lista de palabras similares y es completamente transparente para el usuario.

Tambien hay otra funcion llamada Soundex para PHP pero es un algoritmo de comparacion fonética así que no aplicaba para nuestro caso ya que buscaria similitudes en pronunciación en ingles para palabras en español.

Otra funcion en php util para este tipo de busquedas es "similar_text". Te recomiendo que le des una revisada a la documentación de estas funciones para ver las ventajas y desventajas de cada uno.

Realmente las funciones de expresiones regulares son bastante útiles cuando sabes exactamente que es lo que estas buscando o que queres reemplazar, o cuando tu entrada es "regular". Pero cuando no sabes exactamente que es tu entrada de datos usar regexp te puede dar mas dolores de cabeza que soluciones.



P.D.: Si te fijas la solucion implementada al final es una mezcla de busquedas en SQL y filtrado en PHP. No es algo que haga completamente el gestor ni tampoco completamente PHP . Lastima que no estoy en SNET pero bien se podrìa implementar un "cache" de errores comunes. Asi cada palabra mal escrita se almacena en la DB con su correspondiente correccion y así luego revisas primero si ya se resolvio y sino aplicar el algoritmo de busqueda difusa, con lo que reducirias considerablemente la cantidad de consultas a la DB.. y procesamiento del lado de PHP.

[tekun]

ya cambiamos de tema pero esta interesante ...

¿Porque son cosas exclusivas de la base de datos?, luego cuando toca migrar de base de datos son los dolores de cabeza porque todo esta implementado a ese nivel. Total, para no dar larga a esto (porque el tema era sobre PHP ) creo que solo se puede concluir con "cada quien y sus gustos"

son cosas exclusivas de la base de datos, porque es un alto costo implementarlo en programación...

aja, pero si te toca migrar de lenguaje? si te pasas a asp.Net ? como quedaría tu trabajo?...


y obviamente si me voy a migrar de base de datos, no lo haré de mysql a access -por decir algo-... lo haré para un motor de más calidad, que como requisito mínimo debe tener lo que ya poseo...

[mxgxw]

ya cambiamos de tema pero esta interesante ...

son cosas exclusivas de la base de datos, porque es un alto costo implementarlo en programación...

aja, pero si te toca migrar de lenguaje? si te pasas a asp.Net ? como quedaría tu trabajo?...


y obviamente si me voy a migrar de base de datos, no lo haré de mysql a access -por decir algo-... lo haré para un motor de más calidad, que como requisito mínimo debe tener lo que ya poseo...

Mira..... Si y no.

Por una parte es bonito utilizar todos los extras y funciones que te trae el gestor. Por otra parte depende de como va a crecer tu aplicacion. ¿A que me refiero?

Si vos cambias de un gestor de DB a otro y todas tus operaciones dependian considerablemente de funciones de la base de datos. Vas a morder el leño... duramente. Justamente por eso es que existen las "capas de abstraccion de datos" que lo que hacen es intentar hacer tranparente la utilizacion de distintos gestores de bases de datos dentro de la aplicación. Casi todos los ORM (Object-relational mapping) trabajan bajo esta filosofía.

¿A que quiero llegar? Si vos sabes que durante el ciclo de vida, tu aplicacion va a estar pegado a un solo gestor de BD excelente, sacale el jugo al gestor al máximo. Si en cambio tu aplicacion va a ser de fuente abierta o va a tener que trabajar con distintos gestores de bases de datos. Vas a tener que sacrificar un poquito de performance de la base de datos ya que a puro webo te va a tocar hacer o utilizar una capa de abstracción. En este caso tu capa de abstraccion a veces tendra que hacer ciertas funciones con codigo y otras veces tendra que utilizar funciones de la base de datos si estas están disponibles.

Asi que bueno.. mi recomendación... no nos cerremos, no es cuestión de que estemos reinventando la rueda o no... sino que hay muchos casos en que NO conviene casarse con un solo gestor de DB.

Además hay otra cosa. Un algoritmo es fácil de migrar de un lenguaje a otro, un algoritmo bien armado lo unico que hara es gastar ciclos en el lado del programa y no en el lado del gestor. Pero una funcion muy especica de un gestor de base de datos pocas o ninguna vez se puede migrar fácilmente de un gestor de base de datos a otro... mas con la bonita costumbre que tienen los proveedores de no seguir el estandar SQL.

[vlad]

Muy interesante, la verdad es que SOUNDEX me llamo mucho la atencion cuando lo vi, pero lastima que como dices no aplica al español  :( (aunque no dudo que exista alguna versión "hechiza" para nuestro idioma )

El de Levenshtein lo revise, pero ese si lo queria a nivel de Mysql , pero andaba buscando algo "magico" como para usarlo tipo:
"SELECT levenshtein(col1,$palabra) AS similitud FROM tabla WHERE similitud >= 0 ORDER BY similitud ASC LIMIT 1"

Y pues existe pero lamentablemente hay que tener full control del servidor para agregar la funcion :(

http://www.teamarbyte.de/levenshtein.html

Hacerlo el filtrado en PHP como tu expones me parece excelente y super interesante, no se porque nunca lo considere realmente, aunque me temo que practicamente tenes que cargar toda la tabla para luego ejecutar Levenshtein de forma similar al ejemplo en el sitio de PHP:

Código: [Seleccionar]

<?php
// input misspelled word
$input = 'carrrot';

// array of words to check against
$words  = array('apple','pineapple','banana','orange',
                'radish','carrot','pea','bean','potato');

// no shortest distance found, yet
$shortest = -1;

// loop through words to find the closest
foreach ($words as $word) {

    // calculate the distance between the input word,
    // and the current word
    $lev = levenshtein($input, $word);

    // check for an exact match
    if ($lev == 0) {

        // closest word is this one (exact match)
        $closest = $word;
        $shortest = 0;

        // break out of the loop; we've found an exact match
        break;
    }

    // if this distance is less than the next found shortest
    // distance, OR if a next shortest word has not yet been found
    if ($lev <= $shortest || $shortest < 0) {
        // set the closest match, and shortest distance
        $closest  = $word;
        $shortest = $lev;
    }
}

echo "Input word: $input\n";
if ($shortest == 0) {
    echo "Exact match found: $closest\n";
} else {
    echo "Did you mean: $closest?\n";
}

?>


[mxgxw]

Muy interesante, la verdad es que SOUNDEX me llamo mucho la atencion cuando lo vi, pero lastima que como dices no aplica al español  :( (aunque no dudo que exista alguna versión "hechiza" para nuestro idioma )

El de Levenshtein lo revise, pero ese si lo queria a nivel de Mysql , pero andaba buscando algo "magico" como para usarlo tipo:
"SELECT levenshtein(col1,$palabra) AS similitud FROM tabla WHERE similitud >= 0 ORDER BY similitud ASC LIMIT 1"

Y pues existe pero lamentablemente hay que tener full control del servidor para agregar la funcion :(

http://www.teamarbyte.de/levenshtein.html

Hacerlo el filtrado en PHP como tu expones me parece excelente y super interesante, no se porque nunca lo considere realmente, aunque me temo que practicamente tenes que cargar toda la tabla para luego ejecutar Levenshtein de forma similar al ejemplo en el sitio de PHP:

Código: [Seleccionar]

<?php
// input misspelled word
$input = 'carrrot';

// array of words to check against
$words  = array('apple','pineapple','banana','orange',
                'radish','carrot','pea','bean','potato');

// no shortest distance found, yet
$shortest = -1;

// loop through words to find the closest
foreach ($words as $word) {

    // calculate the distance between the input word,
    // and the current word
    $lev = levenshtein($input, $word);

    // check for an exact match
    if ($lev == 0) {

        // closest word is this one (exact match)
        $closest = $word;
        $shortest = 0;

        // break out of the loop; we've found an exact match
        break;
    }

    // if this distance is less than the next found shortest
    // distance, OR if a next shortest word has not yet been found
    if ($lev <= $shortest || $shortest < 0) {
        // set the closest match, and shortest distance
        $closest  = $word;
        $shortest = $lev;
    }
}

echo "Input word: $input\n";
if ($shortest == 0) {
    echo "Exact match found: $closest\n";
} else {
    echo "Did you mean: $closest?\n";
}

?>


No necesitas cargar toda la tabla en  memoria...

Simplemente haces algo como esto:

Código: [Seleccionar]

<?php
$mejorpeso = 999; // un valor alto de transformaciones, depende del tamaño de la palabra
$mejorpalabra = "";

while($row=mysql_fetch_assoc($result)) {
    $peso = levenshtein($row['col'],$palabra);
    if($peso<=$mejorpeso) {
        $mejorpeso = $peso;
        $mejorpalabra = $row['col'];
    }
}
?>

Al final del while vas a tener la palabra que más se asemeja. Luego podes optimizar el query sql para buscar más palabras

[vlad]

ya cambiamos de tema pero esta interesante ...

son cosas exclusivas de la base de datos, porque es un alto costo implementarlo en programación...

aja, pero si te toca migrar de lenguaje? si te pasas a asp.Net ? como quedaría tu trabajo?...


y obviamente si me voy a migrar de base de datos, no lo haré de mysql a access -por decir algo-... lo haré para un motor de más calidad, que como requisito mínimo debe tener lo que ya poseo...

Eso es todo otro nivel de problema, porque si estas hablando de cambiar el lenguaje de la aplicacion estas hablando de volver a escribirla desde cero, que es casi como hacerlo nuevo todo :\.

Ahora bien, migrar de base de datos es (o deberia de) ser mucho mas sencillo porque es cuestion meramente de almacenamiento, a menos que la logica de tu aplicacion resida en la base de datos, en cuyo caso es el problema.

[vlad]

No necesitas cargar toda la tabla en  memoria...

Simplemente haces algo como esto:

Código: [Seleccionar]

<?php
$mejorpeso = 999; // un valor alto de transformaciones, depende del tamaño de la palabra
$mejorpalabra = "";

while($row=mysql_fetch_assoc($result)) {
    $peso = levenshtein($row['col'],$palabra);
    if($peso<=$mejorpeso) {
        $mejorpeso = $peso;
        $mejorpalabra = $row['col'];
    }
}
?>

Al final del while vas a tener la palabra que más se asemeja. Luego podes optimizar el query sql para buscar más palabras

Perdon, no me referia a cargar la tabla en memoria, si no mas bien a cargar toda la tabla en el sentido de tener que recorrerla toda (todos los registros), aunque asumo que hacerlo a nivel de MySQL tampoco aprovecharia ningun indice en la busqueda del menor Levenshtein :'( .

[rdoggsv]

Yo lo que siento es que tekun esta enojado :( porque usamos mysql :P , ya me imagino el server de la svcommunity con postgresql y la inversión en recursos que habría que hacer para que la lentitud esa chupa recursos funcione :P

Volviendo al tema siento que esta mejor lo de lógica difusa y crear una red neuronal que te busque las similitudes y lo que deseas encontrar :P tipo backpropagation,

Por cierto para un sistema que trade de buscar lo que el usuario quería estoy más orientado con la lógica de google, decirte que no encontró lo que buscabas y que hay X cantidad de resultados con estas otras palabras similares, no forzarlo a llegar adonde tal vez el no quería llegar.

Apuesto que los de google usan algo parecido a redes neuronales para ofrecerte el mejor match :P

[mxgxw]

Yo lo que siento es que tekun esta enojado :( porque usamos mysql :P , ya me imagino el server de la svcommunity con postgresql y la inversión en recursos que habría que hacer para que la lentitud esa chupa recursos funcione :P

Volviendo al tema siento que esta mejor lo de lógica difusa y crear una red neuronal que te busque las similitudes y lo que deseas encontrar :P tipo backpropagation,

Por cierto para un sistema que trade de buscar lo que el usuario quería estoy más orientado con la lógica de google, decirte que no encontró lo que buscabas y que hay X cantidad de resultados con estas otras palabras similares, no forzarlo a llegar adonde tal vez el no quería llegar.

Apuesto que los de google usan algo parecido a redes neuronales para ofrecerte el mejor match :P

Me imagino que sí... pero acordate que para "afinar" la red necesitas una gran cantidad de entradas, la ventaja que tiene google es que tienen suficiente información como para crear Skynet.

Para aplicaciones así pequeñas pienso que sería demasiado  meter una red neuronal solo para eso.

[Jaru]

rdoggsv y mxgxw mejor medicina hubieran estudiado.
Neurologos necesita el pais

[tekun]

Yo lo que siento es que tekun esta enojado :( porque usamos mysql :P , ya me imagino el server de la svcommunity con postgresql y la inversión en recursos que habría que hacer para que la lentitud esa chupa recursos funcione

jeee, fijate que no había mencionado Postgres hasta que g00mba menciono algo que podía aplicarse para el ejemplo de vlad.. o sea no hay necesidad de parsear, por varias razones ya platicadas y tu mencionas una nueva "no forzarlo a llegar adonde tal vez el no quería llegar"

mi único objetivo era decirle a vlad que hay "algunas" ocasiones donde no es necesario esforzarse tanto programando cuando hay "otras" salidas que ya están dadas...

la funcionabilidad y utilidad de los preg_replace es válida y muy útil en ciertas ocasiones, yo iva a que es muy costoso, tener que hacer eso para luego poder hacer una Consulta a la base de datos...