C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  [Calcul] Problème étrange Goto page 1, 2, 3, 4, 5  Next          C++Talk.NET Forum Index -> C++ (French) View previous topic :: View next topic   Author Message Rincevent Guest Posted: Mon May 24, 2004 8:26 am    Post subject: [Calcul] Problème étrange Bonjour à tous, g un gros problème dans mon programme C++. Voilà g 3 entier a,b et c Je souhaite calculer la partie entière de (a/b)*c J'utilise pour cela la fonction floor() de <cmath> Or deux problèmes se présentent : 1) Le compilateur renvoie 0 lorsque je lui demande de calculer (a/b)*c (et ce, alors que les valeurs de a,b,c ne devraient pas donner un tel résultat) 2) Le compilateur m'insulte lorsque j'essaie d'appliquer la fonction floor() à (a/b)*c (motif : l'argument n'est pas un double...) - Je suppose qu'il doit exister une fonction pour convertir des rapports d'entier en double, non ? - Et inversement pour passer d'un double codant un entier --> en type int ? - floor() attend un double comme argument... Soit mais quel est le type duy résultat ? un double ? un int ? - comment résoudre cet épineux problème de façon élégante ??? ;-) Quelqu'un peut-t-il m'aider ? Merci d'avance ! Rincevent Back to top Samuel Krempp Guest Posted: Mon May 24, 2004 10:17 am    Post subject: Re: [Calcul] Problème étrange le Monday 24 May 2004 10:26, [email]rincevent (AT) nospam (DOT) fr[/email] écrivit : Quote: Bonjour à tous, g un gros problème dans mon programme C++. Voilà g 3 entier a,b et c Je souhaite calculer la partie entière de (a/b)*c J'utilise pour cela la fonction floor() de <cmath Or deux problèmes se présentent : 1) Le compilateur renvoie 0 lorsque je lui demande de calculer (a/b)*c (et ce, alors que les valeurs de a,b,c ne devraient pas donner un tel résultat) la division de nombres entiers correspond à la division euclidienne (en ne prenant que le quotient, pas le reste) donc 3/5 == 0. C'est comme ça dans bcp de langages, il faut le savoir. Quote: 2) Le compilateur m'insulte lorsque j'essaie d'appliquer la fonction floor() à (a/b)*c (motif : l'argument n'est pas un double...) je crois que c'est pas ça que te dit le compilo (ou alors il est bizarre) Tu dois sûrement faire un truc comme : int n = floor(a/b*c); et c'est dans le '=' qu'il y a problème : un double à droite, un int à gauche. solution : int n = static_cast Quote: - Je suppose qu'il doit exister une fonction pour convertir des rapports d'entier en double, non ? un "rapport d'entier" est un entier. et ça se convertit donc automatiquement en double si besoin. Quote: - Et inversement pour passer d'un double codant un entier --> en type int ? - floor() attend un double comme argument... Soit mais quel est le type duy résultat ? un double ? un int ? tu n'as aucune doc ? il faudrait au moins que tu aies des références des fctions de la librairie C et C++ si tu veux arriver à qque chose ... http://www.dinkumware.com/manuals/reader.aspx?lib=cpl&h=math.html#floor -- Sam Back to top Django Janny Guest Posted: Mon May 24, 2004 10:34 am    Post subject: Re: [Calcul] Problème étrange Bonjour, Il faut, je pense, que tu convertisse tes entiers en double au moment de ton opération : ((double) a / (double) b) * (double) c a partir de la ton résultat sera != de 0 et tu pour utiliser floor évidemment dans le cas d'un calcul avec plusieurs utilisation des versions double de a,b et c je te conseille vivement d'utiliser de nouvelles variables (de type double...) A+ Django "Rincevent" <rincevent (AT) nospam (DOT) fr> a écrit dans le message de news:c8sbjv$cug$1 (AT) news-reader1 (DOT) wanadoo.fr... Quote: Bonjour à tous, g un gros problème dans mon programme C++. Voilà g 3 entier a,b et c Je souhaite calculer la partie entière de (a/b)*c J'utilise pour cela la fonction floor() de <cmath Or deux problèmes se présentent : 1) Le compilateur renvoie 0 lorsque je lui demande de calculer (a/b)*c (et ce, alors que les valeurs de a,b,c ne devraient pas donner un tel résultat) 2) Le compilateur m'insulte lorsque j'essaie d'appliquer la fonction floor() à (a/b)*c (motif : l'argument n'est pas un double...) - Je suppose qu'il doit exister une fonction pour convertir des rapports d'entier en double, non ? - Et inversement pour passer d'un double codant un entier --> en type int ? - floor() attend un double comme argument... Soit mais quel est le type duy résultat ? un double ? un int ? - comment résoudre cet épineux problème de façon élégante ??? ;-) Quelqu'un peut-t-il m'aider ? Merci d'avance ! Rincevent Back to top Pierre Maurette Guest Posted: Mon May 24, 2004 1:16 pm    Post subject: Re: [Calcul] Problème étrange "Rincevent" <rincevent (AT) nospam (DOT) fr> typa: Quote: Bonjour à tous, g un gros problème dans mon programme C++. Voilà g 3 entier a,b et c Je souhaite calculer la partie entière de (a/b)*c J'utilise pour cela la fonction floor() de <cmath Or deux problèmes se présentent : 1) Le compilateur renvoie 0 lorsque je lui demande de calculer (a/b)*c (et ce, alors que les valeurs de a,b,c ne devraient pas donner un tel résultat) Comment faites-vous pour mener ce calcul de tête ou avec papier-crayon ? Commencez-vous par diviser ? Avez vous besoin de flottants pour traiter le problème ? Si vous faites : int resultat = (a*c)/b; vous traitez exactement le problème tel qu'il est posé, c'est à dire comme un problème d'entiers. Je vous laisse, par rapport à ce que vous souhaitez, juger de l'oportunité d'un ajustement par floor(). Personnellement, je ne l'utiliserais pas, puisque c'est une fonction double. Mais bon, personnellement, je trouve regrettable l'utilisation de / pour la division entière, j'aime bien le couple div mod du Pascal. Il est aussi rapide et plus naturel de tester le signe (et malheureusement je pense qu'il faudra également tester le résultat exact, le cas ou a*c est divisible par b) pour ajuster le résultat. Mais le résultat direct correspond à l'idée que je me fais d'une partie entière. Quote: 2) Le compilateur m'insulte lorsque j'essaie d'appliquer la fonction floor() à (a/b)*c (motif : l'argument n'est pas un double...) En C++, floor() est surchargée pour admettre plusieurs prototypes dont float floor(float) et sans doute double floor(double). Je ne sais pas ce qui est dans la norme et ce qui est dans les implémentations, mais peu importe. L'instruction: a = floor((a*c)/b); //int a, b, c; ne lui permet peut-être pas de résoudre la surcharge. a = floor(((double)a*c)/b); résoud le problème (inutile de caster toutes les variables). Utilisez static_cast Quote: - Je suppose qu'il doit exister une fonction pour convertir des rapports d'entier en double, non ? - Et inversement pour passer d'un double codant un entier --> en type int ? - floor() attend un double comme argument... Soit mais quel est le type duy résultat ? un double ? un int ? - comment résoudre cet épineux problème de façon élégante ??? En téléchargeant un peu de documentation ? Pierre Back to top Jean-Noël Mégoz Guest Posted: Mon May 24, 2004 3:30 pm    Post subject: Re: [Calcul] Problème étrange ----- Original Message ----- From: "Rincevent" <rincevent (AT) nospam (DOT) fr> Newsgroups: fr.comp.lang.c++ Sent: Monday, May 24, 2004 10:26 AM Subject: [Calcul] Problème étrange Quote: Bonjour à tous, g un gros problème dans mon programme C++. Voilà g 3 entier a,b et c Je souhaite calculer la partie entière de (a/b)*c J'utilise pour cela la fonction floor() de Or deux problèmes se présentent : 1) Le compilateur renvoie 0 lorsque je lui demande de calculer (a/b)*c (et ce, alors que les valeurs de a,b,c ne devraient pas donner un tel résultat) Comme déjà dit par qq'un, si a/b = 0, alors forcément (a/b)*c sera nul aussi. D'où ce petit conseil que je me suis toujours félicité de suivre : autant que possible, faire les multiplications avant les divisions : calcule (a*c)/b, plutôt. Dans le cas de réels, cette façon de faire donne en plus résultat plus précis. Quote: 2) Le compilateur m'insulte lorsque j'essaie d'appliquer la fonction floor() à (a/b)*c (motif : l'argument n'est pas un double...) Il suffit de caster l'un des entier (déjà dit aussi) : floor((a*c)/(double) b). Note que caster un seul entier suffit pour que toute l'opération donne un nombre flottant. Back to top Rincevent Guest Posted: Mon May 24, 2004 4:11 pm    Post subject: Re: [Calcul] Problème étrange "Rincevent" <rincevent (AT) nospam (DOT) fr> a écrit dans le message de news: c8sbjv$cug$1 (AT) news-reader1 (DOT) wanadoo.fr... Quote: Bonjour à tous, g un gros problème dans mon programme C++. Voilà g 3 entier a,b et c Je souhaite calculer la partie entière de (a/b)*c Pour info, mon programme doit effectuer (en simplifiant) ces n processus : 1) on fixe N le nb de niveaux de gris differents d'une image (N=256) int N = 256; 2) On obtient, par un procédé qui n'est pas décrit ici, une image M representée par une matrice dont les éléments sont des entiers compris entre 0 et 255 (donc 256 valeurs en tout) 3) Après traitement, je suis en mesure de déterminer les particules de l'image, càd les ensembles de points connexes par arcs. Je souhaite "colorier" ces particules en fonctions de leurs tailles. 4) Pour cela, on demande à l'utilisateur combien de classe de particules il souhaite (classe : au sens mathématique). Ce nombre est stocké dans P. P est également un entier ! 5) Pour la particules appartenant à la k-ème classe, sa couleur est donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas forcément un entier, on prends donc la partie entière pour être sur... Voilà, ça c'est la description théorique de ce que je dois faire. C'est donc le codage C++ de la partie 5) qui me pose problème... Je vais tester de ce pas vos différentes solutions. Merci pour vos contributions ! Rincevent Back to top Pierre Maurette Guest Posted: Mon May 24, 2004 4:57 pm    Post subject: Re: [Calcul] Problème étrange "Rincevent" <rincevent (AT) nospam (DOT) fr> typa: Quote: "Rincevent" <rincevent (AT) nospam (DOT) fr> a écrit dans le message de news: [...] 1) on fixe N le nb de niveaux de gris differents d'une image (N=256) int N = 256; 2) On obtient, par un procédé qui n'est pas décrit ici, une image M representée par une matrice dont les éléments sont des entiers compris entre 0 et 255 (donc 256 valeurs en tout) 3) Après traitement, je suis en mesure de déterminer les particules de l'image, càd les ensembles de points connexes par arcs. Je souhaite "colorier" ces particules en fonctions de leurs tailles. 4) Pour cela, on demande à l'utilisateur combien de classe de particules il souhaite (classe : au sens mathématique). Ce nombre est stocké dans P. P est également un entier ! 5) Pour la particules appartenant à la k-ème classe, sa couleur est donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas forcément un entier, on prends donc la partie entière pour être sur... Tous vos entierzs sont positifs, déclarez-les donc unsigned. N est une constante, apparemment, ainsi que P pendant le calcul. Votre problème esr ainsi simplifié : int resultat = (k*N)/P; //c'est tout ou même int resultat = (k<</P; que devrait vous générer le compilateur si vous avez déclaré N const. Pierre Back to top drkm Guest Posted: Mon May 24, 2004 6:09 pm    Post subject: Re: [Calcul] Problème étrange Pierre Maurette <maurette.pierre (AT) free (DOT) fr> writes: Quote: "Rincevent" <rincevent (AT) nospam (DOT) fr> typa: Bonjour à tous, g un gros problème dans mon programme C++. Voilà g 3 entier a,b et c Je souhaite calculer la partie entière de (a/b)*c J'utilise pour cela la fonction floor() de <cmath Or deux problèmes se présentent : 1) Le compilateur renvoie 0 lorsque je lui demande de calculer (a/b)*c (et ce, alors que les valeurs de a,b,c ne devraient pas donner un tel résultat) Comment faites-vous pour mener ce calcul de tête ou avec papier-crayon ? Commencez-vous par diviser ? Avez vous besoin de flottants pour traiter le problème ? Si vous faites : int resultat = (a*c)/b; vous traitez exactement le problème tel qu'il est posé, c'est à dire comme un problème d'entiers. Et qu'advient-il lorsque a == std::numeric_limits< int >::max() ; ? En fait, je suis en train de me demander s'il n'y a pas conversion du résultat de « a * c » en un long int dans ce cas, mais je ne pense pas ; et ce ne ferait que déplacer le problème. Tandis que int result = static_cast< int >( static_cast< double >( a ) / b * c ) ; gère correctement le problème. Pour ce qui est de la promotion en long int, je n'ai trouvé que 4.5/1. Je ne suis pas certain qu'il s'agit du bon paragraphe, mais si c'est le cas, cette promotion en long int n'existe pas (ce que je pense). --drkm Back to top kanze@gabi-soft.fr Guest Posted: Tue May 25, 2004 6:59 am    Post subject: Re: [Calcul] Problème étrange Samuel Krempp <krempp (AT) crans (DOT) truc.en.trop.ens-cachan.fr> wrote Quote: le Monday 24 May 2004 10:26, [email]rincevent (AT) nospam (DOT) fr[/email] écrivit : [...] Quote: 2) Le compilateur m'insulte lorsque j'essaie d'appliquer la fonction floor() à (a/b)*c (motif : l'argument n'est pas un double...) je crois que c'est pas ça que te dit le compilo (ou alors il est bizarre) Tu dois sûrement faire un truc comme : int n = floor(a/b*c); et c'est dans le '=' qu'il y a problème : un double à droite, un int à gauche. solution : int n = static_cast<int>(floor((a*1.0/b) *c) ); La conversion double en int est implicite en C++. Si le compilateur émet plus d'un avertissement lors de l'affectation, ça m'étonnerait. Je crois que le problème c'est plutôt qu'en C++, floor est surchargé, pour float, double et long double. Et quand on lui passe un int, c'est ambigu, parce que le compilateur ne sait pas laquelle des trois fonctions choisir. En passant, ces surcharges cassent du code existant pré-norme, puisqu'avant la norme, quelque chose comme exp(3) était légal. L'intérêt du surcharge est évident (à mon avis, en tout cas), mais ils auraient peut-être dû ajouter des surcharges sur int, etc., pour ce genre de cas. Quote: - Je suppose qu'il doit exister une fonction pour convertir des rapports d'entier en double, non ? un "rapport d'entier" est un entier. et ça se convertit donc automatiquement en double si besoin. - Et inversement pour passer d'un double codant un entier --> en type int ? - floor() attend un double comme argument... Soit mais quel est le type duy résultat ? un double ? un int ? tu n'as aucune doc ? il faudrait au moins que tu aies des références des fctions de la librairie C et C++ si tu veux arriver à qque chose ... http://www.dinkumware.com/manuals/reader.aspx?lib=cpl&h=math.html#floor Au délà de la doc -- les fonctions mathématiques qui prenent des double renvoie des double, celles qui prenent des float renvoient des float, etc. C'est comme ça dans tous les langages que je connais. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 Back to top kanze@gabi-soft.fr Guest Posted: Tue May 25, 2004 7:11 am    Post subject: Re: [Calcul] Problème étrange "Rincevent" <rincevent (AT) nospam (DOT) fr> wrote Quote: "Rincevent" <rincevent (AT) nospam (DOT) fr> a écrit dans le message de news: c8sbjv$cug$1 (AT) news-reader1 (DOT) wanadoo.fr... g un gros problème dans mon programme C++. Voilà g 3 entier a,b et c Je souhaite calculer la partie entière de (a/b)*c Pour info, mon programme doit effectuer (en simplifiant) ces n processus : 1) on fixe N le nb de niveaux de gris differents d'une image (N=256) int N = 256; 2) On obtient, par un procédé qui n'est pas décrit ici, une image M representée par une matrice dont les éléments sont des entiers compris entre 0 et 255 (donc 256 valeurs en tout) 3) Après traitement, je suis en mesure de déterminer les particules de l'image, càd les ensembles de points connexes par arcs. Je souhaite "colorier" ces particules en fonctions de leurs tailles. 4) Pour cela, on demande à l'utilisateur combien de classe de particules il souhaite (classe : au sens mathématique). Ce nombre est stocké dans P. P est également un entier ! 5) Pour la particules appartenant à la k-ème classe, sa couleur est donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas forcément un entier, on prends donc la partie entière pour être sur... Si 0 <= k < 256 et 0 <= N <= 256 et P > 0, alors (k*N)/P donne exactement le résultat que tu veux, sans risque de débordement ni d'autres problèmes. Pour des valeurs aussi petites, laisse tomber les flottants et leurs imprécisions. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 Back to top Samuel Krempp Guest Posted: Tue May 25, 2004 7:18 am    Post subject: Re: [Calcul] Problème étrange le Tuesday 25 May 2004 08:59, [email]kanze (AT) gabi-soft (DOT) fr[/email] écrivit : Quote: int n = floor(a/b*c); et c'est dans le '=' qu'il y a problème : un double à droite, un int à gauche. solution : int n = static_cast<int>(floor((a*1.0/b) *c) ); La conversion double en int est implicite en C++. Si le compilateur émet plus d'un avertissement lors de l'affectation, ça m'étonnerait. oui, le static_cast n'est là que pour éviter un avertissement. Quote: Je crois que le problème c'est plutôt qu'en C++, floor est surchargé, pour float, double et long double. Et quand on lui passe un int, c'est ambigu, parce que le compilateur ne sait pas laquelle des trois fonctions choisir. ah oui j'avais pas pensé à cette ambiguité. je pensais que l'OP disait juste qu'il avait un avertissement ("insulte"). j'imaginais mal le cas de l'appel de floor pour un int, qui n'est pas très naturel 8-/ d'ailleurs comme dit dans un autre msg, la meileure solution ici est de rester en int tout du long, mais en faisant la division euclidienne comme il faut : int n = (a*b) / c; Quote: En passant, ces surcharges cassent du code existant pré-norme, puisqu'avant la norme, quelque chose comme exp(3) était légal. L'intérêt du surcharge est évident (à mon avis, en tout cas), mais ils auraient peut-être dû ajouter des surcharges sur int, etc., pour ce genre de cas. enfin, pour floor cette surcharge n'est pas un problème, vu que c'est assez inutile de passer un nbre entier à la fonction. Sinon la norme n'a pas du juger utile d'ajouter une surcharge sur int qui n'apporterait rien d'autre que la compatibilité avec le code pré-norme. -- Sam Back to top Samuel Krempp Guest Posted: Tue May 25, 2004 7:24 am    Post subject: Re: [Calcul] Problème étrange le Monday 24 May 2004 18:57, [email]maurette.pierre (AT) free (DOT) fr[/email] écrivit : Quote: Tous vos entierzs sont positifs, déclarez-les donc unsigned. bof, moi je préfere choisir d'utiliser unsigned que si numeric_limits<int>::max() ne me suffit pas ou que je compte utiliser l'arithmétique modulo 2^n. je ne crois pas qu'utiliser des unsigned dès qu'on a un nbre forcément positif soit une convention usuelle en C++. en tout cas je lui trouve moins d'avantage que d'inconvénients. -- Sam Back to top kanze@gabi-soft.fr Guest Posted: Tue May 25, 2004 7:27 am    Post subject: Re: [Calcul] Problème étrange Pierre Maurette <maurette.pierre (AT) free (DOT) fr> wrote Quote: "Rincevent" <rincevent (AT) nospam (DOT) fr> typa: 5) Pour la particules appartenant à la k-ème classe, sa couleur est donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas forcément un entier, on prends donc la partie entière pour être sur... Tous vos entiers sont positifs, déclarez-les donc unsigned. Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction implémentée par les unsigned n'est pas un ensemble des nombres naturels. Le type naturel pour les calculs entiers en C/C++, c'est int. On n'utilise d'autres types que dans les cas exceptionnels. On n'utilise donc unsigned que dans les cas où on a besoin d'un de ces caractèristiques particuiliers : - Des opérations bit-à-bit ne donne pas de résultats « bizarre », même si on manipule le bit de poids fort. (C'est surtout important pour les décalages à droits.) - On a besoin d'un arithmétique modulo, par exemple dans le calcul d'un code d'hachage. - On a besoin de ce bit supplémentaire. Pour représenter ces niveaux de gris, par exemple, je verrais bien un unsigned char, parce que signé, il lui faudrait un short. Enfin, les signé et les non signé ne font pas toujours bon mélange. Donc, quand une interface externe impose des non-signés, il est souvent préférable d'en faire pareil, simplement pour éviter le mélange. Note aussi l'effet des promotions integrales. S'il stocke ses valeurs dans des unsigned int, dès qu'il s'en sert dans une expression, elles seront converties en int. Utiliser par ailleurs des unsigned int reviendra à melanger signé et non signé. Je sais que ça semble bizarre, mais pour éviter de melanger des signé et des non signé lorsqu'on a des unsigned char, il faut se servir de int, et non de unsigned. (C'est beau, le C, n'est-ce pas ?) Quote: N est une constante, apparemment, ainsi que P pendant le calcul. Votre problème esr ainsi simplifié : int resultat = (k*N)/P; //c'est tout ou même int resultat = (k<</P; Jamais. Il veut multiplier, non décaler. Quote: que devrait vous générer le compilateur si vous avez déclaré N const. *Si* les décalages sont plus rapide que les multiplications. Ce n'est pas toujours le cas, et j'ai déjà travaillé sur des systèmes où le compilateur, à titre d'optimisation, convertissait les décalages en multiplications. En tout cas, c'est le problème du compilateur, et non le tien. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 Back to top kanze@gabi-soft.fr Guest Posted: Tue May 25, 2004 7:31 am    Post subject: Re: [Calcul] Problème étrange Pierre Maurette <maurette.pierre (AT) free (DOT) fr> wrote Quote: "Rincevent" <rincevent (AT) nospam (DOT) fr> typa: g un gros problème dans mon programme C++. Voilà g 3 entier a,b et c Je souhaite calculer la partie entière de (a/b)*c J'utilise pour cela la fonction floor() de Or deux problèmes se présentent : 1) Le compilateur renvoie 0 lorsque je lui demande de calculer (a/b)*c (et ce, alors que les valeurs de a,b,c ne devraient pas donner un tel résultat) Comment faites-vous pour mener ce calcul de tête ou avec papier-crayon ? Commencez-vous par diviser ? Avez vous besoin de flottants pour traiter le problème ? Si vous faites : int resultat = (a*c)/b; vous traitez exactement le problème tel qu'il est posé, c'est à dire comme un problème d'entiers. C'est souvent une bonne solution, mais il faut faire attention aux débordements possibles. Quote: Je vous laisse, par rapport à ce que vous souhaitez, juger de l'oportunité d'un ajustement par floor(). Personnellement, je ne l'utiliserais pas, puisque c'est une fonction double. Si les valeurs sont signées, il a intérêt à passer en flottant de toute façon. La division avec des résultats négatifs n'est pas bien définie en C++. Quote: Mais bon, personnellement, je trouve regrettable l'utilisation de / pour la division entière, j'aime bien le couple div mod du Pascal. Tout à fait d'accord. Mais C/C++ ne sont pas seuls dans leur choix. Quote: Il est aussi rapide et plus naturel de tester le signe (et malheureusement je pense qu'il faudra également tester le résultat exact, le cas ou a*c est divisible par b) pour ajuster le résultat. Mais le résultat direct correspond à l'idée que je me fais d'une partie entière. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 Back to top Samuel Krempp Guest Posted: Tue May 25, 2004 7:32 am    Post subject: Re: [Calcul] Problème étrange le Monday 24 May 2004 18:11, [email]rincevent (AT) nospam (DOT) fr[/email] écrivit : Quote: 5) Pour la particules appartenant à la k-ème classe, sa couleur est donc (canoniquement) donnée par (k/P)*N de nos jours, la séparation "canonique" en classe serait plutôt basée sur des percentiles. par exple : std::vector<int> valeurs; // on y met toutes les valeurs des pixels sort(valeurs); std::vector<int> bornes_classes; for(int k=0; k bornes_classes.push_back(valeurs[(k*N)/P]); } (tel quel ça pourrait donner les mêmes bornes à plusieurs classes, donc produire moins que P classes, mais l'idée y est..) au lieu d'avoir P classe bornées par des valeurs choisies sur une échelle arbitraire, et parmi lesquelles la plupart peuvent très bien être vides, on se retrouve avec P classes adaptées aux valeurs observées. -- Sam Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ (French) All times are GMT Goto page 1, 2, 3, 4, 5  Next Page 1 of 5   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.