Design clone et template

Bonjour à tous,

J'ai actuellement besoin d'une classe utilisant un design clone mais le problème est que la classe en nécessitant est une classe "double" template (typename T, typename U).

Je ne peux donc pas utiliser (dans ma classe)

Code:

---

virtual std::auto_ptr<T> Clone() const =0;

---

puisque la classe est double template.

Ma question est simple : comment puis-je faire ? :mouarf:

Si vous voulez de plus amples explications, notamment sur cette fameuse classe ou si vous voulez savoir quelles sont les raisons qui me poussent à utiliser ce design, n'hésitez pas ! ;)

Bonjour,

Je ne comprends pas trop ta question. Tu parles bien de ça : http://cpp.developpez.com/faq/cpp/?p...es#CLASS_clone ?

Ce qu'on retourne c'est un pointeur sur un objet du type de la classe, si la classe est template alors on retourne un pointeur du type de la classe avec les même paramètres template (il n'y a pas besoin de les marquer, ils sont "automatique" au sein de la classe).

Effectivement je ne sais pas pourquoi je pensais que c'était impossible :aie:

Sujet somme toute résolu bien qu'assez inutile :mrgreen:

Merci à toi ;)

Edit : en fait j'ai quand même un probpème :mrgreen:. Le code compile mais les objets ne sont pas du bon type : dans ma classe mère :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

template <typename T, typename U> class Curve { public: [...] virtual ~Curve() {}   virtual Curve* Clone() const = 0; [...] };

---

et dans une des classes fille :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

template <typename T, typename U> class PolynominalCurve3rdDegree : public Curve<T,U> { public: [...] ~PolynominalCurve3rdDegree(){}   PolynominalCurve3rdDegree* Clone() const; [...] };   ...   template <typename T, typename U> PolynominalCurve3rdDegree<T,U>* PolynominalCurve3rdDegree<T,U>::Clone() const { return new PolynominalCurve3rdDegree (*this); }

---

Ainsi, lorsque je déclare :

Code:

---

1 2	Curve<int, double> *B = new PolynominalCurve3rdDegree<int,double>(8,6,5,2,7,9); Curve<int, double> *A = B->Clone();

---

A n'est pas une PolynominalCurve3rdDegree<int,double> car je ne peux pas accéder aux fonctions membres propres à cette classe et la taille de (*A) est la même que celle de (*B) et la même que celle d'un objet de type Curve<int,double>, et non celle d'un objet de type PolynominalCurve3rdDegree<int,double>.

Me suis-je trompé quelque part dans le design ? N'ai-je pas bien compris celui-ci ?

Enfin je verrai cela demain je commence à fatiguer :mrgreen:

Effectivement, tu utilises la fonction Clone de Curve qui te retourne une Curve, et que tu stockes dans un pointeur sur Curve.
Il faut donc que tu fasses un static_cast vers PolynomialCurve3rdDegree pour accéder aux fonctions de cette classe.

Effectivement, merci pour cette réponse claire :ccool:

Sujet résolu

Salut,

Soit, toutefois, attentif au fait que si tu as besoin de transtyper ton Curve<int , double> * en PolynominalCurve3rdDegree<int, double> *, c'est, peut etre, que tu es confronté à un problème de conception dans le sens où tu as été "assez bête" que pour... perdre le fait que tu travaillais avec un PolynominalCurve3rdDegree :aie:

Peut etre devrais tu envisager la mise en place d'un pattern de type "visiteur" (ou similaire) qui te donnerait l'occasion de récupérer un PolynominalCurve3rdDegree<int, double> :question:

En outre, on peut toujours se poser la question de l'opportunité réelle de maintenir dans une même collection des objets dont le type réel hérite de Curve<int, double> mais qui ne sont pas tous de type PolynominalCurve3rdDegree<int, double> ...

Mais ca, cela dépend de ton projet et je ne m'avancerai pas sur ce point ;)

Enfin, il serait peut etre intéressant de s'intéresser pré / post conditions et aux invariants de Curve et de PolynominalCurve3rdDegree, car je ne suis pas persuadé du tout (sans rien savoir de ton projet, encore une fois) qu'il soit effectivement opportun d'avoir un héritage dans le sens où les pré / post conditions et les invariants *risquent* de violer le principe de substitution de Liskov (un peu comme le ferait une liste triée héritant de liste) ;)

