On y voit déjà un peu plus clair.
Utilise à fond ce que je t'ai donné , i.e :
1) Faire en sorte que tu n'es jamais à écrire
monobjet.tel_attribut = qqch
. Ces assignations doivent se faire dans la construction de l'objet.
1 2 3 4
| class BoulePonctuelle :
def toDroite(self) :
cx, cy = sin(self.theta), -cos(self.theta)
return Droite(cx, cy, -(self.absci*cy + self.ordo*cx) ) |
1 2 3 4
| class Vecteur :
def __mul__(self, facteur) :
"""Retourne le produit d'un vecteur et d'un scalaire, (opération commutative)"""
return Vecteur(self.absci*facteur, self.ordo*facteur) |
bp = BoulePonctuelle(0, 0, (-pi/10 + 2*pi) % (2*pi))
et j'en vois d'autre, mais je vais arrêter là l'énumération ...
2) Lier tes méthodes aux classe auquelles elle rapportent.
VandPtoD doit etre inclus dans vecteur (ou Point, ou les deux éventuellements)
PandPtoV et PandPtoD doivent etre inclus dans Point
intersections dans Droites, est_colinéaire, coefcol, produiScal, projectionOrtho, angle dans vecteur
Ce n'est pas parcequ'il y a 2 paramètres que cela change vraiment la donne. Par exemple pour coefcol :
1 2 3
| def coefcol (u, v) :
if v.absci==0 : return round(u.ordo/v.ordo, 10)
else : return round(u.absci/v.absci, 10) |
devient
1 2 3 4
| class Vecteur :
def coefcol (self, other) :
if other.absci==0 : return round(self.ordo/other.ordo, 10)
else : return round(self.absci/other.absci, 10) |
Et au lieu de l'appeler comme ça :
On l'appelle comme ça :
(fonction qui est d'ailleurs très bizarre au passage, car elle présuppose que les vecteurs sont colinéaires. Et s'il ne le sont pas, on ne le sait pas et ca fait n'importe quoi. Ca pourrait etre bien de le vérifier dans la fonction avant d'entamer les calculs)
Et on pourrait faire mieux encore ensuite en créant une classe Polygone et une classe Trajectoire, voire également une classe MatriceRotation ou ChangementBON.
Maintenant que j'y vois un peu plus clair, j'ai voulu changer quelque paramètre pour avoir des pistes sur l'endroit où cela merde. Mais dès que j'en change un, je me retrouve avec une erreur
1 2 3 4
| File "C:/Users/GLE7/Desktop/Rebond_Particule_ponctuelle.py", line 300, in rebondBillardConvexe
inter, i = intersection_Billard(bp, BORD)
TypeError: 'NoneType' object is not iterable |
Parce que ta fonction intersection_Billard retourne None. Et c'est d'ailleurs très bizarre qu'elle retourne None, car quelque soit la trajectoire de ta boule, elle va finir par taper l'un des bords ! Donc ici ca ne devrait jamais etre None qui est retourner ... Mathématiquement une droite, dont l'un des points est à l'intérieur dans polygone fermé, va forcément intersecter ce polygone
En gros, quand je fais
TRAJ = trajBillardConvexe(bp, BORD, n)
ça devrait fonctionner quelque soit n (n étant le nombre de rebond après lesquels j'arrete de calculer si j'ai bien compris).
Ensuite je ne sais pas pourquoi tu t'embêtes à disséquer des cas de figures en fonction de l'angle et du bord. Dans mes souvenirs d'algèbre linéaire, si tu fais un changement de base, tu te ramènes au cas où le plan réfléchissant devient l'axe x, et la normale l'axe y. Dans cette base, il suffit simplement de transformer un vecteur u=(u0,u1) en v=(u0,-u1) pour avoir son réfléchit. Et la matrice de changement de base est simplement la concaténation du vecteur directeur unitaire du plan incident avec celui normal unitaire à ce même plan ...
Je m'explique par un exemple.
Considérons un carré reliant les points (0;0); (3;4); (-1;7); (-4;3).
Je prends le 1er bord. Son vecteur directeur unitaire est (3;4) divisé par sa norme qui est 5, c'est à dire u=(0.6;0.8).
Son vecteur normal unitaire est v=(-0.8,0.6).
Donc la matrice de passage de la base (u,v) à la base canonique (où dans l'autre sens, à inverse près) est donc :
[u;v] (u et v étant écrit en colonne) c'est à dire
1 2
| [[0.6 -0.8],
[0.8 0.6]] |
Alors oui après cette matrice peut s'écrire comme une matrice de rotation en fonction du sin et du cos d'un angle... Mais as t'on besoin de tomber là dedans qui force des distinctions de cas, distinction de cas qui posent des problèmes numérique puisque vos rebonds ne semble pas être calculé de la même manière en fonction du bord sur lequel on atterit ...
Reprenez vous papier crayon, un peu de calcul s'impose je crois !
PS : Autre piste d'amélioration de la lisibilité du code :
1) .absci et .ordo partout c'est un peu lourd comme nom. .x et .y irait très bien
2) Quand on traite avec numpy on a une bien meilleur artillerie que juste avec la librairie math. Donc l'import de la librairie math peut être virer et tirer plutot ce dont vous avez besoin sur numpy
from numpy import pi, cos, sin, sqrt, arccos
Il faut éviter les import * également
Partager