Retour de la fonction bsearch
Le
candide
Bonjour,
Juste un avis perso : le retour de la fonction bsearch est peu exploitable.
Bien souvent, face à une liste croissante, on ne se préoccupe pas
essentiellement de savoir si un élément donné s'y trouve ou ne s'y
trouve pas, on cherche à savoir où il est placé dans la liste (et
éventuellement hors de la liste à gauche ou à droite). Or, quel que soit
l'algorithme utilisé par bsearch (recherche séquentielle ou
dichotomique), bsearch serait en mesure sans coût supplémentaire
excessif de donner cette position. Hélas bsearch se contente de donner
une réponse binaire. Et je trouve particulièrement agaçant d'avoir à me
recoder un truc aussi classique qu'une recherche dichotomique, pas vous ?
Juste un avis perso : le retour de la fonction bsearch est peu exploitable.
Bien souvent, face à une liste croissante, on ne se préoccupe pas
essentiellement de savoir si un élément donné s'y trouve ou ne s'y
trouve pas, on cherche à savoir où il est placé dans la liste (et
éventuellement hors de la liste à gauche ou à droite). Or, quel que soit
l'algorithme utilisé par bsearch (recherche séquentielle ou
dichotomique), bsearch serait en mesure sans coût supplémentaire
excessif de donner cette position. Hélas bsearch se contente de donner
une réponse binaire. Et je trouve particulièrement agaçant d'avoir à me
recoder un truc aussi classique qu'une recherche dichotomique, pas vous ?
Je ne comprends pas. bsearch retourne un pointeur vers l'element trouve.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
??
Vous ne confondriez pas le retour de bsearch(), un void* pointant vers
l'élément ou un élément trouvé, ou (void*) si pas trouvé, et le
prototype de la fonction de comparaison à fournir à bsearch() ?
--
Pierre Maurette
candide, le 01/10/2008 a écrit :
??
Vous ne confondriez pas le retour de bsearch(), un void* pointant vers
l'élément ou un élément trouvé, ou (void*)0 si pas trouvé, et le
prototype de la fonction de comparaison à fournir à bsearch() ?
--
Pierre Maurette
Non, je ne confonds pas. La réponse de bsearch est binaire dans la
mesure où si la clé n'est pas trouvée elle renvoie NULL et elle renvoie
la position de la clé dans le cas inverse.
Mais dans la pratique, ainsi au hasard :
*) exemple 1 : on a une grande liste de nombres premiers et on eut
l'utiliser pour écrire une fonction nextPrime ;
*) exemple 2 : on veut écrire un solveur de Boggle
quand on a une liste triée, on cherche souvent non pas à savoir si la
clé est ou pas dans la liste mais à connaitre le ou les voisins
immédiats de la clé. Pour répondre à cette question, on doit faire
exactement ce que fait l'algorithme bsearch (en supposant qu'il s'agisse
d'une recherche dichotomique ce que d'ailleurs la norme n'impose pas)
donc le potentiel de l'implémentation bsearch n'est pas exploité. Ce
n'est même pas que l'interface soit à reprendre, c'est plutôt le retour
de bsearch qui ne me convient pas.
Sauf que bsearch ne travaille pas avec des listes, mais avec des
tableaux, et qu'avec l'arithméique des pointeurs, quand tu as
l'adresse d'une donnée (et son type), ben, t'a les voisins...
D'ailleurs, une recherche dichotomique dans une liste, ça
va être dur...
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Je crois qu'il voudrait que bsearch se comporte d'une maniere similaire a
std::equal_range en C++; mais il faut retourner plus qu'une simple
position.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je ne sais pas ce qu'il veut exactement, mais bon, c'est quand même
pas très difficile à faire à partir de bsearch. Un coup de ++, un coup de --...
Marc
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
J'ai employé le terme de liste dans un sens informel, ça ne change rien
au problème, ce qui compte c'est qu'on ait une succession d'"objets" (au
sens informel encore).
Je vois pas ce que l'arithmétique des pointeurs vient faire là-dedans.
Tu n'as pas compris ma question.
Bien sûr que j'ai les voisins si bsearch répond != NULL. Mais si bsearch
te renvoie NULL, c'est quoi le voisin ?????? pourtant il existe et dans
sa recherche, bsearch le rencontre mais dans sa réponse, il l'ignore.
Je reprends l'exemple idiot déjà cité : je veux implémenter nextPrime à
partir de la liste suivante
2, 3, 5, 7, 11, 13, 17, 19, 23, 29,
31, 37, 41, 43, 47, 53, 59, 61, 67, 71,
73, 79, 83, 89, 97.
Je demande à bsearch si 50 est dans la liste, il va faire une recherche
dichotomique et il va finir par voir que 50 est entre t[14] et t[15].
Mais il va me répondre NULL, ce qui est une perte d'information car s'il
me répondait par exemple 15 (enfin plutôt un pointeur vers l'élément
numéroté 15 du tableau des nombres premiers ci-dessus), je saurais
immédiatement si 50 est dans le tableau (suffit de comparer 50 avec
t[15]) mais surtout j'aurais une information beaucoup plus consistante
que NULL ! je saurais que nextPrime(50)=t[15], et ça pour le même prix.
Ce que je dis là ne me parait pas bien compliqué à comprendre.
Tu fais une fixation ou quoi ? Avant d'aller faire tes courses au
supermarché, tu te fais un _tableau_ de courses ? Bon moi je fais une
liste. C'est quoi une liste pour toi ? une liste chainée ? Ça reste une
succession d'objets, je vois donc pas le problème.
Si la valeur n'est pas trouvee, faire ++ et -- sur NULL, ca marche pas trop
bien.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
D'après la doc C++ que je viens de regarder, c'est plus ou moins ça.
Une position suffit (l'ordre est total) après c'est une question de
convention (le plus ou le plus grand, peu importe). Mais surtout, et
c'est ça que j'ai du mal à comprendre, c'est que ça ne coûterait _rien
de plus_ à bsearch de nous sortir cette position puisque forcément il la
calcule.