Effectivement après quelques réflexions je me suis aperçu qu'un "simple" héritage avec virtualité suffisait.

Donc plus besoin de connaître le type exact de courbe qu'on manipule, notamment dans le cas de courbe dérivée, pourvu qu'on connaisse son tableau de signe, commun à tous les éléments de la "famille" :mrgreen:

Merci pour ta réponse ;)

Pas de problème...

As tu, cependant, réfléchi un peu aux pré et post conditions de tes deux types de Curve :question:

Pour rappel, pour que LSP soit respecté,

1. Les préconditions ne peuvent pas être renforcées dans une sous-classe. Cela signifie que vous ne pouvez pas avoir une sous-classe avec des préconditions plus fortes que celles de sa superclasse.
2. Les postconditions ne peuvent pas être affaiblies dans une sous-classe. Cela signifie que vous ne pouvez pas avoir une sous-classe avec des postconditions plus faibles que celles de sa superclasse.

A vrai dire je n'avais jamais entendu parler depuis hier de pré, post condition et d'invariants :aie:

En fait, j'ai du mal à saisir exactement le concept, pourrais tu me donner un bref exemple afin que je comprenne mieux ? (enfin ça c'est assez fénéant je vais déjà voir sur internet :mouarf:)

exemple théorique de la déclaration de la fonction sqrt:

Code:

---

double sqrt(double d);

---

préconditions:

• explicite: sqrt prend un unique argument, d, qui est un double
• documentée: d doit être positif ou nul

Les préconditions sont normalement exprimables avec le verbe requérir
postconditions:

• explicite: la valeur de retour est un double
• documentée: la valeur de retour est la racine carrée de l'entrée
• mathématique: la valeur de retour est positive
• documentée: en cas de violation des préconditions, ... (je ne sais plus, -1 je crois)

Pour les invariants, c'est plus en rapport avec un objet (classe ou primitif)
La définition d'un invariant est "une propriété qui est vraie à tout instant".
En général, on définit un invariant dit observable: "une propriété vraie à chaque fois qu'on l'observe."

On attend d'un int qu'il garde sa valeur tant qu'il n'est pas affecté.

Une liste ordonnée garantie qu'à tout instant (hormis pendant l'execution d'une de ses méthodes), le tri est respecté.

En fait, préconditions, postconditions et invariants sont des termes utilisés en "programmation par contrat".

Le principe est, en (très) gros (et horriblement simplifié), de dire "donnes moi ce dont j'ai besoin tu obtiendras ce que tu attends, car, si tu ne me donnes pas ce dont j'ai besoin, je ne garanti absolument pas le résultat que tu obtiendras" :D

Les préconditions, ce n'est qu'un ensemble de conditions qui doivent doivent être respectées avant même le début du traitement car, autrement, il est clair que le traitement n'ira jamais jusqu'au bout.

Prenons l'exemple de l'opérateur [] qui permet de récupérer un élément par l'indice auquel il se trouve dans un tableau.

De manière générale, pour obtenir un résultat cohérent, il faut que l'indice soit "valide", ce qui peut se traduire par deux préconditions :

• l'indice doit être plus grand ou égal à 0
• l'indice doit être plus petit que le nombre d'éléments contenus dans le tableau

car, si ces deux conditions ne sont pas respectées, tu obtiendras quelque chose qui, tôt ou tard, te "pètera à la figure" :aie:

Un autre exemple pourrait porter sur les noms de fichier:

Il y a des caractères (ou des suites de caractères) qui ne peuvent en aucun cas être utilisés dans un nom de fichier, parce qu'ils représentent "quelque chose" pour le système.

Si tu essayes d'ouvrir un fichier dont le nom contient l'un de ces caractères (ou de ces suites de caractères), que ce soit en lecture ou en écriture, il est clair que l'ouverture échouera.

Tu peux donc créer une fonction qui s'assure que la chaine de caractères pressentie pour représenter un nom de fichier est bel et bien exempte de ces (suites de) caractères interdit(e)s et que cela correspond donc à un nom de fichier "valide".

