Implémentation du produit scalaire de l'espace L2

Bonjour,

j'ai créé en C++ les classes génériques suivantes :
- Complex<T>
- Vector<T>
La première permet de manipuler des nombres complexes et la seconde des vecteurs. J'aimerais associer à cette dernière une fonction amie permettant de calculer le produit scalaire "L2" entre deux vecteurs.

Mon problème est que cette opération fait intervenir la notion de conjugué dans le cas de vecteurs complexes. Or, je souhaite conserver l'aspect générique pour pouvoir faire des produits scalaires entre nombres réels.

J'ai réfléchi à plusieurs solutions :

1. ne pas utiliser les templates (i.e. faire des classes DoubleRealVector, DoubleComplexeVector, etc)
2. implémenter plusieurs produits scalaires (un pour les réels, un pour les complexes, etc)
3. faire une méthode "conj" pour les réels.
4. faire une classe Real<T>

A priori, je pencherais plutôt pour l'une des deux dernières solutions. J'aime beaucoup la dernière mais j'ai peur de perdre énormément en performances sur les opérations élémentaires (somme/différence/produit/division de float/double).

J'aimerais avoir votre avis et éventuellement d'autres solutions plus efficaces.

Merci d'avance

Bonjour et bienvenu,
Une piste pourrait être d'utiliser une fonction générique pour le calcul du produit scalaire. Cette fonction pourrait s'appuyer sur des classes traits proposant l'implémentation adéquate selon le type des arguments. Un peu de lecture :
Présentation des classes de Traits et de Politiques en C++

A la volée, cela donnerait quelque chose comme ça :

Code:

---

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

template<class t1, class t2> struct trait_scalaire { // definition dans le cas 'général' (en fait probablement à coup de meta-prog, s'occuper que des types de bases (réels ou entiers). };   template<class t1, class t2> struct trait_scalaire<Complex<t1>,Complex<t2> > {// spécialisation pour les complexes };     template<class t1_, class t2_> typename trait_scalaire<t1_,t2_>::type_retour scalaire(Vector<t1_>lhs_, Vector<t2_>rhs_) { return trait_scalaire<t1_,t2_>::scalaire_impl(lhs_,rhs_); }

---

Bonjour,

Tu peux peut-être aussi envisager la spécialisation des modèles :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

template<class T> T f(T t) { // code utilisé pour tout type T ... return 1; }   template<> int f<int>(int t) { // ... sauf si T est int. return 2; }

---

Ceci est une spécialisation complète car T est complètement défini en int, mais on peut aussi faire des spécialisations partielles, par exemple pour traiter différemment les pointeurs :

Code:

---

1 2 3 4 5 6

template<class T> T* f(T* t) { // utilisé si T est un T* return 0; }

---

Pour ton cas, il faut spécialiser le modèle pour les T qui sont des Complex<T> :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

template<class T> T ProdScal(Vector<T> Vec1, Vector<T> Vec2) { // code utilisé pour tout type T ... // ... }   template<class T> Complex<T> ProdScal(Vector<Complex<T> > Vec1, Vector<Complex<T> > Vec2) { // ... sauf si T est un Complex<T>, c'est ce code qui est utilisé. // ... }

---

Après, je ne sais pas si c’est la meilleure solution, mais avec celle-là, le choix du code à exécuter est fait à la compilation, donc pas de perte de performance.

Salut,
Visiblement on s'est croisé à un pouillème sur une idée voisine :mouarf:
Si je puis me permettre par rapport à ce que tu proposes, je ne suis pas très fan des spécialisations de fonctions. Je préfère les surcharges qui sont plus claires.
Juste une remarque, les spécialisations partielles de fonctions ne sont pas possibles. Ce que tu proposes :

Code:

---

1 2 3 4 5 6

template<class T> T* f(T* t) { // utilisé si T est un T* return 0; }

---

est une surcharge de f et non une spécialisation partielle qui aurait du s'écrire :

Code:

---

1 2 3 4 5 6

template<class T> T* f<T>(T* t) { // utilisé si T est un T* return 0; }

---

D'où ma préférence pour le passage par une structure générique qui elle peut être spécialisée partiellement de façon plus fine je trouve.

Bonjour,

merci beaucoup pour vos réponses. Les solutions que vous proposez sont bien meilleures que celles que j'avais envisagées.

Dans le cas particulier du produit scalaire, je pense que la spécialisation est parfaite : je n'ai pas de distinction supplémentaire à faire par rapport à celle des nombres complexes donc le coût de développement pour moi est minimum.

Merci infiniment pour le lien sur les classes de trait et de politique! Cette notion solutionne un autre de mes soucis : je voulais implémenter de manière générique des techniques de rééchantillonnage (validation croisée,bootstrap) pour des algorithmes pouvant retourner des objets de différentes natures...

Bonne continuation à vous.