summaryrefslogblamecommitdiff
path: root/reponses.lyx
blob: d0f531fa34d143f735ef1dd2dadb6ff68a49b886 (plain) (tree)
1
2
3
4
5
6
7
8
9




                                                                   


                  
                         
                
                   
                   
                  
                     










                            
                  




                          



                 



















                            


















                          




                      
                                                     


































                                                                                   





                                                                                  



















                                                                           
 





                                                                                
                                                                                   


                         
 












                                                                                








                                                                               

















                                                                                    

















































































































                                                                                    

             
#LyX 1.6.7 created this file. For more info see http://www.lyx.org/
\lyxformat 345
\begin_document
\begin_header
\textclass article
\begin_preamble
\usepackage{color}
\end_preamble
\use_default_options true
\language french
\inputencoding auto
\font_roman charter
\font_sans default
\font_typewriter cmtt
\font_default_family default
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100

\graphics default
\paperfontsize default
\spacing single
\use_hyperref false
\papersize default
\use_geometry true
\use_amsmath 1
\use_esint 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\leftmargin 2cm
\topmargin 2cm
\rightmargin 2cm
\bottommargin 2cm
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\author "" 
\author "" 
\end_header

\begin_body

\begin_layout Title
Réponses aux questions
\end_layout

\begin_layout Author
J.
 Odersky 
\begin_inset ERT
status collapsed

\begin_layout Plain Layout


\backslash
and
\end_layout

\end_inset

 C.
 Vázquez
\end_layout

\begin_layout Section*
Question P1.1
\end_layout

\begin_layout Standard
Un vecteur est représenté par la classe `Vector3D'.
 Cette classe comprend trois champs privés du type double: x, y et z corresponda
nt aux composantes du vecteur.
 Ces champs peuvent être accédés respectivement par les méthodes publiques
 getX(), getY() et getZ().
 Les méthodes 
\begin_inset Quotes eld
\end_inset

opérateurs
\begin_inset Quotes erd
\end_inset

 sur les vecteurs (par exemple l'addition, la norme, etc...) sont toutes publiques.
\end_layout

\begin_layout Standard
Ces méthodes s'appuient entre-elles, par exemple la méthode `opposée' retourne
 le vecteur multiplié par moins un et la méthode `soustraction' additionne
 l'opposé.
 Ces appels consécutifs diminuent la performance d'une façon minimale mais
 évitent un duplicage de code considérable.
\end_layout

\begin_layout Standard
Un vecteur est complètement invariable.
 C'est-à-dire qu'une fois un vecteur initialisé, on ne peut plus changer
 ses composantes (pas de méthodes `set').
 De même, tous les opérations internes du sens mathématique (qui renvoyent
 un vecteur), renvoyent une nouvelle instance d'un vecteur.
 En aucun cas l'instance d'un vecteur n'est modifiée! Ceci facilite énormément
 le raisonement sur toute variable de type vecteur.
 De plus, l'invariance d'un vecteur paraît naturelle, comme celle d'un nombre
 réel.
\end_layout

\begin_layout Standard
Quelques vecteurs remarquables sont définis comme variables statiques constantes.
 Parmi ceux-ci notamment le vecteur nulle (Null) et les vecteurs unitaires
 i, j, k selon respectivement les axes x, y et z.
\end_layout

\begin_layout Section*
Question P3.1
\end_layout