Cela ne veut absolument pas dire que le fichier existe ni même (s'il existe) qu'il pourra être ouvert!!!

Cela voudra "juste" dire que, si tu veux utiliser cette chaines de caractères comme nom de fichier et qu'il n'y aura a priori pas de problème, pour autant que les autres conditions (existence du fichier, droits d'accès, absence de "lock" sur le fichier, ...) sont remplies.

Par contre, si la condition "absence de (suites de) caractères interdits" n'est pas remplies, cela ne sert strictement à rien d'essayer d'ouvrir un fichier avec le nom donné et pourrait même avoir de très fâcheuses conséquences ;)

Les postconditions sont un ensemble de conditions qui doivent être respectées après le traitement.

Par exemple, si tu veux lire une série de données dans un fichier, tu est en droit de t'attendre à ce que les données que tu récupères après la lecture correspondent à ce qu'elles étaient au moment de l'écriture car, si ce n'est pas le cas, c'est "qu'il y a un os" :aie:

Les invariants sont enfin des conditions qui doivent être valide avant le traitement et encore être valides après le traitement.

Par exemple, on apprend en primaire qu'un carré a quatre cotés égaux et des diagonales égales et perpendiculaires.

Si tu effectues un traitement sur un carré, il est carré (et doit donc avoir quatre cotés égaux et des diagonales égales et perpendiculaires) avant le traitement et tu t'attends à ce qu'il soit encore carré (et qu'il ait donc encore quatre cotés égaux et des diagonales égales et perpendiculaires) après le traitement.

Si ces conditions ne sont pas respectées, tu pourra appeler, selon le cas, le résultat rectangle, losange, parallélogramme ou meme trapèze, mais, en tout état de cause, ce ne sera pas un carré :aie:

Merci pour cette explication et cet exemple :ccool:

Par contre j'ai du mal à comprendre certains points :

Citation:

---

@koala :

Les préconditions ne peuvent pas être renforcées dans une sous-classe. Cela signifie que vous ne pouvez pas avoir une sous-classe avec des préconditions plus fortes que celles de sa superclasse.
Les postconditions ne peuvent pas être affaiblies dans une sous-classe. Cela signifie que vous ne pouvez pas avoir une sous-classe avec des postconditions plus faibles que celles de sa superclasse.

---

Imaginons j'ai ma classe Curve de base, qui ne définit aucun comportement mais contient juste un intervalle de définition à assigner -> aucune précondition ou postcondition

Maintenant imaginons une classe RacineCurve, héritant de Curve. Lorsqu'on accède à la méthode, héritée virtuellement de la classe mère, permettant de trouver l'image d'un point d’abscisse x, il faut vérifier que cette abscisse soit positive -> précondition.

Donc la la précondition dans la classe fille est plus forte que celle dans la classe mère -> design LSP non respecté ?

Ou sont les erreurs ? Comment résoudre ce problème, j'ai un peu de mal à saisir :aie:

Dans ce cas là ca veut dire que RacineCurve ne devrait pas hériter publiquement de Curve. L'héritage publique représente une relation IS-A, donc, en particulier, tu dois pouvoir utiliser une objet de type fille où est attendu un objet de type mère. Or avec ton renforcement de pré-condition, ce n'est pas possible : un traitement sur un RacineCurve nécessite des précautions supplémentaire par rapport au traitement d'un Curve.

D'accord mais dans ce cas comment faire puisque là une RacineCurve est bien une Curve, sans que l'inverse soit vrai.

De plus une SinCurve, une CosCurve et une PolynominalCurve sont bien des Curves elles aussi donc je ne comprends pas pourquoi un héritage public n'est pas approprié !

Je conçois tout à fait que le fait de rajouter une précondition brise le modèle cependant, la classe curve dispose d'un intervalle de définition permettant de régler ce problème puisque celui-ci est propre à chaque type de Curve, défini par l'utilisateur et certaines contraintes propres au type de Curve.

Comment faire pour éviter de ne pas respecter le design LSP, sachant que je pensais réellement avoir fait quelque chose de logique ? :?

Tout ceci me fait beaucoup penser au carré qui hérite de rectangle. :zoubi:

Peut-être avec des politics ?

La notion de "être quelque chose" est très subjective. Pour la rendre non subjective il faut la définir selon le contexte, dans le cas du LSP, ce "être quelque chose" se traduit, entre autre, par ce qu'à énoncé koala01 (on pourrait aussi le traduire formellement comme c'est le cas dans l'énoncé du principe par son auteur).

Par chance il se trouve que cette définition donne souvent le même résultat que l'utilisation d'une idée intuitive et subjective du "être quelque chose". C'est souvent vrai, mais pas toujours. En particulier dès que l'on considère des objets mathématiques (les exemples sont nombreux).

Donc non, un RacineCurve n'est pas une Curve (pas dans ton design actuel).

NB: Pour la suite je ne fais que supposer, je ne connais pas tes besoins exactes.

On pourrait voir le type Curve comme une réprésentation d'un lien entre deux espaces (en généralisant on tombe sur la notion d'application). Ainsi son interface pourrait offrir :
-> Connaitre les espaces de départ et d'arriver
-> Donner l'espace image d'un sous-espace de l'espace de départ

La seconde est interessante, on peut lui donner comme précondition d'avoir un espace d'entrée qui est bien sous-espace de l'espace de départ.

Ensuite il faut déterminer la nature des différents points de variation, savoir ce qui doit évoluer à l'execution et ce qui sera déterminé à la compilation. A partir de ca tu pourras déterminer ce qui doit être des templates (ce qui est déterminé à la compilation) et ce qui doit être des données membres (ce qui évolue à l'execution).

La dernière étape sera d'écrire les algorithmes qui vont bien, mais si tu as bien déterminé ce qui est données membres de ce qui est template, alors ca devrait aller assez bien.

Personnelement, je ne suis pas convaincu qu'il y est nécessairement besoin d'héritage ici.

Citation:

---

@Bousk :
carré qui hérite de rectangle

---

Oui c'est exactement le même problème ^^

@Flob90 : tout cela me semble bien compliqué je ne saisis pas bien ce concept de double espace relié par la classe Curve :mrgreen:

Edit : après relecture je comprends mieux ton idée, même si je dois admettre que je vois mal où placer les spécificités de chaque type de courbe sans héritage, à moins d'utiliser des templates ?

Citation:

---

Envoyé par koala01

En fait, préconditions, postconditions et invariants sont des termes utilisés en "programmation par contrat".

---

J'en profite pour rappeler qu'il existe également un tutoriel sur developpez : Programmation par contrat, application en C++ ;)

Oui via des templates ou des données membres. Dit moi ce qui est déterminé à la compilation et ce qui l'est à l'execution, je pourrais (essayer) te faire un exemple pour te donner une idée.

@gbdivers : c'est un tutoriel intéressant mais ceci dit si je tente de le suivre en fonction de mon projet il faut que je repense tout même si c'est effectivement ce sur quoi je m'aiguille :mrgreen:

@flob90 : j'ai énormément de mal à discerner les 2 même si je sais que c'est totalement différent :aie:.

Je dirais que pour ce qui s'agit de la compilation, les comportements des différents types de curve sont établis, c'est à dire leur formulation explicite en fonction de x, ainsi que leur dérivée, leur tableau de variation et de signe.

Pour ce qui est de l’exécution, je dirais que ce qui est déterminé, c'est le(s) type(s) de courbes utilisés, et leur intervalle de définition, qui peut être modifié si il ne satisfait pas les conditions de base de la courbe (exemple : intervalle [-5;10] ramené à un intervalle [0;10] dans le cas de la fonction racine).

J'insiste sur le fait que j'ai beaucoup de mal à établir précisément le "design" que je cherche :mrgreen:

J'ai un peu réfléchi et je me suis posé une question :
Cette idée de lien entre 2 espaces est intéressante mais je trouve qu'elle pose certains problèmes avec ce que je fais.

Imaginons en effet cette classe :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

