SEARCHMOTS
inwebo
Messages postés
380
Date d'inscription
lundi 12 novembre 2007
Statut
Membre
Dernière intervention
23 octobre 2014
-
29 janv. 2010 à 17:01
cs_juliuse Messages postés 12 Date d'inscription mercredi 24 mars 2004 Statut Membre Dernière intervention 19 février 2010 - 4 mars 2010 à 23:04
cs_juliuse Messages postés 12 Date d'inscription mercredi 24 mars 2004 Statut Membre Dernière intervention 19 février 2010 - 4 mars 2010 à 23:04
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/51207-searchmots
https://codes-sources.commentcamarche.net/source/51207-searchmots
4 mars 2010 à 23:04
2 mars 2010 à 12:41
Les commentaires sur la sources ne sont pas faites pour assurer le support aux utilisateurs finaux.
2 mars 2010 à 12:20
23 févr. 2010 à 21:30
23 févr. 2010 à 15:44
J'en profite pour faire remarquer que l'auteur n'a même pas participé aux commentaires...
23 févr. 2010 à 13:34
23 févr. 2010 à 13:25
merci
21 févr. 2010 à 22:47
Ca m'énerve alors voici comment il aurait fallut faire après la ligne 15 :
//Vérifie si la recherche a été demandée
if(empty($_POST['quoi'])) die('Aucune recherche n\'a encore été effectuée.');
$To_Search = $_POST['quoi'];
//Vérifie la présence du fichier
$Fichier = "ods5.txt";
if (!file_exists($Fichier)) die('Impossible de continuer, le fichier est introuvable !');
//Effectue la recherche, ligne par ligne dans le fichier.
$handle = fopen($Fichier, 'r') or die('Erreur lors de la lecture du fichier');
$results = array();
while (!feof($handle)) {
$buffer = trim(fgets($handle, 4096)); // On récupère une ligne (trim supprimera les blancs éventuels)
if(stristr($buffer , $To_Search) !== FALSE) { // Recherche insensible à la CASE
$results[] = array('mot'=>$buffer, 'nb'=>strlen($buffer));//On place le résultat dans un tableau
}
//On referme le fichier.
fclose($handle);
//On affiche le résultat (mise en forme à adapter en fonction).
echo ' Il y a ', count($results), ' résultat(s) à cette recherche :'."\n";print_r($results);echo '
';
Ce n'est pas l'idéal mais c'est déjà plus propre comme ça. En plus on peut même s'amuser à opérer un tri alphabétique ou par nombre de lettres sur le tableau de résultats.
21 févr. 2010 à 19:33
ex:ods5.txt et ods6.txt
merci ..
3 févr. 2010 à 04:44
j'ai beaucoup retravaillé son code (je l'ai passé à 15 lignes...) et j'ai réussi à faire ce que je voulais en faire: un système de résolution pour les jeux de pendu!
Merci
1 févr. 2010 à 17:40
Si je remet en cause la valididé du source, c'est uniquement pour le fait qu'il n'inove en rien et qu'en plus c'est mal codé... BDD ou pas, pour moi, c'est un source sans intérêts...
1 févr. 2010 à 16:10
Le problème est le but de la source : étude ou production.
Dans le premier cas, le but est didactique, étudier une solution à un problème, envisager une nouvelle approche. Ici, on se soucie peu des performances, de la facilité de mise en route, etc. Une telle source n'est pas nécessairement faite pour fonctionner parfaitement, juste pour présenter une nouvelle manière de voir les choses.
Dans le second cas, on souhaite que la source fonctionne, soit facile à mettre en oeuvre et performante. Cela implique que la configuration doit être aisée, facilitée, rapide (le plus possible, selon les cas c'est plus ou moins possible). Mais cela implique également que la solution apportée n'est pas nécessairement innovante, mais performante.
Enfin, il reste possible de proposer une source qui soit utilisable en production et qu'il soit possible d'étudier pour son approche. Elle combinerait alors les qualités des deux cas précédents : facile à utiliser, assez performante (on n'attend pas forcément le top du top, juste que son utilisation ne fasse pas s'écrouler un serveur), innovante...
La source présente ne présente pas ces caractéristiques : elle est peut-être facile à mettre en oeuvre, mais d'un point de vue performances, ça reste franchement à démontrer. Pour ce qui est d'une nouvelle approche, elle n'innove nullement puisque l'algo utilisé semble encore moins évolué que d'autres vieux de plusieurs décennies.
La solution (dont je dis qu'elle n'existe pas sur CS) serait de laisser l'auteur définir le but de sa source : didactique ou production. Comme ce n'est pas possible, il faut que l'auteur l'exprime clairement lui-même, à partir de quoi on pourra commencer à critiquer objectivement (dans le sens apporter des critiques constructives) dans un contexte défini.
Pour ce qui est des performances de l'algo par dichotomie sur un SGBD, j'ai comme un doute. Les contraintes ne sont pas les mêmes pour chaque et PHP ne permet pas d'accéder directement à un offset, contrairement à un SGBD : celui codé dans le langage de plus bas niveau, du fait qu'il est plus proche de la machine, peut permettre d'accéder directement à un registre mémoire donné ou à un bloc d'espace de stockage. Je ne suis vraiment pas certain que PHP puisse rivaliser avec ça... Sans parler de la mise en cache en RAM... Bref, un langage de script ne PEUT PAS apporter les mêmes performances qu'un langage compilé en LM.
Je laisse aux sceptiques le soin de bencher, pour ma part, j'estime que c'est une perte de temps.
Il n'en reste pas moins que je n'ai aucunement remis la validité de cette source en question : je ne faisais que soulever l'interrogation "Pourquoi tant de scripts qui revandiquent ne pas utiliser de bdd ?"
1 févr. 2010 à 15:18
Avec les bd, c'est généralement une toute autre affaire : il faut commencer par modifier un fichier de connexion, se préoccuper ensuite de la compatibilité des tables à importer avec sa propre bd, pour terminer par leur importation proprement dite dans un espace où c'est généralement déjà un peu le bazar. Reste plus qu'à croiser les doigts pour que l'exécution ne commence pas par un message d'horreur!
Pour ce qui est des performances de l'algorithme de "recherche dichotomique" appliqué à un fichier texte ordonné, attention!, il est d'une efficacité redoutable et peut s'avérer nettement plus rapide qu'une requête sur une table de bd avec un champ indexé.
Le seul intérêt de la bd, finalement, c'est que celle-ci est en permanence en mémoire vive, ce qui allège d'autant le travail à fournir par le serveur.
1 févr. 2010 à 13:45
si on regarde l'algo:
-fichier dico existe?
-Si oui:
-on reteste pour voir si il existe (lol)
-si oui:
-on le charge dans la variable $tab.
-fin reteste
-on recharge le fichier dans une nouvelle variable $tableau (et $tab alors?? lmao)sans tester s'il existe (??rotlmao).
-on change la case de la variable $_POST["quoi"] et on la charge dans la variable $info.
-la variable $info compte des éléments?
-si oui:
-on affiche "le mot à été trouvé" //hu ???
-fin teste
-sinon (le fichier n'existe pas):
-on affiche "le mot n'a pas été trouvé" //hu??
-fin teste fichier dico
-pour $=0; $i<taille de $tableau; incrémente $i
-si on trouve une occurence de basse_case($_POST["quoi"]) à la position actuelle du tableau // et $info?
-on affiche le résultat en se basant sur la variable $infos //tien... $info est passé au pluriel
-fin si
-fin pour
Des tests à répétitions, des doublons de variables pour stocker les mêmes infos (surcharge d'occupation mémoire). Mauvaise gestions des noms de variables ce qui entraine une confusion entre-elle ($info/$infos). Mauvaise gestion de l'algorithme puisque la phrase 'mot trouvé' s'affiche même s'il n'est pas trouvé.
Source à supprimer à mon avis
1 févr. 2010 à 12:35
# $file= $Fnm;
# if (file_exists($Fnm))
# if(file_exists($file))
1 févr. 2010 à 12:35
Tu aurais par exemple pu envisager de décortiquer ton fichier texte par la première lettre de l'alphabet (Éléphant -> E -> E.txt) puis ensuite effectuer ta recherche. Je ne suis pas mathématicien, mais je sais que ca allégerait déjà ta Bande Passante. Après quand à l'utilisation d'une base de donnée c'est toujours mieux et ca se ferai en quelques lignes ^^ (passé l'appréhension, cela ne prend que quelques jours pour se familiariser à MySQL).
1 févr. 2010 à 12:30
C'est pas parce que c'est peu utilisé, que c'est mauvais. Imaginez justement si Google fonctionnait sur MySql... (ce n'est pas le cas, je vous rassure). Une recherche plein text peut être utile ou nécessaire selon l'application, le besoin et les contraintes métier.
Cependant, en l'occurrence il suffit de voir la réponse de Mayol pour voir que ce script ne peut pas fonctionner en l'état. La moindre des choses est d'appliquer un buffer de lecture pour éviter de dépasser rapidement la mémoire vive du serveur. Ensuite la source aurait pu aussi être améliorée comme l'a démontré l'Opossum_farceur.
Conclusion : source inutile, si ce n'est à me faire me tirer les cheveux.
3/10 dans l'hypothèse où les modifs suivantes seraient effectuées :
- http://fr2.php.net/manual/fr/function.fgets.php : voir l'exemple "lecture ligne à ligne d'un fichier"
- strcasecmp compare une chaine sans tenir compte de la case (majuscule/minuscule)
1 févr. 2010 à 10:40
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 35 bytes) in /Volumes/masto_intel/WEB/phpcs_SEARCHMOTS___Page/search_mot/lister.php on line 43
1 févr. 2010 à 08:47
Php n'est absolument pas équipé pour faire face à ce genre de travail.
Imaginez google tournant sur un moteur php et sans base de données: c'est impensable. J'utilisait des scripts comme celui là il y a 20 ans quand je programmais en basic et turbo pascal, mais depuis, les choses ont un peut évoluées.
C'est vrais qu'au début ce n'est pas évident de se plonger dans MySQL, mais après ça se fait tout seul.
Pour ce qui est du code franchement, je ne vois pas l'intérêt d'avoir publié ce source.
Honnetement, il aurait fallut creuser et étoffer ce code avant de venir le soumettre ici.
---------------------------
it's nothing personal, just what I think
1 févr. 2010 à 02:16
PHP n'est pas fait pour ça : un SGBDR oui, parce qu'il est codé en C (ou équivalent mais un langage de plus bas niveau, compilé en instructions machine d'encore plus bas niveau).
Y'a quand même un truc que j'ai du mal à comprendre, c'est cette manie chez certains développeurs de toujours vouloir faire des scripts qui n'utilisent pas de base de données. Un SBGDR est quelque chose d'assez simple (voire enfantin) à installer et à configurer, pourquoi ouloir absolument remplacer un logiciel performant par un succédané d'une lenteur à faire s'écrouler un serveur avec deux utilisateurs ? J'veux dire c'est bien pour faire de la recherche, mais concrètement, pour une application pratique, je vois pas à quoi ça rime.
1 févr. 2010 à 01:06
Les idées d'améliorations que je suggère sont exactement celles que j'ai appliquées à mon script d'adresse :
http://www.phpcs.com/codes/DICTIONNAIRE-RIMES_45017.aspx
Par ailleurs, si l'algo "recherche dichotomique" t'es totalement étranger, il est toujours possible de taper "recherche dichotomique" dans ton moteur favori (29000 occurences). Ceci dit, j'ai un faible pour le tuto d'adresse :
http://www.siteduzero.com/tutoriel-3-76650-la-recherche-dichotomique.html
lequel contient une version codée en php.
31 janv. 2010 à 11:58
Hello,
Vas y mon gars, améliore puisque tu as la solution et fait nous en profiter , je suis preneur .
31 janv. 2010 à 03:49
Ce script est plutôt poussif quand la 1ère lettre du mot se situe vers la fin de l'alphabet; la raison en est que le tableau est parcouru séquentiellement, ce qui fait qu'une recherche aboutit en moyenne après 378989/2 comparaisons, alors qu'une "recherche dichotomique" (que l'on ne peut appliquer qu'à un ensemble ordonné, mais là c'est le cas) ne requiert que log2(378989) comparaisons (soit 18,53).
D'autre part on peut améliorer encore les performances en scindant le fichier en plusieurs plus petits.
29 janv. 2010 à 22:19
en effet il faut changer le titre et tout ce qui se rapporte à ce "brevet" dans la soirée
merci
29 janv. 2010 à 19:50
Moi, j'vais faire encore plus rapide :
5. On n'utilise pas de noms copyrightés tels que "Scrabble", "Monopoly", etc.
Ces sources seront supprimées pour éviter des problèmes juridiques.
Source : http://www.phpcs.com/reglement.aspx
29 janv. 2010 à 17:01
Quelques commentaires sur ce qui me saute aux yeux :
- Pourquoi ne pas mettre tous tes styles dans ta feuille de style ?
- est dépreciée, de même que
- Peut-être séparé le traitement de l'affichage
- Doctype
- Indentation pour faciliter la lecture de ton code
J'ai dû faire vite, désolé.