On 6/7/18 7:08 PM, Robert Vanden Eynde wrote:
- I didn't know there were sinf in C (that's since C99), I was aware of the 'd' postfix in opengl.
So yeah, sind would be a bad idea, but sindeg or degsin would be too long, hmm, and I can settle for the Pre or Post fix. sindeg(90) degsin(90) are both pretty, the first emphasize on the "degree" part and the second on the "sin(90)" part. I feel I prefer sindeg, cosdeg, atandeg, atan2deg, phasedeg, rectdeg hmhm
By the way I've seen a stackoverflow answer using Sin and Cos with a capital letter, doesn't seem very explicit to me.
- I could do a pypi for it for sure, I didn't know it was that easy to create a repo actually. degreesmath (and degreesmath.cmath ?) would be a good package name but again I don't want to name the functions sin, cos. People could rename them on import anyway (let the fools be fools as long as they don't hurt anyone).
- I agree radians should be the default, but is it especially Because sin/cos must be in radians ? And because it's more efficient ? The problem arrises when Mixing units in the same program.
However, should everyone use m³ and not Liters because they're the SI units ? That's more a problems of "mixing units and not sticking to one convention". I've seen lot of libraries using degrees (and not just good old glRotate).
Let's notice there are some libraries that wrap units so that one can mix them safely (and avoid to add meters to seconds).
Let's be honest, radians are useful only when converting arc length, areas or dealing with derivatives, signals, or complex numbers (engineering stuffs), and efficiency of sin/cos implementations. When doing simple 2D/3D applications, angles are just angles and nobody needs to know that derivative of sin(ax) is a·cos(ax) if x is in radians.
- Integers are more convenient than float, you could add 1 degree every frame at 60fps to a counter and after 60 frames you'll do a full turn, adding tau/360 doesn't add so well (floating point representation). Having exact representation for multiple of 90 degrees is a big plus. Another advantage is also being able to check if the angle is particular (multiple of 30 or 90 for example). Especially python Integers with infinite precision.
- Everyone knows degrees, whereas radians are known only by people that had math in 10th grade. I know it's easy to say "just convert" but trust me, not everyone is confident with unit conversions, when you ask "what's the unit of angle ?" people will think of degrees.
- Changing the behavior for current cos/sin function to have cos(pi/2) being exact is a bad idea in my opinion, the good old sin/cos from C exist for a long time and people rely on the behaviors. That would break too much existing code for no much trouble. And would slow Current applications relying on the efficiency of the C functions.
- I totally agree writing degrees(...) and radians(...) make it clear and explicit. That's why I strongly discourage people defining their own "sin" function that'd take degrees, therefore I look for a new function name (sindeg). First I feel the need to point out that radians are actually fairly fundamental in trigonometry, so there is good reasons for the base functions to be based on radians. The fact that the arc length of the angle on the unit circle is the angle in radians actually turns out to be a fairly basic property.
To make it so that sindeg/cosdeg of multiples of 90 come out exact is probably easiest to do by doing the angle reduction in degrees (so the nice precise angles stay as nice precise angles) and then either adjust the final computation formulas for degrees, or convert the angle to radians and let the fundamental routine do the small angle computation. While we are at it, it might be worth thinking if it might make sense to also define a set of functions using circles as a unit (90 degrees = 0.25, one whole revolution = 1) -- Richard Damon