template <typename T, typename U> class Curve { private : Interval<T> m_definitionInterval; Interval<U> m_functionInterval;   public:   // fonctions a specialiser pour chaque type de curve template <typename V> std::list<U> getSolution(T val);   template <typename V> T getValue(U value); };

---

C'est cool : on peut spécialiser chaque fonction pour chaque type de courbe, eventuellement via des politiques pour empecher l'appel à une fonction non spécialisée, mais cependant, imaginons une courbe polynominale de degré 1, 2 ou 3 : comment avec ce schéma stocker les paramètres de la courbe, à savoir les 2,3 ou 4 coeff de la courbe ? Ici cela me paraît impossible sans faire quelque chose d'assez laid au niveau du code.

De plus, imaginons que je désire inclure un attribut de type pointeur sur curve, correspondant à la fonction appelée en premier dans une fonction composée : lors de l'instanciation d'une fonction curve, on pourrait choisir de la définir en fonction non pas de x mais d'une fonction de x :mouarf: (en fait j'explique très mal mais c'est juste le principe d'une fonction composée).
Concernant le type de la fonction composée de la Curve<T,U> déclarée,il ne s'agit pas forcément d'une curve de type Curve<T,U>. Au contraire, puisque c'est la "base" d'une fonction composée, elle est du type Curve<V,T>, puisque ses images correspondent aux "antécédents" de la courbe ayant cette fonction composée en attribut. :aie:
Je ne sais pas si vous m'avez suivi puisque je le répète j'explique très très mal enfin toujours est-il que si on considère cela on est obligé de rajouter des paramètres template infinis puisque chaque Curve peut être une fonction composée :

Curve<T,U> déclarée -> Curve<V,T> comme composée, qui est elle même une composée de Curve <W,V>, pouvant être également une composée -> Curve <X,W> et ainsi de suite
==>> impossible de définir la classe curve avec un nombre de paramètres template fini