\begin_layout Standard
Nous n'avons pas rajouté un constructeur de copie.
 Comme la classe `Vector3D' est invariable et ne contient pas de pointeurs
 ou références sur d'autres objets mutables, elle n'a pas d'état et donc
 l'utilisation du constructeur de copie par défaut suffit.
\end_layout

\begin_layout Section*
Question P3.2
\end_layout

\begin_layout Section*
Question P3.3
\end_layout

\begin_layout Subsection*
a
\end_layout

\begin_layout Standard
En ajoutant un constructeur par coordonnées sphériques, les attributs de
 la classe ne devraient pas forcémant être changées.
 Il serait toute à fait envisageable, de garder les coordonnées carthésiennes
 comme attributs et de convertir les coordonnées sphériques avec le constructeur.
\end_layout

\begin_layout Subsection*
b
\end_layout

\begin_layout Standard
La surcharge serait une difficulté majeur pour créer un constructeur par
 coordonnées sphériques.
 Etant donné qu'un tel constructeur prendrait comme paramètres deux angles
 et une longueur, représentés par trois doubles, il serait en conflit avec
 le constructeur de coordonnées carthésiennes.
 Il serait alors impossible d'avoir les deux constructeurs dans une classe.
\end_layout

\begin_layout Standard
Néanmoins, une solution alternative serait d'implémenter une méthode statique
 (
\begin_inset Quotes eld
\end_inset

factory method
\begin_inset Quotes erd
\end_inset

) qui prendrait comme paramètres des coordonnées sphériques et qui renverait
 un vecteur ayant des coordonnées carthésiennes équivalentes (par exemple
 
\family typewriter
Vector3D Vector3D::fromSpherical(double phi, double theta, double r)
\family default
).
\end_layout

\begin_layout Section*
Question P3.4
\end_layout

\begin_layout Standard
La méthode `affiche()' d'un vecteur a été implémenté sous forme de l'opérateur
 `<<' de `std::ostream'.
 La méthode `compare' est équivalent à l'opérateur `=='.
\end_layout

\begin_layout Section*
Question P5.1
\end_layout

\begin_layout Standard

\emph on
\begin_inset ERT
status open

\begin_layout Plain Layout


\backslash
color{red}{Réponse incohérente! La question conçernant l'énergie me perturbe...}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Les membres d'une particule representant le facteur gamma
\begin_inset Formula $\gamma$
\end_inset

 et l'énergie
\begin_inset Formula $E$
\end_inset

 peuvent être implémentés soit sous forme d'attributs soit sous forme de
 méthodes.
 Il y a des avantages et inconvénients pour chaque forme.
\end_layout

\begin_layout Standard
L'avantage d'un attribut est que son accès est trés rapide et ne prend (presque)
 pas de temps de calcul.
 Par contre, si la valeur d'un attribut est relié logiquement à la valeur
 d'un autre attribut et que ce dernier est modifié, il faudra manuellement
 changer le premier.
 Par exemple, le facteur gamma étant défini par:
\end_layout

\begin_layout Standard
\begin_inset Formula \[
\gamma=\frac{1}{\sqrt{1-\left(\frac{v}{c}\right)^{2}}}\]

\end_inset


\end_layout

\begin_layout Standard
si il est défini comme variable, il faudrait le mettre à jour à chaque fois
 que la vitesse change.
\end_layout

\begin_layout Standard
Contrairement à un attribut, une méthode est évaluée à chaque fois que l'on
 l'appelle.
 Ceci a l'avantage que si le résultat d'une méthode dépend d'une variable,
 la variable pourra être modifiée sans considération de la méthode.
 Ainsi, si le facteur gamma est une méthode, une mise à jour de la vitesse
 pourra être effectuée directement sans explicitement changer 
\begin_inset Formula $\gamma$
\end_inset

.
\end_layout

\begin_layout Standard
Dans le cas de notre projet, nous avons décidés d'implémenter l'énergie
 sous forme d'attribut et le facteur gamma sous forme de méthode.
 Ceci pour plusieurs raisons:
\end_layout

\begin_layout Enumerate
Au cours de la simulation, la vitesse sera changée très fréquemment, beaucoup
 plus que les appelles à gamma.
 Une implémentation de gamma sous forme de méthode améliore donc la performance.
\end_layout

\begin_layout Enumerate
Le premier argument pourrait s'appliquer également à l'énergie, or il faut
 remarquer que l'énergie est une grandeur spécifiée durant la création d'une
 particule et que en fait la vitesse dépend de l'énergie
\begin_inset Foot
status open

\begin_layout Plain Layout
Complément mathématique: 
\begin_inset Quotes eld
\end_inset

Aux énergies atteintes dans un accélérateur, les particules sont tellement
 proches de la vitesse de la lumière qu'il faudrait garder au moins 7 décimales
 pour que la vitesse permette de connaître l'énergie de façon assez précise.
 On caractérise donc plutôt une particule en termes d'énergie totale que
 de vitesse.
\begin_inset Quotes erd
\end_inset


\end_layout

\end_inset

.
 On pourrait alors penser à définir la vitesse comme méthode mais d'après
 l'argument 1, ce serait complètement absurde au niveau de la performance.
\end_layout

\end_body
\end_document