c3d
Suggested action of the "Angles o" toggle flag in chain rule derivative of trigonometric functions
The suggested action concerns the toggle flag "Angles o" with its 2 states "o" OR "●" to avoid the evaluation error in the following chain rule derivative (DB48X v0.9.7):
'exp(-x/4_s)·sin((0.5_r/s)·x)' 'x' ∂ 'x=2_s' | => "| error: Inconsistent units"
@ leaving on the stack: 'exp(-(2 s÷4 s))·0.5 r/s·cos(0.5 r/s·2 s)+(-(4 s÷4 s²))·exp(-(2 s÷4 s))·sin(0.5 r/s·2 s)'
where we can see that the sum has incompatible units since the first term is in r/s & the second term, in 1/s.
Therefore, what we suggest is the following: when the toggle flag is unset (state "Angles o"), the radians should be treated as dimensionless in order for the sum to make sense. This would give then the same result as the following:
'exp(-x/4)·sin(0.5·x)' 'x' ∂ 'x=2' |
@Expecting 0.03626 04691 25
These problems of DB48X together with others (invoking units and constant with units like the following) need to be ruled out if we want, one day, to use chain rule derivatives in applied physics & engineering. Other example where the derivative evaluation fails:
R=5_Ω C=2_F 'exp(-x·(1/R)/C)' 'x' ∂ 'x=2_s' | => "| error: Inconsistent units"
@Failing -0.08187 30753 08 (F·Ω)⁻¹ leaving on the stack: '(-(R⁻¹·C÷C²))·exp(-(2 s·R⁻¹÷C))'
Eval @Expecting -0.08187 30753 08 (F·Ω)⁻¹
in 'exp(-x/2_s)·sin((0.5_r/s)·x)' 'x' ∂ | 'x=2_s' you have the | operator and its second argument 'x=2_s', in the wrong order. That leads to the error message. I doubt it has anything to do with the _s
Anyway, there's something wrong with the derivative also
'exp(-x/2_s)' 'x' ∂ giving -(2 s÷2 s²)·exp(-(x÷2 s)) is numerically wrong. Here You've got something. The _s is causing a problem.
You may want to read https://iopscience.iop.org/article/10.1088/1681-7575/ac7bc2/pdf
You're right, I have to reorder the where operation (the | operator). I'll do it ... I still got errors. I read your article: interesting. But that doesn't change my opinion about the radians convention especially in the case of the chain rule applied to trigonometric function (like sin(ω·t)). How could it be otherwise, if the result must be dimensionally consistent?
Using https://48calc.org/db48x/index.html (no DM42n yet; away from my Fedora workstation) I RPN build:
differentiate ... to end up with:
Which is pretty messed up, I even without radians.
We need to get back to simpler expressions and see how they behave ... to investigate this bug.
differentiate gives
which is a confusing rendering of
if you evaluated that
a rendering of
The first _s has a -1 exponent.
What the ...
'exp(-x/2_s)' 'x' ∂ giving -(2 s÷2 s²)·exp(-(x÷2 s)) is numerically wrong.
Actually it gives '(-((2_s)÷(2_s)²))·exp(-(x÷(2_s)))' which is numerically correct. It's (2_s)² and not 2_(s²). The visual rendering is bogus, though.
Here You've got something. The _s is causing a problem.
Not really, it's an application of the derivative of (exp(x/a)) being 1/a*exp(x/a). Except that a simplification does not occur so that 1/a is written as a/a² with a=2_s.
You may want to read https://iopscience.iop.org/article/10.1088/1681-7575/ac7bc2/pdf
Which goes in great details to explain why I believe the idea of treading radians as dimensionless is a bad one.
I agree with this dimension fact of unit for angles. But what about my suggestion to avoid the inconsistent unit error (which is the initial question) ? How to avoid this kind of error when calculating the derivative and the subsequent where functions in: R=5_Ω C=2_F 'exp(-x·(1/R)/C)' 'x' ∂ 'x=2_s' | ?
Using DB48X 0.9.7-4-8faeb, I still encounter a condition error "Inconsistent units" with : 'exp(-x/4_s)·sin((0.5_r/s)·x)' 'x' ∂ 'x=2_s' |
'exp(-x/2_s)' 'x' ∂ giving -(2 s÷2 s²)·exp(-(x÷2 s)) is numerically wrong.
Actually it gives '(-((2_s)÷(2_s)²))·exp(-(x÷(2_s)))' which is numerically correct. It's (2_s)² and not 2_(s²). The visual rendering is bogus, though.
Agreed. I should have looked beyond the "visual rendering".
Here You've got something. The _s is causing a problem.
Not really, it's an application of the derivative of (exp(x/a)) being 1/a*exp(x/a). Except that a simplification does not occur so that 1/a is written as a/a² with a=2_s.
I should have said not "_s" but units in the context of derivatives. Same thing happens with other units.
Could you please take a closer look at the example I gave in screenshots. The evaluation goes wrong.
You may want to read https://iopscience.iop.org/article/10.1088/1681-7575/ac7bc2/pdf
Which goes in great details to explain why I believe the idea of treading radians as dimensionless is a bad one.
The very point I was trying to make. Radians have a dimension [length] / [length] = [identity] or, better [angle], which is significant. We should also be careful not to ignore the difference between units and dimensions. A unit has not only a dimension but also a measure.
I have yet to figure out how you treat this in the DB40X software. I must admit that I still have difficulty understanding the DB40X C++ code, let alone debugging, let alone fixing it. I am missing (detail / technical) design docs.
Using DB48X 0.9.7-4-8faeb, I still encounter a condition error "Inconsistent units" with : 'exp(-x/4_s)·sin((0.5_r/s)·x)' 'x' ∂ 'x=2_s' |
How about rewriting such that x = 2_(s/r) ?
I am confused here. How to read this (the first part): a) the inverse s is the unit of the 4 b) the inverse s is the unit of the 1/4
Seems to be b). But this looks very confusing in both the graph and the edit.
Anyway, I know think this doesn't help us with the radian and derivative issue. Sorry about this detour. I thought I was on to something. I do think this is an issue, another one.
The following question is for @c3d. What should be done to avoid the error condition: using DB48X 0.9.7-4-8faeb, I still encounter a condition error "Inconsistent units" with : 'exp(-x/4_s)·sin((0.5_r/s)·x)' 'x' ∂ 'x=2_s' | Eval ?
'exp(-x/4_s)·sin((0.5_r/s)·x)' 'x' ∂ 'x=2_s' | Eval
@Failing 0.03626 04691 25_s⁻¹ => "÷ error: Inconsistent units"
@leaving on the stack before eval
@=> 'exp(-(2 s÷4 s))·0.5 r/s·cos(0.5 r/s·2 s)+(-(4 s÷4 s²))·exp(-(2 s÷4 s))·sin(0.5 r/s·2 s)'
Where units of the first term (r/s) are incompatible with those of the second term (1/s). This should give an answer analog to the following:
'exp(-x/4)·sin(0.5·x)' 'x' ∂ 'x=2' | Eval
@Expecting 0.03626 04691 25
This happened in the following Ssf program (calculating the quadratic uncertainty superposition for a fonction f and initial numbers x & Δ as inputs):
« 0 0 0 → f xv σx funits σxunits fv « 'f|x=xv' Eval Eval →Num 'fv' STO fv IF fv Typename "unit" == THEN 1 fv →Unit ELSE 1 END 'funits' STO f 'x' ∂ 'x=xv' | Eval Eval →Num abs IF σx Typename "unit" == THEN 1 σx →Unit ELSE 1 END 'σxunits' STO IF σxunits 1_° == THEN σx →Radians Uval 'σx' STO END σx × CASE funits 1_° == THEN 1_r * →Degrees END funits 1_r == THEN 1_r * END END » » 'Ssf' STO
@ CASE 1) Correct example (without units):
'exp(-x/4)·sin(0.5·x)' 2 0.05 Ssf
@ Expecting 0.51037 79515 45 0.00181 30234 56
@ CASE 2) Failed example (with units):
'exp(-x/4_s)·sin((0.5_r/s)·x)' 2_s 0.05_s Ssf
@ => "÷ error: Inconsistent units"
@ leaving on the stack: 0.16385 49570 11 r/s -0.12759 44878 86 s⁻¹
I surely understand the idea of angles having radians units, but in the case of the chain rule derivative of trigonometric functions, as it is the case here, it seems that we have no other choice that to force the resulting radians to disappear. Please, your help is required here. If there is no such solution, this entire entreprise of quadratic superposition is totally compromised !
NOTE: Look at CASE 1) where it is already the case, where the constant 0.5 has implicit units of radians (indeed, if x has no units ...). But in this case these radians disappear during the chain rule derivation to give the correct coherent answer ! Clearly, the same shall be done in CASE 2), it's unavoidable !!! Hence, my suggestion to have a flag to enforce this behavior temporarily !
The following question is for @c3d. What should be done to avoid the error condition: using DB48X 0.9.7-4-8faeb, I still encounter a condition error "Inconsistent units" with : 'exp(-x/4_s)·sin((0.5_r/s)·x)' 'x' ∂ 'x=2_s' | Eval ?
'exp(-x/4_s)·sin((0.5_r/s)·x)' 'x' ∂ 'x=2_s' | Eval @Failing 0.03626 04691 25_s⁻¹ => "÷ error: Inconsistent units" @leaving on the stack before eval @=> 'exp(-(2 s÷4 s))·0.5 r/s·cos(0.5 r/s·2 s)+(-(4 s÷4 s²))·exp(-(2 s÷4 s))·sin(0.5 r/s·2 s)'
I am not @c3d but would like to contribute to a solution to this issue.
In my opinion you begin with inconsistent units. In 'exp(-x/4_s)' you imply units s for x. In 'sin((0.5_r/s)·x)' you imply units s/r for x. In 'x=2_s' you have units s for x. To me this is inconsistent already before the ∂ operator is activated.
Try: 'exp(-x/4_s/r)·sin((0.5_r/s)·x)' 'x' ∂ 'x=2_s/r' | Eval
Or, try to use radians angle mode and get rid of the r in the expressions. May require rephrasing the sin argument.
@evgaster: Sorry but you're wrong. Ask the following question in the AI engine of Google: "What are the implied units of the argument f(x) in the composition function sin(f(x)) ?", you will get the following: **«AI Overview In the composition function sin(f(x)), the implied units of the argument f(x) are radians. The sine function, by definition, takes a real number representing an angle in radians as its input. Explanation: The sine function is a trigonometric function that relates an angle to the ratio of the length of the opposite side to the hypotenuse in a right-angled triangle. When dealing with trigonometric functions like sine, cosine, and tangent, it's crucial to understand the units of the input angle. While degrees are often used for angles in introductory mathematics, the sine function is generally defined to take angles in radians. Radians are a dimensionless unit that represent the ratio of the arc length to the radius of a circle. Why radians?
- Calculus and Derivatives: The derivative of the sine function, sin(x), is cos(x). This relationship is valid when the angle is measured in radians.
- Unit Circle: The sine function is often visualized using the unit circle. Each point on the unit circle is associated with an angle in radians, and the y-coordinate of that point corresponds to the sine of the angle. In the context of the composite function sin(f(x)): f(x) represents another function. The input f(x) must be a value that can be interpreted as an angle in radians. The sine function will then take this value as its input and produce the corresponding sine value. »**
Look at eqn (14) In "https://scholar.harvard.edu/files/david-morin/files/waves_oscillations.pdf": the implied units of ω & φ in sin(ω·t+φ) are always rad/s & rad. And from eqn (48): the implied units of α in exp(α·t) are s⁻¹. Great care was taken to follow these guiding rules in the redaction of the 37 equations of the subsection "Oscillations" of the Equation Library (DB48x) and everywhere else in many other subsections. I know this for sure because I wrote all the near 700 equations (near 200 examples) of the complete Library.
I have no problem with what you needed Google or the referenced document for. Nor do I see it conflicting with the point I am trying to make. Unfortunately we seem to communicate on different wavelengths.
DB48X treats the unit r(adian) as if it has a dimension which can't be ignored. The dimension is [angle] = [length] / [length]. That is not the same as 1. It is [1].
I think DB48X is doing it right (now). My advice for @c3d would be to close this issue with wontfix-not-broken. If you write your expressions consistently, as I indicated, then even your Ssf program might work (could perhaps be simplified).
The variable x here has dimension of time, in damped oscillations and in physics (I'm a physicist) in general (as in the ref. https://scholar.harvard.edu/files/david-morin/files/waves_oscillations.pdf) it would be a nonsense to consider time has having dimension "r/s", just to satisfy the chain rule derivative of a trigonometric function as you suggested. In DB48x, I appreciate the fact that angles have dimensions that can't be ignored, except in that very case. This boils down to the very definition of the derivative itself: ∂sin(x)/∂x=cos(x) where the result has no units anymore.
The variable x here has dimension of time, in damped oscillations and in physics
You are mapping a real world problem to a physics representation, to a mathematical representation, to a software representation. Each mapping can cause problems.
(I'm a physicist)
For what its worth: I have a MSc degree (1982) in (experimental) Physics and Mathematics with majors in nuclear physics and computer science (and did theoretical physics and chemistry along the way). I still study Physics, Mathematics and Computer Science. It's fun.
in general (as in the ref. https://scholar.harvard.edu/files/david-morin/files/waves_oscillations.pdf) it would be a nonsense to consider time has having dimension "r/s",
Indeed. The Dimension of time is ... just time. Wikipedia refers to it as Quantity. I think Dimension is a better word. In my experience that is often depicted as [time] or as [s] with the base unit.
You misinterpret what I wrote before. I will give it another try below.
just to satisfy the chain rule derivative of a trigonometric function as you suggested. In DB48x, I appreciate the fact that angles have dimensions that can't be ignored, except in that very case.
Disagree. Will try to explain below.
This boils down to the very definition of the derivative itself: ∂sin(x)/∂x=cos(x) where the result has no units anymore.
Disagree!
Let's look at the Dimensions here: [∂/∂x f(x)] = [f(x)] / [x]. Or, just look at the limit definition of a derivative. It depends on the Dimensions of f(x) and x.
If you take sec sin(x) or cos(x) then the Dimension of x, which is [x], is [1]. Both the argument and the result of such transcendental functions (should) have Dimension = [1]. That is not the same as "no units anymore".
Your code is: 'exp(-x/4_s)·sin((0.5_r/s)·x)' 'x' ∂ 'x=2_s' | Eval
Let's do a (syntax) analysis on that. The argument to the exp() function is "x/4_s". As I mentioned before the Dimension of that argument should be [1]. That means the Dimension of x, [x] = [time]. The argument of the sin() function is "(0.5_r/s)·x". As I mentioned before the Dimension of that argument should be [1]. That means the Dimension of x, [x] = [time] / [angle]. The second argument to the | operator is "x=2_s". Here is the Dimension of x, [x] = [time].
So there is inconsistency in the Dimension of x.
You can argue that [angle] = [1] and the corresponding unit could be ignored. But the current software implementation of DB48X keeps it and treats it as significant. I think that is the right choice, primarily from an SI standard point of view, second from a code complexity point of view (can't deny that).
You could change your code to: Radians 'exp(-x/4_s)·sin((0.5/1_s)·x)' 'x' ∂ 'x=2_s' | Eval
So your suggestion is to completely eliminate radians at the source. Let see if this works in the more general case of: ∂/∂t { exp(-α· t) · sin(ω · t + φ) } = -α·exp(-α· t)·sin(ω · t + φ) + ω·exp(-α· t)·cos(ω · t + φ) } with real values for α, ω & φ:
α=0.25_s⁻¹ ω=0.5_s⁻¹ φ=0.3_r Radians 'exp(-α· t)·sin(ω·t+φ)' 't' ∂ 't=2_s' | Eval
@ CASE1 => "+ error: Inconsistent units" leaving on the stack:
@ level2: '0.30326 53298 56 s⁻¹·cos(0.3 r+1.)' ; level1: '-0.5+(A+B)·sin(0.3 r+1.)'
doesn't work, let's try by eliminating radians of the parameter φ in the sin function:
α=0.25_s⁻¹ ω=0.5_s⁻¹ φ=0.3_r Radians 'exp(-α· t)·sin(ω·t+φ/1_r)' 't' ∂ 't=2_s' | Eval
@ CASE2 => "∂ error: Bad argument type"
doesn't work, let's try by eliminating also radians from both parameters ω & φ:
α=0.25_s⁻¹ ω=0.5_r/s ω2='ω/1_r' Eval φ=0.3_r φ2='φ/1_r' Eval Radians 'exp(-α· t)·sin(ω2·t+φ2)' 't' ∂ 't=2_s' | Eval
@ CASE3 Expecting -0.06498 37749 69 s⁻¹
which finally works. Let's see when eliminating units everywhere:
α=0.25 ω=0.5 φ=0.3 Radians 'exp(-α· t)·sin(ω·t+φ)' 't' ∂ 't=2' | Eval
@ Expecting -0.06498 37749 69 which is the same
So, your suggestion is possible but difficult to implement since CASE2 failed. Moreover CASE3 is not very physical because it requires two abnormal changes of variable from φ to φ2 (ω to ω2) to get rid of the radians in the phase constant φ. Indeed, if you look at the ref. https://scholar.harvard.edu/files/david-morin/files/waves_oscillations.pdf, this phase constant φ has radians units (and the angular frequency ω is also in r/s), it's unavoidable as it was done also in the "Oscillations" subsection of the Equation Library. Plus the fact that for me, to arrange by hand the problem to get rid of radians everywhere at the source (in both φ & ω) is more artificial than to silence the radians (as it is usually done in physics) in the result of the original problem.
(PS I also used to work in nuclear physics: fuel management at Gentilly-2, nuclear safety for IAEA)
ω=0.5_s⁻¹ t=2_s
ω·t
Eval
Typename
Gives "decimal". It throws away the unit. It throws away the Dimension.
ω=0.5_s⁻¹ φ=0.3_r t=2_s
ω·t+φ
Eval
That already gives an "Inconsistent units" error. Everything you build on top of that will give errors.
ω=0.5_r/s φ=0.3_r t=2_s
ω·t+φ
Eval
Gives 1.3_r.
From the above examples it seems the current implementation of DB48X respects the fact that radian is a separate SI Derived unit. So it should!
But it doesn't seem to handle dimension one cases properly.
I think we need a unit _one with a Dimension one. Units of radian or steradian should evaluate to a unit _one. In expressions with units the Dimensions should be evaluated according to Dimensional analysis --> Dim Q. Expression with units where the Dimensions evaluate to one should evaluate to a unit _one and not be simplified to integer, decimal or similar.
I have been staring at the code in unit.cc. It's a steep learning curve. I have learned C++ a long time ago. But I didn't write much myself. Then there's the layer of understanding the design and implementation choices. I wish I could find documentation on that. Now I have to reverse engineer a lot. I don't see myself changing code myself any time soon
We need the expertise of @c3d.
For "Expression with units where the Dimensions evaluate to one should evaluate to a unit _one and not be simplified to integer, decimal or similar." I have my eye on unit::simple. But I am not too sure about the wider impact of changing that.
Stepping back a bit ...
The pure symbolic derivative ∂/∂t exp(-α· t) · sin(ω · t + φ) = -α·exp(-α· t)·sin(ω · t + φ) + ω·exp(-α· t)·cos(ω · t + φ) is done correctly (expect for interchanging the first and second term). But if values for parameters are already assigned, things can go wrong.
Appropriate values, and more important units, are α=0.25_s⁻¹ ω=0.5_r/s φ=0.3_r. Or ω=1 718.87338 539 °/min.
Leaving out a value for t (in that situation the value and the units of t are unknown), makes evaluating ω · t + φ already give an Inconsistent units error. Why does'n it evaluate to 0.5 r/s·t + 0.3 r ?
Something similar occurs if you take the derivative with some parameters already defined.
Including t=2_s allows for evaluating ω · t + φ and exp(-α· t) · sin(ω · t + φ).
The order of things matters. Meaning:
- don't assign parameters and arguments a value yet;
- do symbolic manipulation first;
- assign all parameters and arguments;
- evaluate.
But there is more. The derivative is α·A + ω B (with eventually A and B numerical values without units). And α and ω have different units and db48x concludes they are inconsistent.
But that is debatable ... or should I say incorrect. α and ω have the same Dimension, in SI terms. That is because an angle has Dimension = [1]. So both α and ω have Dimension = 1 / [time].
The root cause is that db48x doesn't properly handle Dimensions and in particular Dimension = [1]. Solving that would, I think, need significant code changes.
A workaround could be the make addition and subtraction of units with r(adian) (or sterradian) treated specially.
I have located the code where (for this issue) the error message comes from. It is in unit.cc in:
bool unit::convert(unit_g &x, bool error) const
// ----------------------------------------------------------------------------
// Convert a unit object to the current unit
// ----------------------------------------------------------------------------
{
...
// Check if this is a unit and if so, make sure the unit is 1
while (unit_p cf = unit::get(o))
{
algebraic_g cfu = cf->uexpr();
if (!cfu->is_real())
{
if (error)
rt.inconsistent_units_error();
return false;
}
o = cf->value();
if (!cfu->is_one(false))
o = o * cfu;
}
...
I have some idea what this does but don't fully understand, certainly not enough to change it to include my suggested workaround.
@c3d would appreciate you looking into this.
(not sure if my comment would be relevant... I understood the Angles flag as a reasonable choice to evade the complications of units, i.e use the calculator in an old-fashioned way. The cited paper hints in the same direction, reminding that one needs to take care about the context of the calculation at hand, especially taking care of the pi factors etc. trig. functions have dimensionless arguments. If we invert a sin we have the arcus or part of the unit circle. if we invert a sinh we have an area function pointing to the included area within the unit hyperbole. is this r squared as a dimensionless unit or a fictive a as an outcome ng dimensionless unit?)
@emb974 I agree with you, In my opinion, this radian issue is an artificial one, simply because radians are not true physical units. And you are forced to choose between two alternatives:
-
Either, you adhere to the strict point of view which implies to consider radians as usual units (that's the case of DB48x v 0.9.14) and, then you observe many consistency issues (as the ones cited here). The only workaround strategies in such cases are either: i) to avoid explicitely affecting radians to any angular quantities that might be implied in chain rule derivative of trig functions (as done when needed for the uncertain interval type in my document: see https://www.hpmuseum.org/forum/thread-24065-post-209826.html#pid209826); ii) or, you somehow fudge your equations to force explicit algebraic cancellation (or incorporation) of radians at the start of any relevant computations (as I did in many expressions of DB48x's extended Equation Library to insure consistency); iii) or, since ii) can not be done algorithmically in some automatic universal procedure, this would imply instead the implementation of the said toggle flag: "RadAngles o" with its 2 states "o" OR "●" to avoid the evaluation error, for instance, in the chain rule derivative cited at the beginning of this issue (or in any circomstances where inconsistencies are related to radians). As far as I can see, an easy way to implement this would be, if the flag is "On": to restart any erroneous evaluation by rewriting beforehand the faulty variable with radian units "θ̱_r" as "θ̱_1".
-
Either, the parsing engine treats any expressions having radians as if they were non-existent, except for the behavior of trig functions managing their angular arguments accordingly. In other words it almost nullifies their presence as it is usually done in many scientific calculators.
For me, if we want to maintain their explicit presence, there is no real alternative other than 1. i) or 1. iii), which are equivalent in the sense that they both require a voluntary action from the user. Does everybody would agree with this analysis?
@Wiljea
What do you mean by "radians are not true physical units"?
The physical quantity we are discussing is an angle. The radian is a measure for the size of an angle. The ° is another measure for the size of an angle. The "grad" is yet another. The radian is an SI derived unit.
This is issue is about de t derivative of sin(ω·t+φ) being ω·cos(ω·t+φ) where ω has a r/s unit and you want to add to something else with a 1/s unit. The r unit gets in the way.
That's because DB48X doesn't know the dimension of r/s and 1/s are the same and quantities with either of these units can be considered consistent units.
Isn't only with addition (or subtraction) of quantities with units with powers of angle measures that differ that this difference should be "ignored"? Or should it be first scaled to the base unit (unfortunately DB48X uses not radian but turn)?
In all other places this difference should be respected.
Therefore, DB48X should know the dimension of r/s and 1/s are the same and quantities with either of these units can be considered as having consistent units, especially in situations where we have the t derivative of sin(ω·t+φ) being ω·cos(ω·t+φ) where ω has a r/s unit and you want to add to something else with a 1/s unit. In such case "_r" has to be treated as "_1". Also in equations where dimensionality a priori differs, like 'T=2·Ⓒπ/ω=2·Ⓒπ·√(L/Ⓒg)'. Is there any other cases to take care of?