Comment puis-je alors contourner tous ces problèmes, tout en respectant LSP (en espérant que vous m'ayez compris :lol:)

Merci par avance !

Pour les fonctions composé :

Code:

---

1 2 3

template<class T, class U, class V> Curve<T,V> compose(const Curve<T,U>&, const Curve<U,V&);

---

Après il y a d'autre problèmes mais ...

Il est vraiment difficile de te donner des solutions à des problèmes de conceptions sans savoir où tu vas. Quel est ton objectif final ? A quoi va te servir ta classe Curve ?

Pour faire simple, j'avais déjà plus ou moins bien codé ce que je voulais, avec de l'héritage (comme je l'avais dit au début), afin notamment de programmer le comportement de n'importe quel objet dans un espace bidimensionnel avec 2 curves, ou tridimensionnel avec 3 curves de façon simple et assez rapide : on définit l'intervalle de définition de la courbe, correspondant à un intervalle de temps, et on obtient les différentes valeurs de la courbe pour différents temps, qu'on assigne à la position de l'objet en X, Y ou Z.

Ensuite, je me suis demandé, notamment pour la création d'un jeu de type worms, comment faire en sorte de savoir quand un objet explosif ou non entrait en collision avec le terrain, sans utiliser le pixel perfect :mrgreen:.

J'ai décidé que ce terrain serait constitué de courbes du 3eme degré établies à partir d'un bruit de perlin ayant subi de nombreuses transformations, histoire de rendre le défi intéressant. Pour trouver ces équations, je dois donc résoudre les équations de type ax^3+bx²+cx+d = Y, et ce Y allant de Ymin de l'objet à Ymax, afin d'être certain de ne pas louper de collision dans le cas notamment d'un gros objet.

Dans ce cas là, il n'est pas très difficile de résoudre l'équation, c'est d'ailleurs le cas pour toutes les fonctions de base (racine, exp, ln, sin, cos ...).

Cependant, cela se complique (très) fortement lorsqu'on ajoute des composées. Pour rendre mon espèce de "moteur de courbes :mouarf:" plus intéressant, j'ai décidé qu'on ne puisse pas seulement utiliser des fonctions simples mais aussi des fonctions beaucoup plus complexes en pouvant remplacer le paramètre x par une autre curve, pouvant elle aussi être composée, etc ...

Les équations sont alors beaucoup plus dures à résoudre, et cela pose également des problèmes d'intervalle. Il devient alors nécessaire d'inclure la notion de tableau de variation et de tableau de signe, ainsi que de dérivée. Sans eux, pas de résolution d'équation envisageable dans certains cas.

C'est pourquoi j'en arrive à ce que je veux obtenir, à savoir un "moteur" de courbes capable de déterminer les solutions d'équation d'une majorité de type sauf de sommes et de différences à moins que je décide d'y inclure plus tard un mode de recherche par dichotomie.

Voilà, j'espère que je n'ai pas trop mal formulé le problème :aie:

Edit : le nom du post n'a plus grand chose à voir avec le sujet actuel, je pourrais le changer ^^. Et je pourrais également passer en non résolu à nouveau :D

Ton objectif c'est la résolution analytique, numérique ou les deux ?

Tu as besoin de gérer quoi comme opération sur les fonctions ? (Composition mais quoi d'autre)

Quel intérêt tires tu des tableaux de signes, de variations et du calcul de la dérivé ? Es-tu certain que le gain qu'elles apportent est supérieur aux coût qu'elles ont ?

Mon objectif est essentiellement la résolution numérique bien que la résolution analytique soit parfois inéluctable pour permettre la résolution numérique.

A vrai dire l'utilisateur choisit lorsqu'il veut calculer le tableau de signe ou de variation, ou la dérivée, d'une fonction, donc ce n'est pas obligatoire et il vaut mieux ne pas le faire lorsque c'est possible.

Enfin, pour l'instant je ne compte pas permettre d'autres opérations sur les fonctions que la composition, car :
-1 : pour l'instant je n'ai besoin que de ça
-2 : je ne vois pas ce que je pourrais inclure de plus, ça viendra avec le temps je pense :mrgreen:

Que me conseillerais-tu comme design pour parvenir à cela ? ;)

Salut,

l'approche pour les dérivées, j'imagine que c'est pour dresser la croissance/décroissance de la fonction, et de pouvoir discuter ensuite sur les éventuelles solutions de yMin<=f(x)<=yMax

Bon, c'est une prise de tête. Pour chercher cet éventuel x, je propose la fonction g à minimiser, telle que
g(x) = | E( f(x)/(yMax - yMin) )| *1000
l'idée étant que si f(x) est dans l'intervalle [yMin;yMax] alors on pénalise pas d'un coeff 1000...

Après bon, ca dépend de f, si elle est biscornue quand elle tape dans [Ymin;Ymax] alors ca va être la mort pour l'initialisation du solveur, mais on espère que tu composes avec des fonctions continues pas trop crapuleuses...

edit:

Citation:

---

je ne compte pas permettre d'autres opérations sur les fonctions que la composition

---

Si t'autorises la composition, t'autorises pas mal de choses...
si tu prends la fonction f(x) = cst + x
et que tu la composes, tu effectues une addition.
idem f(x)=multipl * x
Je parle même pas des intervalles qui peuvent devenir taquins si tu composes une heavyside des sinus, et cie

Si tu fais des résolutions numériques, alors l'algorithme de résolution va consister à parcourir l'ensemble de l'intervalle de départ et à retourner l'ensemble des éléments dont l'image est suffisament prend du résultat voulu.

Dans ce cas je partirais sur :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

template<class, class> class Curve;   template<class T, class U, class V> Curve<T,V> compose(const Curve<U,V>&, const Curve<T,U>&);   template<class T, class U> class Curve { std::function<U (T)> f; Space<T> s;   public: template<class F, class S> Curve(F f, S s) : f(f), s(s) {} template<class S> Space<U> image(S) const { /*algo 1*/ } template<class S> Space<T> solution(S) const { /*algo 2*/ } Space<T> definition() const { return s; }   template<class V> friend Curve<T,V> compose(const Curve<U,V>&, const Curve&); template<class V> friend Curve<V,U> compose(const Curve&, const Curve<V,T>&); };   template<class T, class U, class V> class ComposeF { std::function<U (T)> rhs; std::function<V (U)> lhs;   public: template<class F1, class F2> ComposeF(F1 lhs, F3 rhs) : rhs(rhs), lhs(lhs) {} V operator()(T t) const { return lhs(rhs(t)); } };   template<class T, class U, class V> Curve<T,V> compose(const Curve<U,V>& lhs, const Curve<T,U>& rhs) { return Curve<T,V>(ComposeF(lhs.f,rhs.f),rhs.s); }

---

Ensuite il manque un élément important, c'est la classe Space<>. L'idée c'est que ce soit un type erasure qui permet de manipuler différent type "d'espace", segment, interval, union (finie), intersection (finie). Et se comportant "comme" (au moins en partie) un conteneur. Ainsi les 2 algo vont être des boucles for sur ces espaces et vont construire les espaces voulus en utilisant le foncteur. Renseignes toi sur l'idée de type erasure (article de Alp Mestan sur le sujet sur developpez.com), c'est un point délicat.

Il manque aussi une fonction (membre ou libre ?) permettant de restreindre l'espace de départ. Et je ne les ai pas mis, mais ils faut protéger les fonctions avec des assertions qui vérifient si les espaces sont corrects :

• Si l'espace donné à image est bien inclut dans l'espace s
• Si l'image de l'espace de départ de rhs est bien dans l'espace de départ de lhs

@galerien69: Avec la composition tu n'autorises pas les additions et multiplication de fonctions. Resoudre (analytiquement) (f.g)(x)=cst c'est relativement simple si on connait f et g, alors que résoudre (f*g)(x)=cst ou (f+g)(x)=cst, l'est beaucoup moins. Par contre numériquement la difficulté est la même.

NB: Code non testé, j'ai pas de compilateur sous la main.

@galerien69 :

Effectivement :D

En fait je comptais également faire des multiplications de courbes mais pas des additions, du moins faire en sorte qu'il soit impossible de calculer le tableau de variation et de signe de somme de fonctions, car après c'est trop compliqué à gérer au niveau de la recherche de solutions :mrgreen:

Je n'ai pas super bien compris ton histoire de fonction g à minimiser, peut-être pourrais-tu m'en dire plus ? :aie: Ce serait pour m'éviter de trouver les dérivées ?

Je précise également que je ne travaille qu'avec des fonctions continues sinon ce serait le chaos total bien que j'entrevoie de créer une courbe pouvant regrouper plusieurs fonctions sur différents intervalles pour pouvoir faire plein de choses par la suite :D

@ Flob90 :
Je vais bien regarder tout ça ce qui me paraît très intéressant !

Citation:

---

@galerien69: Avec la composition tu n'autorises pas les additions et multiplication de fonctions. Resoudre (analytiquement) (f.g)(x)=cst c'est relativement simple si on connait f et g, alors que résoudre (f*g)(x)=cst ou (f+g)(x)=cst, l'est beaucoup moins. Par contre numériquement la difficulté est la même.

---

oui, je m'en suis rendu compte avant de partir. C'est un problème intéressant auquel j'ai pas du tout réfléchi pour l'instant...

Citation:

---

fonction g à minimiser, peut-être pourrais-tu m'en dire plus

---

l'idée, c'est que il existe des solveurs tout pret qui font le travail pour toi à savoir:
tu donnes une borne xInf (ex:0) une borne xMax (ex:1000) et une fonction f, et tu appèles solveur(f,xInf,Xmax) qui te retourne la valeur de x qui minimise f. De cette manière, tu as pas besoin de te fouler.

edit2: bien que peu d'interêt pour cette discussion, ca reste quand même intéressant.

Citation:

---

Resoudre (analytiquement) (f.g)(x)=cst c'est relativement simple si on connait f et g, alors que résoudre (f*g)(x)=cst ou (f+g)(x)=cst, l'est beaucoup moins

---

Je ne vois pas la différence entre f.g et f*g.
Mais je ne vois pas non plus le rapport entre résoudre (f+g)(x)=cst et l'assertion la composition n'autorise pas l'addition.
pour ma part, je concois les choses comme u(f(g(x)) = f(x)+g(x)
et moyennant la bijectivité de f et g (...), u(x) = f(g^-1(f^-1(x)))+f^-1(x)

Je pense que par f.g flob90 sous entendait la composition des 2 fonctions, donc ce n'est pas f*g

Il est ainsi plus facile de résoudre f.g = cste que f*g = cste :
pour résoudre f(g(x)) = cste, il suffit de résoudre f(X) = cste, puis g(x) = X, on a alors les solutions x, même si je pense ne rien apprendre à qui que ce soit :D

Alors que pour résoudre f*g = cste ou f+g = cste, il faut passer par la dérivée et établir une approximation de x dans une majorité des cas, sauf si il s'agit de résoudre f*g = 0

ah, ok normalement la composition est notée fog.
Cela dit, ca change pas que je vois pas le rapport.
Ni que de toute façon que c'est du détail (qu'on me reprenne s'il y avait un sous entendu derrière cette subtilité).

Le fait est que si tu veux dans un cas général composer plein de fois des fonctions continues, et de savoir si la fonction résultante tape bien dans l'intervalle [ymin;ymax] alors aborder le problème par étude de variation est oufzor (idem j'y crois pas, mais qui sait, ...).
Le deuxième point c'est que c'est quand même plus pratique quand on se passe des expressions analytiques (genre sinon va faloir un interpréteur).

Du coup, j'opterais vraiment pour un algorithme basé sur ta fonction f résultante.
A partir de là, tu peux implémenter le tiens, ou te servir d'un solveur.
Le problème du solveur, c'est qu'il est dépendant de l'initialisation et que tu peux passer a coté de solutions éventuelles. Il faut connaitre son l'implem (du moins lalgo) du solveur pour pas avoir de résultats imprévus, mais je pense que partir sur la minimisation que j'avais proposée est concluante.

<HS>
@galerien69: Dans mon message le . (oui je sait bien que normalement c'est o, sauf que je trouve le . plus clair sur un forum, et c'est la notation utilisée par Haskell) indiquait ici l'opérateur de composition. La suite de mon message était pour souligner que la composition est le cas le plus simple à traiter analytiquement (et c'est d'ailleurs pour ca que j'avais demandé si il voulait faire analytiquement ou pas et si il avait autre chose que des composition). Pour ce qui est de mon assertion, (R^R, .) et (R^R, +) (ou (R^R, *)) ne sont pas isomorphes (fondamentalement car un des oéprateur est commutatif et l'autre non). Et la bijectivité que tu supposes est quelque chose de très fort, trop fort pour l'op.
</HS>

J'ai du mal à comprendre ce que fait le solveur et à partir de quoi il le fait.

Pouvez-vous m'en dire plus et éventuellement ou en trouver ?

Je ne sais également pas ce qu'est la minimisation d'une fonction si comment trouver la fonction résultante ! :aie:

Citation:

---

La suite de mon message était pour souligner que la composition est le cas le plus simple à traiter analytiquement.

---

Je suis (évidemment) ouvert sur ta méthode de procéder pour savoir si on tape dans le fameux [ymin;ymax].

Je vois pas trop comment tu peux te servir de la propriété "uniquement des compositions" pour arriver à une solution simple.

Citation:

---

Pouvez-vous m'en dire plus et éventuellement ou en trouver ?

---

tu as par exemple gsl qui propose cette fonction

Typiquement tu poses x=0, et xMax=beaucoup
(je crois que x est un temps donc positif), et de fait tu as plus qu'à cueuillir la solution si elle existe.

Si je connais analytiquement les solutions à f(x)=y et g(x)=y, alors je peux calculer directement les solutions. Ainsi pour résoudre f(g(x))=y, alors il suffit de calculer les z tel que f(z)=y puis les x tel quel g(x)=z pour tout les z.

En fait ça revient à ce que j'avais fait au départ (cf le début du post même si je n'explique pas vraiment comment je fais) mais ça ne respecte pas LSP :aie:

J'utilise en effet une classe Curve dont hérite chaque autre courbe : RacineCurve, PolynominalFirstDegreeCurve, ExpCurve etc...

L'avantage est qu'on peut définir un nouveau comportement à chaque fois pour la résolution d'équation, l'inconvénient c'est que ça respecte pas LSP puisque pour des courbes comme RacineCurve il faut restreindre les valeurs de x aux valeurs positives. Pour les composées j'avais trouvé un système sympathique mais assez lourd pour résoudre les équations, puisqu'il fallait à chaque fois réécrire de nombreuses lignes de codes :mrgreen:

Voilà pourquoi il fallait que je trouve autre chose, ce que je suis en train de faire ;)

Je ne sais même plus à qui je réponds :mouarf:
Toujours est-il que je me souviens maintenant pourquoi j'ai besoin de calculer des dérivées ! (je vous en dirai plus après avoir mangé ^^)

C'est quoi qui "revient à ce que tu avais fait" ? Ce que je vient de dire ? C'est étrange puisque tu m'as dit que tu résolvais numériquement et pas analytiquement.

Si c'est le cas, alors une solution est d'ajouter un second foncteur qui retourne l'espace réciproque à un singleton. Ensuite c'est à ta factory d'initialiser correctement ta curve avec le foncteur et le foncteur réciproque qui convient.

Citation:

---

Si je connais analytiquement les solutions à f(x)=y

---

ouais mais le problème, c'est que tu sais pas si f(x)=y admet des solutions, et si c'est pas le cas, il faut tenter f(x+epsilone) et ainsi de suite tant que pas de solutions. Ce qui au final est peut-être un peu lourd (mais mérite réflexion).