This is avoiding an common but unnecesary round trip. When your inputs are vectors, angles are an unnecessary intermediate representation. You can substitute the geometric meaning of dot and cross product directly into the Rodrigues matrix and get by with less operations overall. It's more elegant, uses less instructions.
That’s exactly what I mean, there are no inverse trig that needs to be involved anywhere, see the matrix section in the article. It is trivial to recognize that vector inputs are pretty much the same space the k coefficients and mentally treat cos and sin as a shorthand symbol in terms of vector products.
And in any case inverse trig functions are just components of logarithms of quaternions, and trig is components of exponentiating half-axis-angle into quaternions.
Ok, this is very interesting, as after pondering my code and the article's main pt, I independently came to the same conclusion that angles are what introduces trig. I agree that maybe people might be using angles as intermediates, but IMO there are cases where they're the most realistic abstraction. For example, how can I map a user's mouse movements, or button presses to a change in rotation without a scalar value? Without trig?
User moves cursor or stick a number of pixels/units. User holds key for a number of ms. This is a scalar: An integer or floating point. I pose this to the trig-avoiders: How do I introduce a scalar value into a system of vectors and matrices or quaternions?
My take as a graphics programmer is that angles are perfectly fine as inputs. Bring 'em! And we'll use the trig to turn those into matrices/quaternions/whatever to do the linear algebra. Not a problem.
I'm a trig-avoider too, but see it more as about not wiggling back and forth. You don't want to be computing angle -> linear algebra -> angle -> linear algebra... (I.e., once you've computed derived values from angles, you can usually stay in the derived values realm.)
Pro-tip I once learned from Eric Haines (https://erich.realtimerendering.com/) at a conference: angles should be represented in degrees until you have to convert them to radians to do the trig. That way, user-friendly angles like 90, 45, 30, 60, 180 are all exact and you can add and subtract and multiply them without floating-point drift. I.e., 90.0f is exactly representable in FP32, pi/2 is not. 1000 full revolutions of 360.0f degrees is exact, 1000 full revolutions of float(2*pi) is not.
Hah. I think we're and the author of both articles on the same page about this. (I had to review my implementations to be sure). I'm a fan of all angles are radians for consistency, and it's more intuitive to me. I.e. a full rot is τ. 1/2 rot is 1/2 τ etc. Pi is standard but makes me do extra mental math, and degrees has the risk of mixing up units, and doesn't have that neat rotation mapping.
Very good tip about the degrees mapping neatly to fp... I had not considered that in my reasoning.
If you want consistency, you should measure all angles in cycles, not in radians.
Degrees are better than radians, but usually they lead to more complications than using consistently only cycles as the unit of measure for angles (i.e. to plenty of unnecessary multiplications or divisions, the only advantage of degrees of being able to express exactly the angle of 30 degrees and its multiples is not worth in comparison with the disadvantages).
The use of radians introduces additional rounding errors that can be great at each trigonometric function evaluation, and it also wastes time. When the angles are measured in cycles, the reduction of the input range for the function arguments is done exactly and very fast (by just taking the fractional part), unlike with the case when angles are measured in radians.
The use of radians is useful only for certain problems that are solved symbolically with pen on paper, because the use of radians removes the proportionality constant from the integration and derivation formulae for trigonometric function. However this is a mistake, because those formulae are applied seldom, while the use of radians does not eliminate the proportionality constant (2*Pi), but it moves the constant into each function evaluation, with much worse overhead.
Because of this, even in the 19th century, when the use of radians became widespread for symbolic computations, whenever they did numeric computations, not symbolic, the same authors used sexagesimal degrees, not radians.
The use of radians with digital computers has always been a mistake, caused by people who have been taught in school to use radians, because there they were doing mostly symbolic computations, not numeric, and they have passed this habit to computer programs, without ever questioning whether this is the appropriate method for numeric computations.
Unfortunately, IEEE Std 754 contains a huge mistake, which has been followed by some standard libraries for programming languages.
As an alternative to the trigonometric functions with arguments measured in radians, it recommends a set of functions with arguments measured in half-cycles: sinPi, cosPi, atanPi, atan2Pi and so on.
I do not who is guilty for this, because I have never ever encountered a case when you want to measure angles in half-cycles. There are cases when it would be more convenient to measure angles in right angles (i.e. quarters of a cycle), but half-cycles are always worse than both cycles and right angles. An example where measuring angles in cycles is optimal is when you deal with Fourier series or Fourier transforms. When the unit is the cycle that deletes a proportionality constant from the Fourier formulae, and that constant is always present when any other unit is used, e.g. the radian, the degree or the half-cycle.
Due to this mistake in the standard, it is more likely to find a standard library that includes these functions with angles measured in half-cycles than a library with the corresponding functions for cycles. Half-cycles are still better than radians, by producing more accurate results and being faster, but it may be hard to avoid some scalings by two. However, usually it is not necessary to do a scaling at every invocation, but there are chances that the scalings can be moved outside of loops.
Such functions written for angles measured in half-cycles can be easily modified to work with arguments measured in cycles, but if one does not want to touch a standard library, they may be used as they are.
When one uses consistently the cycle as the unit of angle, which is consistent with measuring frequencies in Hertz, i.e. cycle per second, instead of measuring them in radian per second, one must pay attention to the fact that a lot of formulae from most handbooks of physics are incorrect. Despite the claim that those formulae are written in a form that is independent of the system of units, this claim is false because many formulae are written in a form that is valid only when the unit of angle is the radian.
For example, all formulae for quantities related to rotation movements, as they are written in modern handbooks contain the "radius". This use of the "radius" creates a wrong mental model of the rotational quantities, both for students and also even for many experienced physicists.
In reality, in all those formulae, e.g. in the definition of the angular momentum, in order to obtain the correct formulae one must replace the "radius" with the inverse of the curvature of the trajectory of the movement. Thus the angular momentum is not the product of the linear momentum by the radius, but it is the ratio between the linear momentum and the curvature.
Then one must use the correct definition for the curvature. Most handbooks define the curvature as the inverse of the radius. This is a wrong definition, which is based on the non-explicit assumption that angles are measured in radians.
The correct definition of the curvature is as the ratio between rotation angle and length, for the movement, i.e. more precisely it is the derivative of the rotation angle as a function of the length of the curve on which something moves. When angles are measured in radians, the curvature is the inverse of the radius. When angles are measured in cycles, the curvature is the inverse of the perimeter. Thus with angles measured in cycles the angular momentum is defined as the product between the linear momentum and perimeter. Similarly for the other rotational quantities, like angular velocity and acceleration, moment of inertia and so on.
Great's great info on curvature! Also don't see the use of the half cycle, although obviously see use of cycle. (As was thinking in terms of them anyway, just with a tau term to convert to radians.)
There are many applications where instead of angles it is more convenient to use the Y to X ratio (also the Z to X ratio in 3D), i.e. to use the tangent of the angle as a scalar that encodes the direction.
In 2D, using either the angle or its tangent needs a single number. The third alternative is, as others have mentioned, to use a complex number (i.e. the cos and sin couple).
Any of these 3 (angle, tangent of angle and complex number) may be the best choice for a given problem, but for 2D graphics applications I think that using a complex number is more frequently the best. For 3D problems there are 3 corresponding alternatives, using a pair of angles, using a pair of tangents (i.e. coordinate ratios) or using a quaternion.
Specifying directions by the ratio between increments in orthogonal directions, instead of using angular measures, has always been frequent in engineering, since the Antiquity until today.
For something like cursor movement, the ratio between Y pixels and X pixels clearly seems as the most convenient means to describe the direction of movement.
That's right. However, one disadvantage of using the tan value (the y/x ratio) over that of (cos,sin) tuple is that the former loses information on whether the y coordinates or the x coordinate was negative.
So, if you use the tan representation you have to carry that information separately. Furthermore, the code needs to correctly handle zero and infinity.
Tan of the half angle takes care of the first problem and is related to the stereographic transform. This works modulo one full rotation.
The article answers to this near the very beginning.
> Now, don't get me wrong. Trigonometry is convenient and necessary for data input and for feeding the larger algorithm. What's wrong is when angles and trigonometry suddenly emerge deep in the internals of a 3D engine or algorithm out of nowhere.
In most cases it is perfectly fine to store and clamp your first person view camera angles as angles (unless you are working on 6dof game). That's surface level input data not deep internals of 3d engine. You process your input, convert it to relevant vectors/matrices and only then you forget about angles. You will have at most few dozen such interactive inputs from user with well defined ranges and behavior. It's neither a problem from edge case handling perspective nor performance.
The point isn't to avoid trig for the sake of avoiding it at all cost. It's about not introducing it in situations where it's unnecessary and redundant.
I don't have a problem with the process. Is it common knowledge there? Maybe try aksing people what ashes are. I know it can be a touchy subject but I was pretty old when I found out in America.
Most town museums of any size will have an Iron Age cremation urn full of burnt bone fragments on display. The ashes weren't exactly ground up back then.
The sun won't go supernova, but it will become a red giant in about 5,000,000,000 years, which will have roughly the same consequences for life on earth.
To be honest, I can't quite predict if humanity truly survives within the next decade or two/three or a century. Let alone millions of times more than that amount.
We humans are very likely to be our own worst enemy. I would wish for the world to exist till the 5_billion year date that you mention.
There's a lot of Jupyter notebooks out there that have a similar format. I bet you could create an interactive Jupyter notebook with AI around a particular topic.
Yeah it was pretty spectacular. The author was a bit paranoid, had never shared his sources with anyone or backed them up anywhere or version controlled them to a remote SVN server or anything like that. And then his hard drive failed and Buzz development was over. IIRC there even was a community-organized crowdfunding campaign to fund some fancy data recovery company to try and revive the hard drive so he could get the sources back (not sure if this ever turned out happening).
Yeah, I don't think writing config files for labwc to display polled data from a software defined radio that's snooping on area weather stations is giving me dementia.
Not worried: "Associations between television/computer use and dementia in socially inactive older adults remain unclear, and optimal limits are unknown."
reply