cerhu > comp.lang.* > comp.lang.c

candide (01/10/2008, 12h39)
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 ?
Jean-Marc Bourguet (01/10/2008, 12h53)
candide <candide> writes:

> Juste un avis perso : le retour de la fonction bsearch est peu exploitable.
> 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+
Pierre Maurette (01/10/2008, 13h04)
candide, le 01/10/2008 a écrit :
> Bonjour,
> Juste un avis perso : le retour de la fonction bsearch est peu exploitable.
> 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 ?


??
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 (01/10/2008, 13h14)
(supersedes <mn.0b107d8a5a0dddca.79899>)

candide, le 01/10/2008 a écrit :
> Bonjour,
> Juste un avis perso : le retour de la fonction bsearch est peu exploitable.
> 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 ?


??
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() ?
candide (01/10/2008, 14h15)
Pierre Maurette 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() ?


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.
Marc Boyer (01/10/2008, 14h30)
On 2008-10-01, candide <candide> wrote:
> Pierre Maurette a écrit :
> 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é.


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
Jean-Marc Bourguet (01/10/2008, 14h46)
Marc Boyer <Marc.Boyer> writes:

> On 2008-10-01, candide <candide> wrote:
> 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...


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+
Marc Boyer (01/10/2008, 15h08)
On 2008-10-01, Jean-Marc Bourguet <jm> wrote:
> Marc Boyer <Marc.Boyer> writes:
> 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.


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
candide (01/10/2008, 15h10)
Marc Boyer a écrit :

> Sauf que bsearch ne travaille pas avec des listes,


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).

> 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...


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.

> D'ailleurs, une recherche dichotomique dans une liste, ça
> va être dur...


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.
Jean-Marc Bourguet (01/10/2008, 15h13)
Marc Boyer <Marc.Boyer> writes:

> On 2008-10-01, Jean-Marc Bourguet <jm> wrote:
> 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 --...


Si la valeur n'est pas trouvee, faire ++ et -- sur NULL, ca marche pas trop
bien.

A+
candide (01/10/2008, 15h17)
Jean-Marc Bourguet a écrit :

> Je crois qu'il voudrait que bsearch se comporte d'une maniere similaire a
> std::equal_range en C++;


D'après la doc C++ que je viens de regarder, c'est plus ou moins ça.

> mais il faut retourner plus qu'une simple
> position.


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.
candide (01/10/2008, 15h18)
Jean-Marc Bourguet a écrit :

> Si la valeur n'est pas trouvee, faire ++ et -- sur NULL, ca marche pas trop
> bien.


Ah, enfin !
Jean-Marc Bourguet (01/10/2008, 15h26)
candide <candide> writes:

> Jean-Marc Bourguet a écrit :
> 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.


Un equivalent de lower_bound ou upper_bound alors?

Ca couterait a l'utilisation normale (chez moi; j'utilise des structures
plus complexes qu'un tableau trie si ce que tu desires est necessaire; note
que les fonctions du C++ sont valables pour autre chose que des tableaux)
un test supplementaire pour savoir si ce que bsearch retourne est un
element trouve ou bien la position ou il faudrait mettre un element non
trouve.

A+
Marc Boyer (01/10/2008, 15h43)
On 2008-10-01, candide <candide> wrote:
> Marc Boyer a écrit :
>> Sauf que bsearch ne travaille pas avec des listes,

> 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).


Et pourtant ça change plein de choses, en algorithmique déjà, et en C
encore plus.

> 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.


Ah, c'était ça ta demande.

> Ce que je dis là ne me parait pas bien compliqué à comprendre.


Ce que tu dis dans ce message ci en effet. Mais je n'avais
pas compris avec les messages précédents. Et Jean-marc non plus
puisque std::range_equal ne correspond pas à ce que tu demandes.

>> D'ailleurs, une recherche dichotomique dans une liste, ça
>> va être dur...

> Tu fais une fixation ou quoi ?


Non, mais j'ai des réflexes d'informaticien.

> Avant d'aller faire tes courses au
> supermarché, tu te fais un _tableau_ de courses ? Bon moi je fais une
> liste.


Oui, mais chaque domaine spécialise un certain nombre de termes.
En info, une liste, c'est une liste chainée.
Un truc qui va de [0,n-1] dans T (avec T un type), sans présumer
de la représentation interne, on appelle plutôt ça une séquence
il me semble.

> C'est quoi une liste pour toi ? une liste chainée ? Ça reste une
> succession d'objets, je vois donc pas le problème.


Ben, le problème de faire une recherche dichotomique dans une
liste.

Marc Boyer
Marc Boyer (01/10/2008, 15h49)
On 2008-10-01, candide <candide> wrote:
> Marc Boyer a écrit :
>> Sauf que bsearch ne travaille pas avec des listes,

> 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).


Et pourtant ça change plein de choses, en algorithmique déjà, et en C
encore plus.

> 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.


Ah, c'était ça ta demande.

> Ce que je dis là ne me parait pas bien compliqué à comprendre.


Ce que tu dis dans ce message ci en effet. Mais je n'avais
pas compris avec les messages précédents.

>> D'ailleurs, une recherche dichotomique dans une liste, ça
>> va être dur...

> Tu fais une fixation ou quoi ?


Non, mais j'ai des réflexes d'informaticien quand je suis
sur fclc.

> Avant d'aller faire tes courses au
> supermarché, tu te fais un _tableau_ de courses ? Bon moi je fais une
> liste.


Oui, mais chaque domaine spécialise un certain nombre de termes.
En info, une liste, c'est une liste chainée.
Un truc qui va de [0,n-1] dans T (avec T un type), sans présumer
de la représentation interne, on appelle plutôt ça une séquence
il me semble.

> C'est quoi une liste pour toi ? une liste chainée ? Ça reste une
> succession d'objets, je vois donc pas le problème.


Ben, le problème de faire une recherche dichotomique dans une
liste.

Marc Boyer

Discussions similaires
Problème avec bsearch()

bsearch

Exception avec bsearch

Personne ne sait pour l'exception de bsearch ?


Fuseau horaire GMT +2. Il est actuellement 12h15. | Privacy Policy