"Hertz" [Hz] is not compatible with "radian per second" [rad/s] and "revolutions per second" [rev/s]

[orestesmas]

Currently, trying to match a number expressed in Hz with its equivalent expressed in rev/s or rad/s gives an error of "Incompatible units".

That's because in "casstring.units.class.php" the "Hertz" is defined as:

array('Hz', '1/s', 'Hz', 'Hertz'),

and the "radian" and "revolution" are defined as:

array('rad', 'rad', 'rad', 'radian'),
array('rev', '2*pi*rad', 'rev', 'revolutions'),

/* NOTE: there's also a "revolution per minute" [rpm] defined as */
array('rpm', 'pi*rad/(30*s)', 'rpm', 'revolutions per minute'),

so there's no "logical connection" between the former and the latter.

These units (at least the first two of them) should be compatible, because is common practice in physics and electrical engineering to express frequencies either in Hertz or in radian per second.

In a STACK question, students may give their answers using the unit of choice, and the result should be considered correct in any case. Currently, to implement the response tree, the teacher has to test for both units separately, or manipulate the student's answer previously to transform the units into a common basis.

[zhengpushi]

Interesting question! Because SI-brochure-2019 give the definitions that "Hz = 1/s, rad=1, rad/s = 1/s", but "Hz = 2pi rad/s" is a common knowledge for engineer, so we got "1=2pi". This is a long-term unsolved famous problem. I have stucked this problem at least three days, so I happen to got here by searching www. I can't give you an solution, but only could tell you this is a famous problem (as I know, from 2005~now). I give some useful URL about the discussion for this question. https://en.wikipedia.org/wiki/Radian#Dimensional_analysis https://community.ptc.com/t5/PTC-Mathcad/Hz-vs-rad-sec-wrong-in-Mathcad/td-p/246438

[sangwinc]

Thanks for raising this issue. We did check SI when we set up the units, but there are edge cases like this and I want to be able to support this.

Can you please make a specific proposal and we can discuss it here? If we need to make changes to STACK we will certainly do so, either fixing a "bug" or providing an option where there is a genuine need to support genuine differences of opinion.

[zhengpushi]

Thank you for your attention too.

In fact, I am not sure if it is a goood solution yet, let me explain the plan below.

1. WHAT PROBLEM? Hz = rad/s, Hz = 2*pi rad/s, these two formulas realy confilicted. From SI-Brochure-2019, Hz = /s = rad/s, From engineer-view, Hz = 2*pi rad/s, They are both "right" and both "wrong".
2. WHY? Hz is frequency unit, rad/s is angular frequency unit, they need a conversion. By ω = 2*pi*f, we know that [f, frequency] and [ω, angular frequency] has a factor [2*pi]. That means, [f] and [ω] both has unit [/s], but they realy different. It should be noted that, [rad] has a history. Before 1995, the "radian(short as rad)" and "steradian" are supplementary units, not SI units. After 1995, the "radian" become SI units, and is defined as "rad = m/m", we think it is "1". I think this is the core reason. We should treat [rad] as a special case, not simply "1" .
3. A SOLUTION by the way, I am designing a formal quantity calculus system under the Coq proof assistant, so, I have interest to this problem (THIS work is not published yet). I defined [rad] as eighth basic unit, like this:

   BasicUnit := BUTime|BULength|...|BURadian.

   So, I distinguished the common quantity and angular quantity. anything about [rad] will be append a basic unit [BURadian]. [f] has unit "Hz" or "/s", that means "cycle per second" or "event per second", [rad/s] has unit "[BURadian]/s", If you want convert "Hz" to "rad/s", do this job:

   {y} [rad/s] = ({2*pi} [BURadian]) * ({x} {Hz})
   {y} [rad/s] = {2*pi*x} [rad/s]
   so, {y} = {2*pi*x}

   That means, "2*pi" is not a simple number factor, but a quantity coefficient, it is "{2*pi} [BURadian]". It's meaning is a conversion by multiply it. Another example, let's re-think "2*minute = 120*s" or "1minute = 60\s", what is 60?

   {120} [s] = ({60}[s/minute]) * ({2} [minute])
   {120} [s] = {60*2} [s]
   so, the equation is right.

   That means, 60 is not a simple number factor, but a quantity coefficient, it is "{60} [s/minute]"

4. SUMMARY two things. (1), I defined rad as BasicUnit, not derived unit. Although it is different from SI seven basic unit. But it is from practice view, not pure view. (THIS idea come from "https://en.wikipedia.org/wiki/Radian#Dimensional_analysis"). (2), I treat "60, 2*pi, etc." these magic numbers are quantity coefficient. I want give every numbers a formal meaning. So I don't misuse them, and avoiding this [2*pi] problem.

