You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While the first options are not terrible, I am not a fan. As for unitful, I do not like having to import a new package for simple conversion. And neither option solves printing as degrees.
Personally, I would love to have variants of the different representations that have a lowercase "d" appended, similar to sin and sind. So we would have RotAd, RotABd, RotABCd, AngleAxisd, and whatever other representations that take angles as input. These representation could store the input as degrees, and dispatch to e.g. sind instead of sin, and in that way close #196 and #197. They could also print those stored fields as degrees, without floating point conversions between radians. All in all I think it could be quite neat, for both exactness and to make a degree-based workflow feel first-class.
The text was updated successfully, but these errors were encountered:
Note: I have not used this package much, but I wanted such functionality when I realised that python has it: Inputs and outputs as degrees, specified by a keyword argument.
If one wants to specify and read angles as degrees, it seems like one is out of luck with this package. Of course, one can always do
or
While the first options are not terrible, I am not a fan. As for unitful, I do not like having to import a new package for simple conversion. And neither option solves printing as degrees.
Personally, I would love to have variants of the different representations that have a lowercase "d" appended, similar to
sin
andsind
. So we would haveRotAd
,RotABd
,RotABCd
,AngleAxisd
, and whatever other representations that take angles as input. These representation could store the input as degrees, and dispatch to e.g.sind
instead ofsin
, and in that way close #196 and #197. They could also print those stored fields as degrees, without floating point conversions between radians. All in all I think it could be quite neat, for both exactness and to make a degree-based workflow feel first-class.The text was updated successfully, but these errors were encountered: