newRPL: Angles revisited

04012016, 11:15 PM
Post: #19




RE: newRPL: Angles revisited
(04012016 07:01 PM)emece67 Wrote: I agree on this. On my view:So far so good, scalar +/ angle breaks consistency but could be done. (04012016 07:01 PM)emece67 Wrote: [*]scalar / angle = scalar, the result is scalar/(angle converted to radians), 2 / 90D = 4/piThis could be a problem. For example an expression: 'ASIN(A)*ASIN(A)/ASIN(A)'. The user has the settings in DEG, and thinks ASIN will return DEG, so you would expect the result to be let's say 45 or ∡45°. If the operator associates the right side first: ASIN(A)*(ASIN(A)/ASIN(A)) = ASIN(A)*1 = ∡45° but if it associates from the left: (ASIN(A)*ASIN(A))/ASIN(A) = (pi/4)^2/∡45° = pi/4 (correct, but in radians!) With the "angle is a number" approach: ASIN(A)*(ASIN(A)/ASIN(A)) = ASIN(A)*1 = ∡45° (ASIN(A)*ASIN(A))/ASIN(A) = 45^2 / ∡45° = 45 (not an angle, but at least the same number as expected) On the other hand, the "angle is a number" can also give bad results in expressions with mixed systems: '∡50g*2/∡90°' If associated from the left: (∡50g*2)/∡90° = ∡100g/∡90° = 1 versus: ∡50g*(2/∡90°)= ∡50g*(1/45)= ∡1.11111111111111g This can seriously drive a user crazy. What could be a solution for this? 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)