Small typo in js doc and a small question of coordinates transform

[YingChangJ]

Hello,
Thanks for your wonderful project!
Here is a very little typo in JavaScript docs

Rotation_EQJ_ECT | Calculates a rotation matrix from J2000 mean equator (EQJ) to J2000 mean ecliptic (ECL).
the second coordinates in the description should be ECT instead of ECL.

I am trying to write a simple star map with some astronomical objects in different coordinates. (for fun)(yingchangj.github.io/starmap.html)
The planets, star and coordinate circles (ecliptic, equator, horizon) need a lot of coordination transform. When I looked into the docs, I find there are usually a lot ways to do the same things: when an object need to transform from ECT to HOR, both EQD or EQJ are available as a bridge (since Rotation_ECT_HOR is not there).
With a little reading of the Astronomy Engine's JavaScript, EQD should be chosen apparently.
When I read the JavaScript and try to find the best route to all the transforms between different coordinates in a better way, a question comes to my mind (apologies if it sounds too simple) Is this intentionally done to reduce coupling?
such as,

1. ECT_EQD and EQD_ECT could be calculate with inverse rotation each other
2. Horizon and Rotation_EQD_HOR share a lot code in same before the refraction take into calculation.
3. gyration and Rotation_EQD_EQJ and Rotation_EQJ_EQD did basically the same thing with different conditions/directions.
4. Ecliptic and Rotation_EQJ_ECT, they are doing very similar things but looks very different. Both of they convert EQJ to EQD first, and then from EQD to ECT. Their code are similar but nothing shared.
   May I guess, some difference do exists?
   Really apologies for the length.

[cosinekitty]

Thank you for reporting the typo! I found and fixed a few more of those.

About the rotation functions: yes, there is not a consistent theme because I kept adding more and more coordinate systems, and I didn't want to have a ridiculously large number of conversion functions. I made sure there is a way to go from any orientation to any other, although as you point out, sometimes you have to go through some intermediate orientation system.

I'm sure with some care, it would be possible to simplify and improve the way they are implemented. I'll be happy to consider any specific recommendations you have.

[YingChangJ]

Thanks for your explanation.
I believe using rotation functions to replace certain code in planet-related calculations could enhance readability.
For those less acquainted with astronomy, a brief explanation within the code could be beneficial.

If a single result is sufficient, consider finding the direct path; otherwise, follow these logical steps:

1. Planets calculation: HelioVector, then GeoVector, then Equator(EQJ -> EQD), then Ecliptic or Horizon. Obtaining any of these result and converting only in the rightward direction (using rots) will reduce repeated calculation.
2. Coordinates transformation: only use four EQD-related rotations, plus CombineRotation and InverseRotation to obtain other rotations, this will avoid unnecessary detours. (GAL and ECL are exceptions, which need EDJ)
3. the direct transformation path outside the rotation system, could be more efficient since it might calculate e_tilt only once.

A bit verbose, lol, efficiency might not be important:)

[cosinekitty]

This is a very interesting direction for the conversation. It would be interesting to make a diagram of all the orientation systems, and what is the minimum number of steps to go from any one of them to any other.