Cabeceras de coordinates.py

[AlexS12]

Hay que tomar una decisión al respecto:

• Cambiar theta, phi, psi en las cabeceras por euler_angles.
• Cambiar gamma, mu, chi en las cabeceras por ¿?
• alpha y beta pueden quedar como alpha y beta o llamarlos aero_angles (pero a lo mejor es menos explícito).

Otra opción es dejarlo como está y llamar a la función desempaquetando los ángulos:

from pyfme.utils.coordinates import wind2hor

angles = (1, 1, 1)
vector = (1, 1, 1)

wind2hor(vector, gamma=1, mu=1, chi=1)
Out[4]: array([ 1.38682227,  1.27032352, -0.09489569])
wind2hor(vector, *angles)
Out[5]: array([ 1.38682227,  1.27032352, -0.09489569])

¿Qué pensáis? Para no condicionar vuestra respuesta me ofrezco a cambiarlo si hace falta

[lbahamonde]

Yo creo que seria mejor mantener los nombres griegos y desempaquetados. Al final como estamos ensamblando las matrices de rotación vamos a necesitar cada escalar y para luego hacer code review es mejor tenerlo lo mas fiel a como está en las referencias. Podemos empaquetar los ángulos en una capa superior a medida que avanze el proyecto y empiezen a reproducirse las variables que tengamos que manejar en el codigo, por ahora estas funciones de bajo nivel lo veo mejor con psi=1 que euler_angles.

[JuanMatSa]

no se... quiza para gamma mu chi por separado, pero euler_angles lo dejaría junto, no se

[astrojuanlu]

@AeroPython/pyfme ¿Alguna idea sobre esto? Si no hay, cerramos.

[AlexS12]

Quizá esté bien dejar los nombres griegos desempaquetados. Pero deberíamos estar atentos a mantener una consistencia en el orden porque suele ser una fuente de error por mi experiencia.
Como buena práctica, cuando pasemos los ángulos, deberíamos pasarlos como argumentos con nombre, en vez de posicionales para evitarnos las dudas. Lo pongo en la wiki que haga y si os parece, cerramos.

[astrojuanlu]

Os copio un párrafo de un artículo que me ha gustado mucho:

https://glyph.twistedmatrix.com/2016/08/attrs.html

Another place you probably should be defining an object is when you have a bag of related data that needs its relationships, invariants, and behavior explained. Python makes it soooo easy to just define a tuple or a list. The first couple of times you type host, port = ... instead of address = ... it doesn’t seem like a big deal, but then soon enough you’re typing [(family, socktype, proto, canonname, sockaddr)] = ... everywhere and your life is filled with regret. That is, if you’re lucky. If you’re not lucky, you’re just maintaining code that does something like values[0][7][4][HOSTNAME]["canonical"] and your life is filled with garden-variety pain rather than the more complex and nuanced emotion of regret.

Seguramente en un futuro tengamos que definir un objeto Orientation que admita conversiones entre ángulos de Euler, cuaterniones (#32, #35) y que nos permita abstraernos de cosas como los nombres de las variables o el orden de los argumentos de las funciones. ¿Pero tal vez sea mejor plantearlo para la siguiente versión?

[AlexS12]

Mmm.... Me mola la idea de tener un objeto orientación. De hecho, seguramente podamos extender la idea a otras partes del código. La reestructuración en systen, aircraft, environment y demás se ha hecho ya con esa filosofía.
Tenemos que mantenerlo en mente! Y para esa misma versión podemos incorporar las unidades

[astrojuanlu]

Entonces vamos a quitar el milestone y planearlo para la siguiente versión. ¡Muy de acuerdo con el tema de las unidades por cierto!