Angle calculations return rad values but labeled degrees

[oni303]

Just tried to use the math functions, after wondering about the values I found they are working in the rad system not in degrees. This is especially confusing with the degree sign in the result label. In my opinion there is not much sens in calculating in rad for valentinas applications.

[Roman Telezhynskyi]

So, what do you propose? Add two new functions RadToDegree and DegreeToRad?

[oni303]

Actually I know no one how thinks like "lets make an angle of half Pi these lines", 90 Degree is much more common. Thus, I think the rad version are not needed. Another reason is that everywhere else in valientina degrees are used as well.

[Susan Spencer]

Hi @oni303, for documentation purposes, can you post the math functions that you used, and the results? Thanks!

[oni303]

Hi,

as an example: asin(10/14) = 0.795 rad which is not wrong but 45.584 deg is much more intuitive. Especially when all other angle values are in deg, now you have to convert from deg to rad and vise versa every time you use functions like sin, tan, cos ...

[Roman Telezhynskyi]

I don't see a need to change them.

[oni303]

I agree with minor importance but I disagree with closing In my opinion it hard to explain why a user needs to do thinks like: 10/sin((AngleLine_D2_D)*(3.1415/180)). When 10/sin((AngleLine_D2_D)) is not much more programming work. Such a design decision is hard to explain.

It should be fixed better earlier than later. I guess by no these functions are nearly unused, just by that there a no complains about this issue by now.

With some hints I would try to fix it my self.

[Roman Telezhynskyi]

We can't fix it. Any change in behaviour will break backward compatibility. Even if you think that these functions are rare used that still mean they are used.

Your point about sin/cos and friends is right. But if we really want to fix the problem all we can do is to bring new functions that will take degree instead of rad. For example sinD, cosD etc.

Also look in this thread.

[oni303]

Well backward compatibility is a good reason.

Can you give me some hints where to start implementing sinD ... Even when you decide not do use it in the end, it looks like a issue to get familiar with the code base.

[Roman Telezhynskyi]

You need two places:

• QmuParser::InitFun()
• File def.h. We translate all names. So you need to add function names for translation. See string "extern const QString sin_F;"

[oni303]

Thanks for merging my pr