[aharjula]

Not that I know about these things, but to me, frequency is the rate at which a given thing repeats. To me, it would be silly to hard code a relation between full rotations and frequency as that is just one such interpretation of a thing that repeats. Personally, I believe that the unit system should not make any such assumptions by default and that there should be separate parameters one could tune to connect such things together when they make sense. Might be that rev/s <-> Hz connections make sense for some but generally throwing in revs into an answer when there is nothing there to revolve should not be acceptable, so the conversion should always be defined so that it would direct to something specific, and that specific would be what one would use in the answer-tests, e.g. Hz -> rev/s could be added to the system when the question context defines that they are indeed interpreting things like that.

As a bad example, imagine a servo motor that never rotates fully. We somehow end up with an answer that presents the angular velocity of that servo, in that case, I would not equate that answer with frequency at all and any answer containing Hz as the unit would be wrong, therefore we would not connect those two things in that situation. In that question, the frequency could be defined as something like the rate at which the servo does a full sweep between maximum and minimum values, and again equating that to radians/s would be a problem if the full sweep would not cover an angle that is a multiple of pi...

This is not entirely unlike the issue we just recently had with VA as a unit and how it depends on the phase when doing AC things. With it, we could not bring the phases into the model so the connections in the unit system needed to be broken.

In any case, eventually, we will have a tunable unit system where people can switch the unit definitions as they wish but not yet. The groundwork for that in the core of STACK is however pretty much complete so there is hope.

[zhengpushi]

I think that the coefficient 2*pi*[BURadian] is a good example to discuss. I means that, the coefficient is not fixed, it can be changed to pi*[BURadian] or 3*[BURadian], ... depend on the practical situation. Because the coefficient is a "unit and quantity conversion" given by user/designer/engineer/people. The important thing is that, SI mis-designed that Hz = /s = rad/s, so we will loss rad infomation and get ridiculous result that 1 = 2*pi. I want define rad as a BasicUnit, write as BURadian in my system. It is useful to distinguish 1 and rad. So, if any-time anybody want convert 1 to rad, he could give a suitable coefficient. For rotation situation, this is 2*pi*[BURadian]. Summary, this trick is useful for computer software to avoid simplify rad to 1 directly. But the real coefficient need to be maintained by final stakeholder.

[sangwinc]

Thank you for taking the time to provide such a clear discussion of the difference between Hz (frequency unit), and rad/s (angular frequency unit). I agree having some way to distinguish them (even if some people want to make rad simplify to 1) is probably helpful.

I would not be surprised if our efforts with online assessment lead to improvements in the SI system, or at least highlight that some people use units in a different way to others. If "SI mis-designed that Hz = /s = rad/s," then you should probably take that up with SI. If we change our implementation that will also be confusing to people who expect us to respect SI (even if you think it is wrong)!

We define our units here. https://github.com/maths/moodle-qtype_stack/blob/master/stack/maxima/stackunits.mac

rad is included in the SI units https://github.com/maths/moodle-qtype_stack/blob/master/stack/maxima/stackunits.mac#L36

Do you have specific suggestions for how we should change the code?

[zhengpushi]

I have read the code. I think that the definition is correct and no problem. Return to the beginning problem by [orestesmas], he said that ('Hz', '1/s') and ('rad', 'rad') have no logical connection. I think it's right, they really should not be directly connected.

Because I am not familiar with this project, I'm sorry I can't given suggestion to solve this issue. Maybe I am talking too much and may be disturbing the progress of this project, I just want to point out that rad isn't 1. Wish this project is going well.

[orestesmas]

Thank you @zhengpushi for your deepful insight and explanations. I hope this will help greatly to find an acceptable solution to this problem.

In order to clarify my first claim a little more, I believe that the solution of the problem is to provide some logical connection between rad/s and Hz. But I didn't claim that this logical connection has to be "direct" (whichever it means). Any (correct) connection will suffice. In fact, if I did understant you correctly, is precisely what your proposed solution does, isn't it? Provide the connection through the definition of BURadian:

{y} [rad/s] = ({2*pi} [BURadian]) * ({x} {Hz})

[zhengpushi]

@orestesmas Yes, I agree with you. It is what I want to say.

the solution of the problem is to provide some logical connection between rad/s and Hz. Any (correct) connection will suffice.

[BURadian] is a logical symbol, represent the definition of radian from SI. So we won't mistake the 1 and rad.