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 ?
bsearch cherche sur un tableau. Donc en faisant (pointeur trouvé - pointeur base ) / taille element tu auras la position.
candide a écrit
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 ?
bsearch cherche sur un tableau. Donc en faisant (pointeur trouvé -
pointeur base ) / taille element tu auras la position.
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 ?
bsearch cherche sur un tableau. Donc en faisant (pointeur trouvé - pointeur base ) / taille element tu auras la position.
Antoine Leca
En news:48ed3074$0$2497$, candide va escriure:
Antoine Leca a écrit :
En news:48e6139f$0$10248$, candide va escriure: Non, il y a des différences entre les deux.
Pour mémoire, il s'agissait de
: extern int f(), (*fp)(), (*apf[])(double);
par opposition à
: [N'auraient-ils pas dû écrire : extern int f(void), (*fp)(void);
La plus évidente
"évident" dis-tu ?
Oui, c'est un comparatif, les autres différences sont _moins_ évidentes.
est que tu peux écrire
int f(a,b) int a,b; { return f(a) + fp(b); }
C jurassique ou crétacé inférieur ? ;)
???
Moi Cro-Magnon (= /homo sapiens sapiens/), pas encore apparu à l'ère secondaire...
Antoine
En news:48ed3074$0$2497$426a34cc@news.free.fr, candide va escriure:
Antoine Leca a écrit :
En news:48e6139f$0$10248$426a74cc@news.free.fr, candide va escriure:
Non, il y a des différences entre les deux.
Pour mémoire, il s'agissait de
: extern int f(), (*fp)(), (*apf[])(double);
par opposition à
: [N'auraient-ils pas dû écrire
: extern int f(void), (*fp)(void);
La plus évidente
"évident" dis-tu ?
Oui, c'est un comparatif, les autres différences sont _moins_ évidentes.
est que tu peux écrire
int f(a,b) int a,b; { return f(a) + fp(b); }
C jurassique ou crétacé inférieur ? ;)
???
Moi Cro-Magnon (= /homo sapiens sapiens/), pas encore apparu à l'ère
secondaire...
Tous les compilateurs que j'ai essayé me sortent un message d'avertissement en mode par défaut (et après avoir substitué le ; par :).
Antoine
Alain Montfranc
Antoine Leca a écrit
En news:, Alain Montfranc va escriure:
(result==NULL)?-1;result-base
Depuis quand -1 et result-base sont congruents ?
Tous les compilateurs que j'ai essayé me sortent un message d'avertissement en mode par défaut (et après avoir substitué le ; par :).
Antoine
C'etait juste une reponse rapide pour dire qu'il y avait moyen de faire ce que le posteur initial demandait en testant la valeur null... Bon d'accord j'ai fait un lapsus calami, mais le principe reste le même. (result==NULL)?-1:(int)(result-base) par exemple.
Bon apres on peut renvoyer une valeur hors plage (comme -1), lever une exception, appeler le concierge ou ce qu'on veut pour signaler que le resultat n'a pas été trouvé.
Antoine Leca a écrit
En news:mn.9a7a7d8a5164c2d8.51095@x.con, Alain Montfranc va escriure:
(result==NULL)?-1;result-base
Depuis quand -1 et result-base sont congruents ?
Tous les compilateurs que j'ai essayé me sortent un message d'avertissement
en mode par défaut (et après avoir substitué le ; par :).
Antoine
C'etait juste une reponse rapide pour dire qu'il y avait moyen de faire
ce que le posteur initial demandait en testant la valeur null... Bon
d'accord j'ai fait un lapsus calami, mais le principe reste le même.
(result==NULL)?-1:(int)(result-base) par exemple.
Bon apres on peut renvoyer une valeur hors plage (comme -1), lever une
exception, appeler le concierge ou ce qu'on veut pour signaler que le
resultat n'a pas été trouvé.
Tous les compilateurs que j'ai essayé me sortent un message d'avertissement en mode par défaut (et après avoir substitué le ; par :).
Antoine
C'etait juste une reponse rapide pour dire qu'il y avait moyen de faire ce que le posteur initial demandait en testant la valeur null... Bon d'accord j'ai fait un lapsus calami, mais le principe reste le même. (result==NULL)?-1:(int)(result-base) par exemple.
Bon apres on peut renvoyer une valeur hors plage (comme -1), lever une exception, appeler le concierge ou ce qu'on veut pour signaler que le resultat n'a pas été trouvé.
Jean-Marc Bourguet
Alain Montfranc writes:
Antoine Leca a écrit > En news:, Alain Montfranc va escriure: >> (result==NULL)?-1;result-base > > Depuis quand -1 et result-base sont congruents ? > > Tous les compilateurs que j'ai essayé me sortent un message d'avertissement > en mode par défaut (et après avoir substitué le ; par :). > > > Antoine
C'etait juste une reponse rapide pour dire qu'il y avait moyen de faire ce que le posteur initial demandait en testant la valeur null...
Ce qu'il demandait -- ca a ete clarifie dans la suite du fil -- c'est que bsearch retourne un pointeur vers le plus grand element inferieur a la cle quand celle-ci n'est pas dans la table plutot que NULL.
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
Alain Montfranc <x@x.con> writes:
Antoine Leca a écrit
> En news:mn.9a7a7d8a5164c2d8.51095@x.con, Alain Montfranc va escriure:
>> (result==NULL)?-1;result-base
>
> Depuis quand -1 et result-base sont congruents ?
>
> Tous les compilateurs que j'ai essayé me sortent un message d'avertissement
> en mode par défaut (et après avoir substitué le ; par :).
>
>
> Antoine
C'etait juste une reponse rapide pour dire qu'il y avait moyen de faire ce
que le posteur initial demandait en testant la valeur null...
Ce qu'il demandait -- ca a ete clarifie dans la suite du fil -- c'est que
bsearch retourne un pointeur vers le plus grand element inferieur a la cle
quand celle-ci n'est pas dans la table plutot que NULL.
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
Antoine Leca a écrit > En news:, Alain Montfranc va escriure: >> (result==NULL)?-1;result-base > > Depuis quand -1 et result-base sont congruents ? > > Tous les compilateurs que j'ai essayé me sortent un message d'avertissement > en mode par défaut (et après avoir substitué le ; par :). > > > Antoine
C'etait juste une reponse rapide pour dire qu'il y avait moyen de faire ce que le posteur initial demandait en testant la valeur null...
Ce qu'il demandait -- ca a ete clarifie dans la suite du fil -- c'est que bsearch retourne un pointeur vers le plus grand element inferieur a la cle quand celle-ci n'est pas dans la table plutot que NULL.
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
Alain Montfranc
Jean-Marc Bourguet a écrit
Alain Montfranc writes:
Antoine Leca a écrit
En news:, Alain Montfranc va escriure:
(result==NULL)?-1;result-base
Depuis quand -1 et result-base sont congruents ?
Tous les compilateurs que j'ai essayé me sortent un message d'avertissement en mode par défaut (et après avoir substitué le ; par :).
Antoine
C'etait juste une reponse rapide pour dire qu'il y avait moyen de faire ce que le posteur initial demandait en testant la valeur null...
Ce qu'il demandait -- ca a ete clarifie dans la suite du fil -- c'est que bsearch retourne un pointeur vers le plus grand element inferieur a la cle quand celle-ci n'est pas dans la table plutot que NULL.
A+
Ok, le "on cherche à savoir où il est placé dans la liste " es-tait ambigu
Désolé
Jean-Marc Bourguet a écrit
Alain Montfranc <x@x.con> writes:
Antoine Leca a écrit
En news:mn.9a7a7d8a5164c2d8.51095@x.con, Alain Montfranc va escriure:
(result==NULL)?-1;result-base
Depuis quand -1 et result-base sont congruents ?
Tous les compilateurs que j'ai essayé me sortent un message d'avertissement
en mode par défaut (et après avoir substitué le ; par :).
Antoine
C'etait juste une reponse rapide pour dire qu'il y avait moyen de faire ce
que le posteur initial demandait en testant la valeur null...
Ce qu'il demandait -- ca a ete clarifie dans la suite du fil -- c'est que
bsearch retourne un pointeur vers le plus grand element inferieur a la cle
quand celle-ci n'est pas dans la table plutot que NULL.
A+
Ok, le "on cherche à savoir où il est placé dans la liste " es-tait
ambigu
Tous les compilateurs que j'ai essayé me sortent un message d'avertissement en mode par défaut (et après avoir substitué le ; par :).
Antoine
C'etait juste une reponse rapide pour dire qu'il y avait moyen de faire ce que le posteur initial demandait en testant la valeur null...
Ce qu'il demandait -- ca a ete clarifie dans la suite du fil -- c'est que bsearch retourne un pointeur vers le plus grand element inferieur a la cle quand celle-ci n'est pas dans la table plutot que NULL.
A+
Ok, le "on cherche à savoir où il est placé dans la liste " es-tait ambigu
Désolé
Charlie Gordon
"Jean-Marc Bourguet" a écrit dans le message de news:
Alain Montfranc writes:
Antoine Leca a écrit > En news:, Alain Montfranc va escriure: >> (result==NULL)?-1;result-base > > Depuis quand -1 et result-base sont congruents ? > > Tous les compilateurs que j'ai essayé me sortent un message > d'avertissement > en mode par défaut (et après avoir substitué le ; par :). > > > Antoine
C'etait juste une reponse rapide pour dire qu'il y avait moyen de faire ce que le posteur initial demandait en testant la valeur null...
Ce qu'il demandait -- ca a ete clarifie dans la suite du fil -- c'est que bsearch retourne un pointeur vers le plus grand element inferieur a la cle quand celle-ci n'est pas dans la table plutot que NULL.
Ou plutôt vers le plus petit élément supérieur ou égal à la clé. Cela permet de gérer correctement les cas particuliers suivants: - tableau vide - clé inférieure au premier élément - clé supérieure au dernier élément du tableau (il est loisible de renvoyer l'adresse &array[array_size]) - clés dupliquées dans le tableau, il est préférable de renvoyer l'adresse du premier élément du tableau qui a la bonne clé.
Un indicateur booléen qui précise si la clé a été trouvée ou pas serait bien utile aussi.
Pouvoir retouner les deux efficacement sans recours à un pointeur ou une structure serait une extension du C particulièrement sympathique ;-)
-- Chqrlie.
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de news:
pxbd4hvqk5v.fsf@news.bourguet.org...
Alain Montfranc <x@x.con> writes:
Antoine Leca a écrit
> En news:mn.9a7a7d8a5164c2d8.51095@x.con, Alain Montfranc va escriure:
>> (result==NULL)?-1;result-base
>
> Depuis quand -1 et result-base sont congruents ?
>
> Tous les compilateurs que j'ai essayé me sortent un message
> d'avertissement
> en mode par défaut (et après avoir substitué le ; par :).
>
>
> Antoine
C'etait juste une reponse rapide pour dire qu'il y avait moyen de faire
ce
que le posteur initial demandait en testant la valeur null...
Ce qu'il demandait -- ca a ete clarifie dans la suite du fil -- c'est que
bsearch retourne un pointeur vers le plus grand element inferieur a la cle
quand celle-ci n'est pas dans la table plutot que NULL.
Ou plutôt vers le plus petit élément supérieur ou égal à la clé. Cela
permet de gérer correctement les cas particuliers suivants:
- tableau vide
- clé inférieure au premier élément
- clé supérieure au dernier élément du tableau (il est loisible de renvoyer
l'adresse &array[array_size])
- clés dupliquées dans le tableau, il est préférable de renvoyer l'adresse
du premier élément du tableau qui a la bonne clé.
Un indicateur booléen qui précise si la clé a été trouvée ou pas serait bien
utile aussi.
Pouvoir retouner les deux efficacement sans recours à un pointeur ou une
structure serait une extension du C particulièrement sympathique ;-)
"Jean-Marc Bourguet" a écrit dans le message de news:
Alain Montfranc writes:
Antoine Leca a écrit > En news:, Alain Montfranc va escriure: >> (result==NULL)?-1;result-base > > Depuis quand -1 et result-base sont congruents ? > > Tous les compilateurs que j'ai essayé me sortent un message > d'avertissement > en mode par défaut (et après avoir substitué le ; par :). > > > Antoine
C'etait juste une reponse rapide pour dire qu'il y avait moyen de faire ce que le posteur initial demandait en testant la valeur null...
Ce qu'il demandait -- ca a ete clarifie dans la suite du fil -- c'est que bsearch retourne un pointeur vers le plus grand element inferieur a la cle quand celle-ci n'est pas dans la table plutot que NULL.
Ou plutôt vers le plus petit élément supérieur ou égal à la clé. Cela permet de gérer correctement les cas particuliers suivants: - tableau vide - clé inférieure au premier élément - clé supérieure au dernier élément du tableau (il est loisible de renvoyer l'adresse &array[array_size]) - clés dupliquées dans le tableau, il est préférable de renvoyer l'adresse du premier élément du tableau qui a la bonne clé.
Un indicateur booléen qui précise si la clé a été trouvée ou pas serait bien utile aussi.
Pouvoir retouner les deux efficacement sans recours à un pointeur ou une structure serait une extension du C particulièrement sympathique ;-)
