This is true. I am just encouraging the unlearning of bad habits from school, like using degrees, using percentages and counting from 1.

It's still more visual and easier when working on a tool which use degrees.

I recrently changed all my properties to degree to be artist friendly (rotation, FOV of the camera...).

I let there the way to convert efficiently if "thefollower" want to do the same :

const float CMath::DEG2RAD = 0.01745329251994329576923690768f;
const float CMath::RAD2DEG = 57.2957795130823208767981548141f;

inline float CMath::ToRadian( const float Degree )
{
  return Degree * DEG2RAD;
}

inline float CMath::ToDegree( const float Radian )
{
  return Radian * RAD2DEG;
}

bad habits from school, like using degrees, using percentages and counting from 1.

Out of interest, why the percentage hate?

Or the counting from 1.

I should mention there is another option, which is not to use angles at all. Instead of using angle alpha you can use the unit-length vector (cos(alpha), sin(alpha)). It turns out most of the things you want to do with an angle require you computing the cosine and the sine, so if you use that as your representation, for the most part you don't need to call trigonometric functions at all.

If you are familiar with complex numbers, think of storing cos(alpha)+i*sin(alpha) instead of the angle. You can also write that as exp(i*alpha), if you are even more familiar with complex numbers. Now rotating just becomes complex multiplication, and your code often becomes very elegant.

Of course, if making the jump from degrees to radians doesn't seem easy, jumping to complex numbers can be a bit much.

Wouldn't complex numbers just hinder performance?

Out of interest, why the percentage hate?

Or the counting from 1.

Wouldn't complex numbers just hinder performance?

Vector2 apply_rotation(Vector2 v, float alpha) {
  float s = sin(alpha), c = cos(alpha);
  return Vector2(c * v.x - s * v.y, s * v.x + c * v.y);
}

Complex apply_rotation(Complex v, Complex rotation) {
  return v * rotation; // This is actually four multiplications, a subtraction and an addition. Look ma, no trig!
}

Now let's encode "goes up by 10%" as "is multiplied by 1.1" instead. If something is multiplied by 1.1 one day and by 1.1 the next day, what was it multiplied by in total? The formula is 1.1 * 1.1 = 1.21.

I've never really thought about it explicitly like that before, but that's exactly how I think of percentages - by replacing it with the proper scaling term. I wouldn't be surprised if that's one of the main reasons why some people find percentages so hard, while I found the concept fairly easy to understand while learning it.

I'll let Dijkstra answer: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

Out of interest, why the percentage hate?

If something goes up by 10% one day and by 10% the next day, what percentage did it go up in total? The formula is 100 * ((1 + 10/100) * (1 + 10/100) - 1) = 21. See all those multiplications and divisions by 100? They are an indication that you are not using the natural units.

Now let's encode "goes up by 10%" as "is multiplied by 1.1" instead. If something is multiplied by 1.1 one day and by 1.1 the next day, what was it multiplied by in total? The formula is 1.1 * 1.1 = 1.21.

Or the counting from 1.

I'll let Dijkstra answer: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

Wouldn't complex numbers just hinder performance?

Au contraire! Complex numbers do take twice as much memory as a single angle, but when was the last time you were filling up your memory with angles? When it comes to applying a rotation to a vector, the angle-centric code goes like this:

Vector2 apply_rotation(Vector2 v, float alpha) {
  float s = sin(alpha), c = cos(alpha);
  return Vector2(c * v.x - s * v.y, s * v.x + c * v.y);
}

With complex numbers it looks like this:

Complex apply_rotation(Complex v, Complex rotation) {
  return v * rotation; // This is actually four multiplications, a subtraction and an addition. Look ma, no trig!
}

If you store your rotations as complex numbers, the cosine and sine are already computed. You can write all sorts of things without ever calling a trigonometric function, and those are at least an order of magnitude more expensive than multiplications and additions.

Out of interest, why the percentage hate?

If something goes up by 10% one day and by 10% the next day, what percentage did it go up in total? The formula is 100 * ((1 + 10/100) * (1 + 10/100) - 1) = 21. See all those multiplications and divisions by 100? They are an indication that you are not using the natural units.

Now let's encode "goes up by 10%" as "is multiplied by 1.1" instead. If something is multiplied by 1.1 one day and by 1.1 the next day, what was it multiplied by in total? The formula is 1.1 * 1.1 = 1.21.

Or the counting from 1.

I'll let Dijkstra answer: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

Wouldn't complex numbers just hinder performance?

Au contraire! Complex numbers do take twice as much memory as a single angle, but when was the last time you were filling up your memory with angles? When it comes to applying a rotation to a vector, the angle-centric code goes like this:

Vector2 apply_rotation(Vector2 v, float alpha) {
  float s = sin(alpha), c = cos(alpha);
  return Vector2(c * v.x - s * v.y, s * v.x + c * v.y);
}

With complex numbers it looks like this:

Complex apply_rotation(Complex v, Complex rotation) {
  return v * rotation; // This is actually four multiplications, a subtraction and an addition. Look ma, no trig!
}

If you store your rotations as complex numbers, the cosine and sine are already computed. You can write all sorts of things without ever calling a trigonometric function, and those are at least an order of magnitude more expensive than multiplications and additions.

Performance is pretty low on browsers anyway the most i can do is about 2,000 iterations for any loop before i drop below 60 FPS (unless I use webGL). So i have to squeeze as much as possible.

I've never really thought about it explicitly like that before, but that's exactly how I think of percentages - by replacing it with the proper scaling term. I wouldn't be surprised if that's one of the main reasons why some people find percentages so hard, while I found the concept fairly easy to understand while learning it.

>>> x = 100 # 100
>>> x = x * 1.1  # * 110%
>>> x = x * 0.9  # * 90%
>>> x
99.00000000000001  # = 99% ???